This mirrors the same change from 49bb7fe5f88fc35b8529d7d8dfcd4c151a9aaf1a
and 4ced52595f3e0367a0f2823be8b7acf6d7b7c2be in systemd. Instead of potentially
allocating random GIDs for the root and nobody groups, let's insist that these
have the expected GIDs.
These were added to systemd's basic.conf in
4ced52595f3e0367a0f2823be8b7acf6d7b7c2be,
49bb7fe5f88fc35b8529d7d8dfcd4c151a9aaf1a and
9361a712f85860ead532dba1468dbd3deef00e34. Let's add them to the setup
package as well to ensure we match with systemd's expected user/group
layout.
This inverts the order of operations: previously, the passwd and group
files were the original source of information, and shadow and gpasswd
were created using sed, and sysusers fragments were generated using a
shell script.
There are a few problems with the previous approach:
- We had two sysusers files, one for groups and one for users. This
split makes things more complicated. By default sysusers will create
a group with the same name and number, if a user is defined without
an explicit group override. This is what we want to do, to make the
config shorter and easier to read.
- The rpm sysusers generator created two sets of 'Provides:group(…)'
attributes.
In the new approach, we use the sysusers file as the "source of truth",
and run systemd-sysusers to generate passwd, group, shadow, and gshadow
files.
This has the following advantages:
- No code to maintain here.
- The config is easier to read.
- Toes a lint of the data. If a uid conflict was present, we'd
get a warning.
- With the support for sysusers in rpm, when we install this package on
a system, because of the Provides, rpm will create the users and groups
using systemd-sysusers anyway. So by doing the same during the build,
we match what rpm would do anyway, so we get a file that is closer to
what will actually appear in the system.
- Since we now have a file generated by systemd-sysusers in the payload,
we can see how things will actually look on the installed system.
This allowed me to notice a bug in systemd packaging.
