Properly label the build root for the f34 build root manifest v2.
Also label the cp and tar binaries with `install_exec_t` so they
can read and copy labels unknown to the host.
Include a simple test for the `tar` stage that does basic checks,
i.e. that a tarball was successfully created, but also checks
that we do not create entries with a `./` prefix.
Create a new `org.osbuild.systemd.unit` stage with the code for
create systemd drop-ins extracted from `org.osbuild.systemd`.
In contrast to the old code the new stage can only handle one
drop-in file. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top level comment.
The file is called `org.osbuild.systemd.unit` since in the future
it could also support creating unit files (not just drop-ins).
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top level comment.
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top level comment.
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify additional options at the top level which
will then be per-file, like a top-level comment.
Instead of supporting writing an arbitrary number of configuration
files, just write one. This makes the stage and its schema clearer
and simpler. If more than one config file is needed, the stage can
be repeated multiple times. It is also more flexible since we can
in the future specify the directory, `/etc` vs `/usr` via a new
top level `directory` key.
The order of entries in a dictionary is not specified by the JSON
standard and hard to control when marshalling dictionaries in Go.
Since the order of mounts is important and the wrong order leads
to wrong mount trees change the `mounts` field to an array. This
breaks existing manifests but after careful deliberation it was
concluded that the original schema with mounts as dictionaries
is not something we want to support. Apologies to everyone.
Adjust the schema of the copy and zipl stage accordingly.
Instead of having the OSTree repo in the anaconda root squashfs,
put the it to the root of the iso. This has several advantages:
first and foremost, we don't have to make a huge squahfs file-
system. We don't have to compress the repo. Additionally, the
repo is now easily accessible by mounting the iso.
Intead of overwriting the standard ananconda kickstart file, we
move it to the root of the iso. To have anaconda pick it up an
additional kernel command line parameter is required.
F34+ has the xorg-x11-server-utils package split up. Install the
individual new packages we need for anaconda.
See Anaconda commit 55371c996861a47da9504b31118858dd3257a8b0
Use variables for various often occuring contants, like the
release, ref and isolabel. Additionally, use variables for
the snapshot so it can be changed easily.
Allow the manifest variables, defined via mpp-vars, to be used from
within the mpp blocks. For this template strings are used, where
variables are marked via `$`. We cannot use the `mpp-format` logic
easily there, since that is processed after other mpp directives
have been processed.
As a result remove the built-in substitution from support from dnf
dep-solving, since we had to post-process the resulting urls with
variable substitution afterwards. Now that is covered with this
more generic mechanism.
The manifests set a "en_US" locale but this causes gnome-terminal to not
run due a non UTF-8 locale being used, which is an unsupported config:
gnome-terminal-server[1899]: Non UTF-8 locale (ISO-8859-1) is not supported!
Reported-by: Stephen Smoogen <ssmoogen@redhat.com>
Use the new partiton layout support in MPP. NB: start data as
well as the size of the last partition have been omitted now,
since `sfdisk` will figure those out for us.
Previous versions of mpp would already set the arch and basearch
substitution, which would work for dep-solving itself, but not
properly re-write the resulting URLs which means that the manifest
was broken. Fix this by properly replacing the substitutions in
the URL. Also support official 'releasever' substitution.
Instead of passing dictionaries around that are inconvenient to
use in code and even more in the `mpp-format-*` directives, use
a simple class to represent package information. Use that in
the `pkginfo` dict that can be accessed via `mpp-format-*`. Use
the `evra` property instead of string manipulation in the
`fedora-boot.mpp.json` and `-ostree-bootiso.mpp.json` manifest.
This uses size computations to simplify the partition size/offsets
and the depsolv results to get the kernel version.
This makes no changes to the resulting json files.
Add a new `org.osbuild.authselect` stage for configuring system identity
and authentication sources using `authselect`. The stage runs
`authselect select` command from the image in a chroot to set the
desired 'profile_id' profile. Optionally, a list of specific profile
features to enable can be passed using the 'features' option.
Add a test case for the new stage.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add a new option 'x11-keymap' for configuring the X11 keyboard settings.
The value of the option is a dictionary with keys representing settings
which can be configured. Currently, only the 'layouts' setting can be
configured. Its value is a list of strings, representing the specific
layouts, which should be configured for the X11 keyboard.
Update the stage test case with the new option 'x11-keymap'.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The `org.osbuild.chrony` stage currently supports only a single option
'timeservers' which does not allow specifying additional options for the
configured timeservers. The option can not be easily extended to allow
specifying additional options and at the same time keep the backward
compatibility with old manifests.
The need for a lower-level stage option allowing to configure additional
options of the 'server' directive is required by RHEL AMI images, which
use 'maxpoll', 'minpoll' and 'prefered' options.
Extend the `org.osbuild.chrony` stage with two additional options. The
'servers' option accepts a list of dictionaries specifying timeservers
to be configured using the 'server' directive, including a subset of the
directive options. The 'servers' option can not be used at the same time
in the stage options as the 'timeservers' option.
The second added option is 'leapsectz' corresponding with a directive of
the same name. The value of the option is a string. If the provided
string is empty, then all occurrences of the 'leapsectz' directive are
removed from the `chrony.conf`. Otherwise, the 'leapsectz' directive is
added to the `chrony.conf` with the provided value, while all original
occurrences of the option are removed.
Add a new stage test case under `test/data/stages/chrony-servers` to
test the new variant of the stage options. The reason is that the
'timeservers' option conflicts with 'servers' option, which makes it
impossible to test both of them in the same test case.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add new `org.osbuild.cloud-init` stage, which currently allows to create
configuration files for cloud-init under `/etc/cloud/cloud.cfg.d`. The
stage supports only a very limited subset of cloud-init configuration
options, which is covering needs of RHEL AMI images.
The schema mandates that if the 'configuration_files' option is
specified, then at least one configuration file must be defined. In
addition each section of the configuration must contain at least one
property (section or configuration option).
Add `python3-pyyaml` package to the `F34-build` testing manifest,
because it is required for running and testing the new stage.
Regenerate all affected manifests.
Add test for the new stage.
Update the `osbuild-ci` container image used for testing to a new tag,
which includes python3-pyyaml, the dependency of the new stage.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
