rfmoz
systemd-sysusers and Fedora/RHEL
Have you given any thoughts to the changes to the RPM spec file to make use of systemd-sysusers, similar to what has been done for Debian?
It should be a pretty simple change, but I'm reluctant to push it straight into Fedora without some prior testing, so I won't use it for current version.
Also, now that RHEL7 has gone, RHEL8 and on should also support it.
I've checked how systemd-sysusers apply on RPM and their doc said that it is available in Rpm >= 4.19 so Fedora 39 and later, RHEL 8 uses v4.14 and RHEL 9 v4.16, so none one.
As the current tuptime rpm package works fine and it's compatible with a large number of releases, maybe introducing sysusers could narrow the scope. I haven't done anything because of that, feel free to apply it, you know better what could be the impact.
On the Debian side, the .deb package will be updated on the official repos in a few weeks. I'm expected to monitor its progress (I hope everything goes smoothly).
What I will do is upgrade to the new version, using the current spec file, and play around with the new systemd-sysusers format in COPR after that.
It is interesting that RPM upgrade to internally support systemd-sysusers is only in Fedora, but doing an installation similar to your installation script without using the RPM macro should work on RHEL systems.
Using the attached spec file (tuptime.spec.txt), I've built and installed the package using sysusers in Fedora 40 without problem.
I followed the docu on https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/ and https://github.com/openela-main/munge/blob/el9/SPECS/munge.spec as example.
Please, could you take a look?
On a quick look, it seems to be what I saw from some of the docs you reference, although I may need to split it into the case for EPEL vs everything else that handles the new macros.
But first, I'll test it out to make sure it works as expected, and then go to handling compatibility issues with older systems.
BTW, as EPEL7 is no longer available, I guess I really only need to worry about EPEL8 & 9, which means I may strip out some of the other tests too.
Sorry I've left this for so long, but it is both because I've been busy and because Fedora devs have been discussing enforcing this creation method going forward anyway.
As such, how it is done now has simplified even more, and I'm now going to try and add it for use in F42 and maybe for the other current releases.
One thing I did notice was that in %post you no longer initialise the DB, i.e. you have lost the lines:
%post
# Create and initialise the tuptime DB with consistent permissions, etc.
su -s /bin/sh _tuptime -c "(umask 0022 && /usr/bin/tuptime -q)"
Is it deliberate or just necessary, or is it somehow covered elsewhere?
Great, don't worry.
The removal of:
%post
# Create and initialise the tuptime DB with consistent permissions, etc.
su -s /bin/sh _tuptime -c "(umask 0022 && /usr/bin/tuptime -q)"
%systemd_post tuptime.service
%systemd_post tuptime-sync.service
%systemd_post tuptime-sync.timer
it's related with the %pre section and the usage of sysusers.
As the new version lacks of useradd/groupadd and relies on sysusers, the user/group _tuptime is not available at the right time when the package is installed. If you keep that line to a testing .spec, it is executed just before user creation:
Running transaction
Preparing : 1/1
Running scriptlet: tuptime-5.2.4-2.fc40.noarch 1/1
Installing : tuptime-5.2.4-2.fc40.noarch 1/1
warning: user _tuptime does not exist - using root
warning: group _tuptime does not exist - using root
Running scriptlet: tuptime-5.2.4-2.fc40.noarch 1/1
su: user _tuptime does not exist or the user entry does not contain all the required fields
Creating group '_tuptime' with GID 993.
Creating user '_tuptime' (Tuptime execution user) with UID 993 and GID 993.
Installed:
tuptime-5.2.4-2.fc40.noarch
It doesn't matter if it is placed after the systemd calls::
%post
%systemd_post tuptime.service
%systemd_post tuptime-sync.service
%systemd_post tuptime-sync.timer
# Create and initialise the tuptime DB with consistent permissions, etc.
su -s /bin/sh _tuptime -c "(umask 0022 && /usr/bin/tuptime -q)"
Preparing : 1/1
Running scriptlet: tuptime-5.2.4-2.fc40.noarch 1/1
Installing : tuptime-5.2.4-2.fc40.noarch 1/1
warning: user _tuptime does not exist - using root
warning: group _tuptime does not exist - using root
Running scriptlet: tuptime-5.2.4-2.fc40.noarch 1/1
su: user _tuptime does not exist or the user entry does not contain all the required fields
warning: %post(tuptime-5.2.4-2.fc40.noarch) scriptlet failed, exit status 1
Error in POSTIN scriptlet in rpm package tuptime
Creating group '_tuptime' with GID 993.
Creating user '_tuptime' (Tuptime execution user) with UID 993 and GID 993.
Installed:
tuptime-5.2.4-2.fc40.noarch
Complete!
I also trying with %posttrans, but the result is equal:
warning: %posttrans(tuptime-5.2.4-2.fc40.noarch) scriptlet failed, exit status 1
Error in POSTTRANS scriptlet in rpm package tuptime
Creating group '_tuptime' with GID 993.
Creating user '_tuptime' (Tuptime execution user) with UID 993 and GID 993.
Nevertheless, when the unit is started, /var/lib/tuptime/tuptime.db is created with _tuptime:_tuptime as expected. But... if root executes tuptime before first start, the db file is created belonging to root user.
Yes, I thought that might be the case. I've seen other comments that seemed to imply the user wasn't available during the post-install scripts, so there may be no way to fix it.
However, as you noted, it probably doesn't really affect anything in normal use.
Looking at these comments, it may work properly in the near future:
> – are run after the RPM installation.
The new mechinism in rpm itself creates the accounts _before_ the rpm
is installed. (When the rpm is being built, if it has a sysusers file,
a virtual Provides is generated. When rpm sees an rpm with the Provides,
it will precreate the account.)
So yeah, having a package with a sysusers file and files owned by the
users or groups defined therein works fine. (This was already possible
before, but required careful creation of a %pre scriptlet. The new
mechanism is much nicer.)
And delving even further, this will come in with Fedora 42, which is due to be released in a few months.
It is in Fedora rawhide now, which is what I've built for, and so going forward we can actually add that initialisation back in, if you want.
However, it does look like it won't be in RHEL10, as that is rpm 4.19, which is not fully functional with these features anyway.
Well, I think that the problem is related with a corner case behaviour and it's better to be aligned with the upcoming releases.
Okay, so I'll set up the Fedora/EPEL spec file to use the old method for Fedora <= 41 and EPEL <= 10, and add back in the initialisation, and then do a PR to update your one in the distribution to match.