Pytoml is no longer being maintained: https://github.com/avakar/pytoml
The author suggest switching to toml.
We already use the
```
try:
import toml
except ModuleNotFoundError:
import pytoml as toml
```
pattern in stages/org.osbuild.containers.storage.conf so use it in the tests too to prefer "toml" instead of pytoml.
This adds tests for the erofs stage. The tests are slightly different
from the existing tests that run the filesystem utils inside the
stages. Depending on what exactly we want to test we may still need
a run inside the stages. However running this inside a container
should be good enough if we just want to validate that the options
are passed correctly and the file is created.
This is a variation of PR https://github.com/osbuild/osbuild/pull/960
that put the machine-id handling into it's own stage and adds
explicit handling what should happen with it.
For machine-id(5) we essentially want the following three states
implemented:
1. `first-boot: yes` will ensure that /etc/machine-id is
in the "uninitialized" state. This means on boot the systemd
`ConditionFirstBoot` is triggered and a new id in `/etc/machine-id`
is created. This will work for systemd v247+.
2. `first-boot: no` will ensure that /etc/machine-id exists but
is empty. This will trigger the creation of a new machine-id but
will *not* trigger `ConditionFirstBoot`.
3. `first-boot: preserve` will just keep the existing machine-id.
Note that it will error if there is no /etc/machine-id
Note that the `org.osbuild.rpm` will also create a
`{tree}/etc/machine-id` while it runs to ensure that postinst
scripts will not fail that rely on this file. This is an
implementation detail but unfortunately the rpm stage will
leave an empty machine-id file if it was missing. So we cannot
just remove /etc/machine-id because any following rpm stage
would re-create it again (and we cannot change that without
breaking backward compatiblity). Thanks to the special semantic
that a missing /etc/machine-id and an /etc/machine-id with
the `uninitialized` string are equivalent we don't care.
To support systemd versions below v247 we could offer an option
to remove /etc/machine-id. But the downside of this is that
it would only work if the org.osbuild.machine-id stage is after
the rpm stage.
See also the discussion in PR#960.
Thanks to Tom, Christian for the PR and the background.
Check for valid ipv4 addresses via a regex in the schema and
add matching tests. This will ensure that only valid ipv4
addresses can be entereed in "ip", "gateway" or "nameservers".
Note that libc/kernel accept invalid ipv4 addresses and do
"interesting" things with them. So they accept `127.1` and
turn that into `127.0.0.1` or even `127.256` and turn that
into `127.0.1.0` because 256 overflows into the next segment
(thanks to Simon for poiting this out). If this becomes a
problem and customers rely on invalid ipv4 addresses we will
need to relax the rules but let's start strict and help our
users with more guardrails.
Note that no ipv6 validation via regex is done. The regex
on stackoverflow for validating ipv6 is 660 chars long
and that seems a bit too long for our schemas and putting
and error with that in front of our users.
This commit adds a small stage unit test and most importantly
a comemnt why `devices` is part of the schema (but appears unused).
The reason "devices" is explained by Alex Larsson:
"""
The mounts don't work without devices that have the filesystems.
In sample-images for example, this is typically used like so:
```
type: org.osbuild.ostree.post-copy
devices:
root:
type: org.osbuild.loopback
options:
filename: disk.img
mounts:
- name: root
type: org.osbuild.ext4
source: root
target: /
```
"""
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!
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.
