The unit test consists of a manifest creating an empty file, which
is then converted to various formats using the `org.osbuild.qemu` stage
in separate pipelines.
The unit test then builds and exports each pipeline with qemu stage and
inspects the resulting image file using `qemu-img info` command and checks
that the test data specified in `checks.json` is a subset of the data
returned by the command.
When is specified change the GPT partition attribute bits. The attributes
is a comma list of bits numbers or bit names. You can take a look at the
manual page of sfdisk to see the supported attribute bits.
Instead of a human pushing a tag with the release notes let a bot do the
work.
The bot is part of our composite action in osbuild/release-action on the
create-tag branch. It calculates the next subsequent release version and
creates a tag based on pull request titles associated with the changes
since the last release.
Finally the tag is pushed to the repository.
Unfortunately GH Actions don't allow for reliably fortnightly schedules,
so we do an additional check that determines if this is an even or an
odd week. This will help with correctly scheduling alternating osbuild
and osbuild-composer releases.
For reference, we do exactly the same for osbuild-composer already:
https://github.com/osbuild/osbuild-composer/blob/main/.github/workflows/create-tag.yml
If instructed, the rpm stage checks all digests and signatures of a package
explicitly using `rpmkeys` tool. The default stage behavior is that no
package signatures are checked when installed by the stage (not even
explicitly).
For these reasons, the package signature checking is supposed to be
disabled when installing rpm packages. This was achieved by passing the
`--define "_pkgverify_level none"` option to rpm. However this option
specifies only requirements for a package to be installed and `none`
means that packages without any signature are accepted by rpm. If the
package signature is deemed BAD, the package installation fails even
though this option has been passed to rpm.
There are valid cases when even packages which signature marked as BAD
should be installed. It may happen, that the GPG key used to sign a
package uses an algorithm not allowed by the system crypto policy, e.g.
SHA1. If such GPG key is imported on the system and a package signed
using it is being installed, its installation would fail when the
package is read by rpm. This is because its signatures are by default
checked if they exist in the package.
The desired behavior to not check any package signatures when installing
a package is instead achieved by using `--nosignature` rpm option. It
turns off the whole signature checking mechanism.
Use the `--nosignature` rpm option instead of
`--define "_pkgverify_level none"`, when installing packages using rpm.
Fix https://github.com/osbuild/osbuild/issues/991
Instead of using `chcon`, directly call `selinux.setfilecon`.
On systems without SELinux support, i.e. coreutils was built
without `<selinux.h>` present, `chcon` will return `ENOTSUP`
for all calls to SElinux functions like `setfilecon` even if
the selinux libraries are later installed.
Therefore we directly call the new osbuild helper function,
which really is just a wrapper around setting extended file
attributes and thus will work even if SELinux support is not
compiled into coreutils.
The only other thing `chcon` is doing besides a cal to the
`setfilecon` method is to convert the context string to a
new `contex_t` and back to validate it. This should not be
needed since the kernel will do this for us. On system
without SELinux support `context_new` will also not validate
the context.
This is basically a re-implementation of `setfilecon(3)` minus the
translation of human readable context to raw context. Add test for
the new function.
Some RPMs might be very large, and limiting the total download time
might lead to failed build even in cases where downloading is making
progress. Instead, set a minimum download speed (1kbps). If the
minimum is not surpassed for 30 seconds in a row, the download fails
and is retried. This follows the logic employed by DNF.
Adjust the number of retries to 10 and the connection timeout to 30,
in order to match what DNF does. One difference is that DNF does 10
retries across all downloads, whereas we do it per download, this
could be changed in a follow-up.
Old:
- a download taking more than 5 minutes is unconditionally aborted
New:
- slow but working downloads will never be aborted
- downloads will be stalled for at most five minutes
in total before being aborted
- time spent making progress does not count towards
the five minutes
Signed-off-by: Tom Gundersen <teg@jklm.no>
Add a new attribute `config.default` that when set will be written to
`GRUB_DEFAULT`. This should be set to `saved` when a `saved_entry` is
specified so that the functionality will be preserved if the grub cfg
gets regenerated (which is really should not, but we can not prohibit
it).
When the firewall stage is provided with stage options, which set only
the default firewall zone, the `firewall-offline-cmd` command is
executed unconditionally without any parameters. This is because in this
case `ports`, `enabled_services` and `disabled_services` are all an
empty lists. This results in a failure with the following error message:
`Opening of '/etc/sysconfig/system-config-firewall' failed, exiting.`
Make sure that the second invocation of `firewall-offline-cmd` happens
conditionally, only when at least one of the `ports`, `enabled_services`
or `disabled_services` is a non-empty list.
Adjust the stage test to cover this scenario.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
In all the invocation of `subprocess.run` stderr and stdout were both
combined in a shared pipe, but lvm sometimes spits out notices and
informational messages on stderr and thus potentially interfering
with the data we are interested in on stdout. Separate the two.
In all invocations of `subprocess.run` stderr and stdout were both
combined in a shared pipe, but lvm sometimes spits out notices and
informational messages on stderr and thus potentially interfering
with the data we are interested in on stdout. Separate the two.
Add a new option `gpgkeys.fromtree` that when specified will
import the specified gpg keys from files located in the tree,
such as `/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release`.
Extend the firewall stage to allow setting the default firewall zone.
Modify the stage unit test accordingly.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Without configured repositories the generated pacman.conf isn't super
useful. Pacman supports two different ways to configure a repository
either with a Server = line or sourced from pacman's mirrorlist.
The udev inhibitor rules are checking for `device-$major:$minor`
but we created them with `f"device-{major}-{minor}"`. So they
did indeed not actually work. Fix that.
This stage is needed to write down the FDO DIUN pub key root certs
needed to talk to the manufacturer server to grab the device credentials
for provisioning and later onboarding
Co-Authored-By: Antonio Murdaca <runcom@linux.com>
According to OCI image specification the `created` property needs
to be in the format describe in RFC 3339, section 5.6 "Internet Date /
Time Format". The suffix is the "time-offset" which is either "Z" or
"time-numoffset".
Before commit 25b5679[2] we the datetime object, created via `utcnow`
did not have timezone information so "Z" was manually appended. This
was changed with commit 25b5679 and now the timezone information was
indeed included, which also meant that `isoformat` now included the
offset, i.e. `+00:00`. But the `Z` was still appended and the result
was `+00:00Z`, something that is not standard compliant. Fix this
by removing the extra `Z`.
[1] https://datatracker.ietf.org/doc/html/rfc3339#section-5.6
[2] 25b567990b
Add support for emitting signals to host.Service which can be used to
transmit data back to the client during an ongoing method call. This
provides the possibility for the services to send information to their
client counterpart while running. The signal can take file descriptors
as extra parameters to send data on separate files.
Each time the overlay backend runs on an xfs fs it creates the
file "overlay/backingFsBlockDev" in the containers storage directory.
It is not needed in the image as skopeo recreates it each boot, and
since it is a block device its existance means we can't store the
resulting tree in ostree. Lets just get rid of it.
During the rework done in commit "use and require explicit exports"
with commit id 7ae4a7e78, the test got overlooked. Add an empty
list of checkpoints to the `obs.compile` invocation as to actually
trigger the osbuild invocation.
Reported-By: Thomas Lavocat <tlavocat@redhat.com>
We hardcode oci-archive for now and use the first file in the pipeline
tree as the archive. Long term we may want to get this info from the
metadata of the oci-archive stage instead.
There is a source test that installs a pre-build, embeded image file
and ensure all the right files are installed. This uses the vfs driver
because then it works everywhere, including the CI (which doesn't do
overlayfs).
Then the is a source test that downloads a minimal image from
a faked registry on localhost.
For the registy API to work the "/v2" entry-point in the webserver has
to be at the root, so there is a symlink in test/data:
v2 -> sources/org.osbuild.skopeo/data/v2
But otherwise the data is localized to sources/org.osbuild.skopeo.
Both file embedding and depsolves start by iterating over all stages,
and we want to add another similar one for container installs, so
break out the iteration over the containers so that it is done in
one place only.
This adds a stage called org.osbuild.skopeo that installs docker and
oci archive files into the container storage of the tree being
constructed.
The source can either be a file from another pipeline, for example one
created with the existing org.osbuild.oci-archive stage, or it can
be using the new org.osbuild.skopeo source and org.osbuild.containers
input, which will download an image from a registry and install that.
There is an optional option in the install stage that lets you
configure a custom storage location, which allows the use of the
additionalimagestores option in the container storage.conf
to use a read-only image stores (instead of /var/lib/container).
Note: skopeo fails to start if /etc/containers/policy.json is
not available, so we bind mount it from the build tree to the
buildroot if available.
