For usecases where for example selinux is not supported,
we should expect more errors from tar so we should also accept this
when matching the string.
Kudos go to Achilleas Koutsou <achilleas@koutsou.net> for this hint
We currently use the absolute path of these binaries in the
helper. This has some advantages but given that we control the
inputs for PATH in general it seems unnecessary.
We are also slightly inconsistent about this in the codebase but
favor the non absolute path version. A quick count:
```
$ git grep '"chroot"'|wc -l
13
$ git grep '"/usr/sbin/chroot"'|grep -v test_|wc -l
8
```
for `mount` and `umount` it seems this is the only place that uses
the absolute path.
It's not an important change but it has the nice property that it
allows us to use e.g. `testutil.mock_command()` in our tests and
it would be nice to be consistent.
This commit adds a new `transform` option to the tar stages that
maps directly to the `--transform=` comamndline argument of tar(1).
This allows to transform the names while files/dirs are added to
a tarfile. This is useful for the `gcp` pipeline for
bootc-image-builder where we want to create a gcp tar file that
expects the disk image filename in the tar to be exactly `disk.raw`.
Note that tar allows only a single `--transform` and we leave it
to the user to construct `sed` expressions if multiple renames
are required.
With the labels option the user is specifying the exact context
they want to set on the path so it's not necessary to supply a
context here. This can be also useful in the case where you want
to set some labels and you haven't yet populated the tree yet.
This is essentially org.osbuild.systemd.unit.create but creates
file where podman looks for quadlets instead.
For now only container, volume and network is supported.
Not all quadlet options are supported, but at least the most usef ones, and enough for the automotive sample-images.
Its not uncommon for systemd unit key values to contain things like
"%t", as these are magic values expanded by systemd. We need to
disable the ConfigParser default interpolation that treats '%' as
meaning interpolation.
Otherwise you will get errors like:
```
File "/run/osbuild/bin/org.osbuild.systemd.unit.create", line 66, in <module>
r = main(args["tree"], args["options"])
File "/run/osbuild/bin/org.osbuild.systemd.unit.create", line 46, in main
config.set(section, option, str(value))
File "/usr/lib64/python3.9/configparser.py", line 1204, in set
super().set(section, option, value)
File "/usr/lib64/python3.9/configparser.py", line 894, in set
value = self._interpolation.before_set(self, section, option,
File "/usr/lib64/python3.9/configparser.py", line 402, in before_set
raise ValueError("invalid interpolation syntax in %r at "
ValueError: invalid interpolation syntax in '%t/asil-ipc-demo/asil_ipc.socket' at position 0
```
Add a new stage, which allows analyzing the installed packages in a
given filesystem tree using DNF4 API and generating an SPDX v2.3 SBOM
document for it.
One can provide the filesystem tree to be analyzed as a stage input. If
no input is provided, the stage will analyze the filesystem tree of the
current pipeline.
Add tests cases for both usage variants of the stage, as well as the
unit test for stage schema validation.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
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.
