The code currently does not support btrfs subvolumes that are not
directly under the root directory. This commit fixes this by adding
`-p` to `btrfs subvolume create` and adding an integration test.
Closes: https://github.com/osbuild/osbuild/issues/1882
We need to pass loopback devices for these properties, but the schema
says that there will be a `path` property, so osbuild complains.
osbuild is right of course, but this definitely *did* work in an earlier
version, so something changed. Ideally, we'd narrow down here what
happened exactly, but at the same time this approach of just making the
property more generic matches what's done in e.g. the `zipl.inst` stage
where we also use a loopback device.
For reference, this is where we use this stage:
ba45b296ec/src/osbuild-manifests/platform.qemu.ipp.yaml (L100-L119)
Adds a new stage that calls update-ca-trust tool with extract argument
to extract CA certificates. It is expected that one or more CAs are
placed in the /etc/pki/ca-trust/source/anchors directory in PEM format.
Filenames do not matter but must be unique enough. See the
update-ca-trust man page for more details on what it does.
For consistency, use subprocess.run() with check=True for the calls that
were previously using subprocess.check_call().
Update the affected tests to match.
Different toml libraries write arrays differently, so we can't know
exactly what the file contents will look like. Some will write an array
in a single line (toml) while others will break it into one element per
line (tomli_w). Parse the file that's written by the stage so we can
compare the objects instead of the text contents directly.
Recently [1], the update-crypto-policies script added a check to verify
that the FIPS policy was automounted by reading the
/proc/self/mountinfo. The script will fail if the proc filesystem isn't
available.
Use the new Chroot context to set up the environment for the command.
[1] 04ceadccfc
New chroot utility module that sets up a tree with the necessary virtual
filesystems needed for running commands in the root tree in a similar
environment as they would run in the build root.
This is needed for some stages, but may also be used for all chroot
calls to unify the setup and teardown of the root environment.
The Chroot context class was previously part of the org.osbuild.dracut
stage, which was the first stage to need this setup.
dracut expects the environment, in which it is run, to have properly
mounted /proc, /dev and /sys. Otherwise, some of its modules don't work
properly. E.g. dracut fails to embed the CA cert bundle into the initram
disk, which means that HTTPS won't work in it. dracut also prints a lot
of errors and warnings about this, but we used to ignore them until now.
The buildroot environment in which the stage runs is OK, but we actually
run dracut using 'chroot', which is the core of the problem. The runtime
environment in such case lacks the necessary mounts.
Add a context manager for setting up and cleaning up all the necessary
mounts in the image FS tree when running dracut.
This change is related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1962975
And the implementation has been inspired by the fix in lorax:
https://github.com/weldr/lorax/pull/1151
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
There was a small mistake in the schema since either one of
`new_profile` or `tailored_profile_id` is required. This commit fixes
this and updates the tests to check for this case.
According to `autotailor(8)` arguments passed in via the cli take
precedence over the JSON tailoring file contents.
Make the `new_profile` a required field for the json tailoring too and
pass it as an option to the `autotailor` command. This approach has some
trade-offs. It allows us to maintain the explicitness of the manifest
that is consumed by `osbuild`. The downside is that it will override the
profile id that is set by the user in the JSON tailoring file.
Rename the `new_profile` option to `tailoring_profile_id` for clarity.
This also ensures that the change is backwards compatible by falling
back to the `new_profile` option if that was set instead of the
`tailoring_profile` id option.
This is a small adjustment to how the `osbuild.util.mnt.mount` fuction
is imported. While adding unit tests, the tests failed when trying to
patch the function, this commit fixes the issue.
With the `oscap-utils-1.3.10` release, the `autotailor` command now
supports importing a JSON tailoring file[1] that is then converted to the
XML tailoring file which is consumed by the `oscap` command in the
remediation stage.
[1] https://github.com/ComplianceAsCode/schemas/blob/main/tailoring/schema.json
Add the force_password_reset field to the users option in the
org.osbuild.users stage. This option forces the user to change their
password on first login.
Based on the filename, different sections of the unit configuration are
valid. Service (.service) units require a [Service] section and mount
(.mount) units requires a [Mount] section.
It might be possible to validate this in the schema but it would
probably require a major rewrite and could get complicated. For now,
validate it in the stage code itself.
With PR#1727 merged there is no need to test for individual stages
if they support the bootc style mounting in their schema. All
stages now support devices/mounts now. So let's remove this
redundant code.
