The `nobody` user/group is special and can't be driven from a sysusers
dropin because Fedora's systemd has a compiled-in default value
for naming the overflow user that same name and that always takes
precedence.
The problem is that due to legacy and cargo-culting, we have to deal
with a bunch of systems with the `nobody` user set to 99:99 that we
can't just ignore. We need to migrate those, but for now at least to
make `--sysusers` usable in these environments, let's add a new hidden
`--nobody-99` option which defines _only_ that entry in the hardcoded
passwd/group. This _is_ respected by systemd-sysusers.
See also: https://github.com/coreos/fedora-coreos-tracker/issues/1201
See also: https://github.com/systemd/systemd/issues/7717
Not sure why but when you try to build c9s with rpm-ostree from
git main the change in [1] causes the sed commands here to exit
with a weird error:
```
sed: couldn't close stdout: Bad file descriptor
```
Let's just redirect to /dev/null for now and maybe we can drop
it longer term when c9s goes away. See also [2] where this was
reported.
[1] f4aecb9b62
[2] https://github.com/coreos/rpm-ostree/pull/5388#issuecomment-2971623787
The `set -euo pipefail` shouldn't be controversial.
The `set -x` bit is more debatable because it makes
the output more verbose but I find it helpful right
now as I comb through all sorts of details as part of
https://github.com/coreos/fedora-coreos-tracker/issues/1861.
If we care about less verbose output, I'd prefer we keep `-x` but
switched to having rpm-ostree buffer postprocess output and only dump it
if it fails.
This one doesn't make much sense to have enabled by default on systems
with image based updates because we shouldn't need a local cache of
yum repo metadata (i.e. we should just be interacting with a registry).
This works around two issues:
- First, rpm switched to reading users/groups directly for
its implementation of systemd-sysusers, which meant
it no longer reads via nss, which breaks nss-altfiles.
xref: https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-1536435351
and below.
- Second, even if that was fixed, `keylime` wants to add
its user to the group, which can't be done when it's a system
uid.
Since nothing in the OS content is owned by this group, we can
move underneath `/etc` by default.
Signed-off-by: Colin Walters <walters@verbum.org>
The versioning here was originally inherited from the Fedora CoreOS
configuration. However...the version numbering was always
overridden by coreos-assembler, so it wasn't actually used there!
Conceptually there are two things here:
- OS version
- Arbitrary date stamp
For the "OS version"...well, the closest thing we have actually
to "version of set of RPMs" is a compose today, which is expressed
in a distinct label already - at least for CentOS and RHEL.
For Fedora of course post-branching there are no "composes"
as such but just a set of floating RPMs post-release.
We have the "arbitrary date stamp" in the container image build
time already - and tooling like bootc and rpm-ostree show
both the version and the build time.
Let's significantly simplify our version numbers by just going
to "OS version".
This especially fixes the bug that we weren't setting
`releasever` anymore which just broke the version anyways.
Closes: https://gitlab.com/fedora/bootc/base-images/-/issues/40
Signed-off-by: Colin Walters <walters@verbum.org>
https://dnf.readthedocs.io/en/latest/conf_ref.html#protect-running-kernel-label
uses uname to protect the running kernel, when both the
container and the host shared the same kernel version this
blocks removing the kernel or replacing it, since on ostree
systems we only support one kernel this prevents us from
installing kernel-rt for example.
There's a crazy history around this; what we really want is
to have this reliably generated by tmpfiles.d, the handling
for which I want to move to bootc. For now let's wedge this
into finalize.d alongside the few others here.
Signed-off-by: Colin Walters <walters@verbum.org>
Motivated by trimming the package set of minimal to be smaller
to match its name.
But more generally, I think the solution most of the time we hit a
"multiple things have a provides" isn't to hardcode what we want,
but to exclude what we don't want.
Ideally of course...there'd be something like
`ProvidesDisfavored: iptables` that `iptables-legacy` could
use.
Signed-off-by: Colin Walters <walters@verbum.org>
I just saw the sqlite-shm corruption in
https://gitlab.com/redhat/centos-stream/containers/bootc/-/merge_requests/437#note_2372766792
so let's just go ahead and turn on rpmdb_normalize which
also aids the reproducibility of the rpmdb.
While we're here let's also add a long overdue "unit test" for
the rootfs. This operates as a container build that mounts
the container-under-test as part of a multi-stage build.
Signed-off-by: Colin Walters <walters@verbum.org>
This is generally useful for the same reason dpkg/rpm packages
have descriptions. But it's also specifically preparation
for the base image builder having a list operation to show
available configurations.
Signed-off-by: Colin Walters <walters@verbum.org>
We have a legacy of trying to support using e.g. kernel-rt. But
it adds complexity in the inheritance because minimal/manifest.yaml
isn't standalone, it also needs a kernel.
As part of custom base images I want to simplify this.
In order to use kernel-rt, we'll just say that you build a
minimal base, and then swap to kernel-rt as a secondary step
for now.
Signed-off-by: Colin Walters <walters@verbum.org>
The "tiers" nomenclature ended up being unhelpful since
we introduced "tier-x" which is between tier-0 and tier-1.
We also never exposed the tier naming outside of our source
code. In preparation for doing so, rename to tier-0 to
"minimal" which is a bit more descriptive.
Renaming the other images will follow.
Signed-off-by: Colin Walters <walters@verbum.org>
