overlay/sysusers: add fragments for all FCOS system groups

[lucab]

This translates all Fedora CoreOS system groups (i.e. those coming
from group manifest) into equivalent sysusers.d fragments.

We currently ship four kinds of system groups:

• basic groups coming from the /etc/group file in the setup
  package (10-groups-basic.conf)
• the legacy GID for the nobody group (00-group-nobody.conf)
• extra groups with static GIDs that adhere to the Fedora
  allocation table (10-groups-static-extra.conf)
• extra groups with static GIDs that are specific to CoreOS
  (00-groups-coreos-static.conf)

These sysusers.d fragments are meant as a transitory measure to
help migrate the existing group entries from the current nss-altfiles
setup to a plain sysusers.d world.

[lucab]

Over time we do expect to be able to drop some of these sysusers.d fragments, as more packages will start shipping their own configuration files.
This is meant to kickstart our port and to cover custom FCOS entries.
In parallel I'm tackling this from two other sides:

• adding the basic groups directly in the setup package - https://pagure.io/setup/pull-request/39
• adding translation logic for groupadd in rpm-ostree - core: wrap and intercept groupadd calls in scriptlets rpm-ostree#3778

[cgwalters]

Shouldn't we also remove these things from our static group file?

[lucab]

@cgwalters absolutely yes, likely coupled with a nss-lookup-group-use-altfiles: false knob.
But I do have the feeling there is going to be a bit of fallout once I start removing all the nss-altfiles band-aids, so I'd prefer to first land all the sysusers bits and later on switch over to them, step by step in separate PRs (so that we will have some cancellation points available, in case).

[lucab]

Just for experimenting I did try emptying out this file in #1839, and indeed there is some entanglement with rpm-ostree trying to perform group lookups at compose/install time.

[cgwalters]

Just for experimenting I did try emptying out this file in #1839, and indeed there is some entanglement with rpm-ostree trying to perform group lookups at compose/install time.

Yeah; and really this generalizes to "looking up users/groups in containers that don't run systemd-sysusers by default" - and we'll want a common story for that. I think the answer is probably "run systemd-sysusers" right? (Remembering that in doing so, we want to discard any such changes to /etc/passwd if this is part of a build process generating a layered image)

Alternatively of course, we could invent nss-sysusers, though that seems weird.

[lucab]

I realized this content isn't actually used by rpm-ostree when composing, because file overlays are only applied after all %pre and %post logic.
Moving that around in rpm-ostree seems to be causing further issues with systemd own %post scriptlet (which runs systemd-sysusers) so no point in landing this right now.

[lucab]

Specifically, I'm seeing some confusion on the side of systemd-sysusers:

systemd.post: Suggested group ID 1 for bin already used.
systemd.post: Creating group 'bin' with GID 973.

And then complains about gshadow content:

systemd.post: /etc/gshadow: Group "bin" already exists.

[travier]

It might be confused by the fact that we are requesting a group only (and not a user + group) for an existing user+group entry. Likely a bug in systemd-sysusers.

[travier]

In a sense, If you directly request a u bin 1 via sysusers, this should match both the existing user and group.

[lucab]

Tackling users has a larger impedance mismatch (e.g. on GECOS labels, where not even systemd and setup entries agree), so not approaching that right now.
And the g entries should be made working first anyway because some Fedora user entries do re-use a specific different/existing primary GID.

I think systemd-sysusers is getting confused by an apparent conflict with the primary UID of the user, I'm tracking that at systemd/systemd#24066.

[lucab]

I made good progress on all the other fronts (including packaging tweaks and rpm-ostree/systemd bugfixes), and gluing everything back together got me to a mostly-working state.
Thus we can start merging this one now, and then I'll move my focus to user entries.

We can't yet start removing user/group entries from FCOS manifests. That will need to wait till the very end, when rpm-ostree will have full support for sysusers-only mode.

[travier]

Looks sane to me but let's have someone else cross review.

[jlebon]

This looks sane to me but I wonder if it'd be useful to have a tracker issue (maybe we can re-use coreos/fedora-coreos-tracker#155, or it might be less confusing to make a separate one) with a checklist of how we're going to transition to sysusers in FCOS. That would also make it easier for folks to participate and better review things along the way. (And to replicate it in other rpm-ostree-based variants.)

We currently ship four kinds of system groups:

The descriptions there are useful; might be good in a follow-up to include them as comments in the respective drop-in files.

[lucab]

a tracker issue with a checklist of how we're going to transition to sysusers in FCOS

I'll be honest here: I think we are still quite far from that, and I'm personally not sure how to do the actual transition. So I don't have a checklist to follow along right now.

For the moment I'm just working to make sure all the configuration entries are consistent/aligned, and squashing the bugs I hit while kicking the tires.