If fs-verity is configured in ostree then ostree will (try to) enable
fs-verity on various repo files. However, in osbuild this will happen
in a separate pipeline, and these files will later be copied to the
final location on the physical filesystem, and any fs-verity status
then is lost.
To support fs-verity we need to run this stage after copying the image
to the filesystem. It uses the ostree "admin post-copy" operation.
which it will re-enable fs-verity as needed.
This adds a new stage that allows you to set the experimental new
`ex-integrity.composefs` option. If set to true, it means that when
deploying from this repository a composefs image will be created.
A value of `maybe` is also supported, which means composefs will only
be created if support is built into ostree.
Support for this was added in ostree 2023.4, earlier versions ignore
this key.
This stage uses the new prefix org.osbuild.experimental. This way
users will not accidentally enable an experimental option, and allows
us (and ostree) some leeway in making changes over time to this
feature.
This stage calls `update-crypto-policies` to set the
policy applicable for the various cryptographic back-ends,
such as SSL/TLS libraries.
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
Link "/proc/self/fd" to "/dev/fd" within the tree
to avoid "'/dev/fd/63': No such file or directory" errors
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
This implements the display mode options `text`, `graphical`,
`cmdline` as an enum with the name `display_mode`.
See PR#1442 for the rational/discussion of this over using
three boolean options.
Thanks to Achilleas and Tom!
This adds a stage to be able to add kernel arguments on a system by
appending to the BLS [1] config directly either in the tree or in
a mount. This is useful on say systems that don't use `grubby` and
thus can't use the org.osbuild.kernel-cmdline stage.
[1] https://freedesktop.org/wiki/Specifications/BootLoaderSpec/
This form of signatures has been (build-time-optionally) supported
since ostree 2020.4 as an alternative to the old gpg signatures. With
the current work on composefs[1] they are becomming more important, as
they will allow verification of the commit (and thus the composefs
image) during boot, giving us a full trusted boot chain all the way
into the ostree userspace.
Note: `ostree sign` used to require libsodium and was thus disabled in
e.g. the Fedora build of ostree. However, recently[2] it is also supported
with openssl, which will let it be more widely used.
[1] https://github.com/ostreedev/ostree/pull/2921
[2] https://github.com/ostreedev/ostree/pull/2922
This stage allows you to create new (random) ed25519 keys as used by
`ostree sign`.
The primary usecase for this is composefs. You can generate a
transient key-pair during the build (unique to the build) that binds
the initrd to the userspace tree.
You put the public key in the initrd, sign the resulting commit with
the private key and then throw away the private key. During boot of a
(secureboot trusted) initrd, we use this public key to validate that
we're booting the right commit.
This is similar to how the transient kernel module signatures work.
It similarly generates a keypair during the kernel rpm build, sign the
modules, throw away the private key and embed the public key in the
kernel binary.
Of course, this stage can also be used to generate keys used for
persistant signatures.
Now that inputs can be relatively easily validated against
the schema this should also be used for all the "good" test
inputs to ensure that all tests test against valid inputs.
This commit implements the `reboot` option for kickstart files.
Note that there are two ways this can be enabled via the json.
Either via a boolean or by passing a dict with options.
```
{"reboot": true}
{"reboot": {"eject": true, "kexec": true}
```
Passing the empty dict
```
{"reboot": {}}
```
is not allowed by the schema.
Add functional/regression around the schema validation for the
kickstart stage. The goal is to ensure that the regexp matching
in the schema allows the expected uses and rejects clearly
forbidden ones.
Add support for the kickstart options:
- zerombr
- clearpart
Note that for clearpart the `drives` and `list` options have a
regexp pattern to limit the valid inputs. In theory we could only
exclude the `,` here as this is used in the kickstart config as
the list delimiter. Similarly `disklabel` also needs to exclude
` ` or one could write:
```
{"disklabel": "foo --unknown-option-that-confuses-kickstart"}
```
Functions for parsing mounts and inputs raise an exception if the
referenced entity can't be found in the stage options. However, the
exception message always included the value of the `root` variable,
which is `None` when an exception is risen. Instead of the `root`
value, the `name` variable with the entity name should be used.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The items of an array are defined under the `items` key, not under `paths`.
Let's fix this.
Btw, this is possible because JSON Schema itself doesn't use
additionalProperties = false. This allows extending the schemas easily, but
is sadly a bit error-prone.
Sadly, since this issue effectively disabled validation of the stage options,
we also need to relax the schema a bit:
We found out that there are manifests in the wild, that use relative paths,
instead of absolute ones. Thus, this commit changes the validation regex to
allow relative paths. However, this now emits a warning and it's strongly
discouraged. The associated stage test was modified to accommodate for this.
Co-authored-by: Tomáš Hozza <thozza@redhat.com>
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
This is a feature that was added in rpm-ostree 2023.10 and is needed
for the new transient /etc feature to work. What it does is change the
labeling of /usr/etc to match those of /etc, so that /usr/etc can be used
directly as a bind-mount or an overlay mount when mounted on /etc.
See https://github.com/coreos/rpm-ostree/pull/4640 for details.
This drains some of the logic out of `main()` into a
`ostree_commit_deploy()` function. Doing this will make it easier
to diff this stage with the recently added `ostree.deploy.container`
stage.
This commit also changes the `ref` in the schema to be optional,
which is a fixup for 3cc733d. We need to make the ref optional because
the ref could come from the user in the toplevel schema or it could
come from input commit in the schema.
This stage is similar to ostree.deploy, but deploys from a container
image rather than from an OSTree commit by using the `ostree container
image deploy` command. An example stage definition could look like:
```
- type: org.osbuild.ostree.deploy.container
options:
osname: fedora-coreos
target_imgref: ostree-remote-registry:fedora:quay.io/fedora/fedora-coreos:stable
mounts:
- /boot
- /boot/efi
kernel_opts:
- rw
- console=tty0
- console=ttyS0
- ignition.platform.id=qemu
- '$ignition_firstboot'
inputs:
images:
type: org.osbuild.containers
origin: org.osbuild.source
mpp-resolve-images:
images:
- source: quay.io/fedora/fedora-coreos
tag: stable
```
Co-authored-by: Dusty Mabe <dusty@dustymabe.com>
Add a new attribute, "keys", to allow specifying multiple public SSH
keys to install to a users authorized_keys file.
This maintains backwards compatibility with the existing "key" attribute
that can only specify a single SSH key to install into the file (without
using some newline hacks).
Signed-off-by: Michael Ho <michael.ho@ieee.org>
This will allow a user to specify an input directly to the deploy
stage rather than requiring a ostree.pull stage to be called first.
Adding inputs will also be useful when we soon add support for
deploying from a container rather than just deploying from an existing
ostree commit in a repo.
I've been informed that this stage is old and shouldn't be used for
newly created manifests. Let's add a comment to the top for future
explorers of this code base.
Some platforms like the TI AM62 require a particular FAT geometry for
their CPU to read the file system (and thus the bootloader). Failing
that the CPU will simply not boot and keep looking for a bootloader.
Let's add some options to enforce a particular filesystem geometry
through the -g option of mkfs.fat.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The current options building code for mkfs.fat prevents to have multiple
options at a time since it will assign the opts list to either the label
or fatsize options.
If both are set, only the last one, fatsize, will be set.
Use the occasion to rewrite the code a bit and limit the number of
lists concatenation.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
This will hoist even more code into util out of the skopeo stage.
Now a caller can call:
with containers.container_source(image) as (image_name, image_source):
print(f"{image_name}, {image_source}")
to process containers inputs.
This hoists container handling code from the skopeo stage into
util/containers. It is prep for adding another stage that accepts
containers as an input. The code is common so we should share it
amongst all stages that use containers as input.
For Fedora CoreOS we don't actually have any root= kernel command
line option in our baked images. We have services that rely on this
and set up sysroot on first boot. The code in this stage doesn't
require for this option to have been provided and actually gracefully
handles when it's not provided. Let's just change the schema to also
not require it.
Osbuild doesn't support creating btrfs over multiple devices, thus it should
be fine to have only single and dup in the schema (other options are for raid)
systemd unit stage will now be able to add user unit dropin,
this is done by adding an additional field:unit-type
which is set to system by default. It also adds ability
to update the unit config with ConditionPathExists.
Relevant testing updated for the new workflow.
Signed-off-by: Sayan Paul <paul.sayan@gmail.com>
This adjustment allows the definition of the mark with the RPMs and runs
DNF after installing the RPMs to put the proper markings in the DNF
state database. See #455.
This ensures that packages don't get removed during `autoremove` leading
to broken systems.
rpm-ostree 2023.2 dropped the `rpm-ostree container-encapsulate` entrypoint.
Instead, we have to use `rpm-ostree compose container-encapsulate`.
Adjust the code that it selects the correct entrypoint based on the rpm-ostree
version.
Since the new stage now requires python-yaml, add it to the buildroot and
regenerate all manifests.
We have a lot of copypasta of `def ostree()` but in this
case it's actually rpm-ostree, and we should be clear about that.
(Also in the future this code will need to change
to use the non-deprecated entrypoint, see
https://github.com/coreos/rpm-ostree/pull/4527 )
