[Rpm-maint] [rpm-software-management/rpm] Add a man page for rpm sysusers integration (PR #4126)

[Michal Domonkos]

@dmnks commented on this pull request.



> +at installation time. This eliminates the need for the manual creation of such
+accounts in transaction scriptlets.
+
+This works implicitly if a package ships one or more files in this format under
+*%\_sysusersdir* (typically _/usr/lib/sysusers.d/_). RPM will then automatically
+invoke the *%\_\_systemd_sysusers* binary (typically *systemd-sysusers*(8)) with
+the correct arguments in order to create the user and/or group accounts when the
+package is installed. This is the recommended method on systemd native platforms
+and requires no intervention from the package beyond shipping those files.
+
+RPM also allows for declaring sysusers.d entries explicitly in the spec file
+with the *%add_sysuser* macro. This macro takes a sysusers.d line with its
+fields passed as separate arguments and must be declared in the (sub-)package
+context. This method is primarily intended for platforms without systemd where
+it is typically also coupled with a custom *%\_\_systemd_sysusers* binary (see
+*DECODING* for details).

Since we're in a philosophical mood this Friday, here's a more elaborate version of my thoughts:

My view is based on the assumption that `sysusers.d` aspires to be the way(TM) to allocate users/groups on a systemd OS. In that view, packages would ship these files like any other, and `systemd-sysusers.service` would read those files and create the specified accounts next time it activates.

Without native package manager integration, this would've worked just fine, by simply activating that service (or calling the `systemd-sysusers` tool directly) in a post-install script - similarly to the `%systemd_post` macros on Fedora, for example. Alternatively, the accounts would've been created on the next reboot of the system by that very service.

The thing is, this wouldn't suffice for those accounts that have to be created early, e.g. during the bootstrapping process, or simply when a package ships files that are to be owned by the sysusers.d accounts it also ships. That's where the package manager needs to step in and provide tight integration with this sysusers.d protocol to make it actually useful. As a bonus, this integration also removes the need to write those scriptlets in the first place, since the package manager takes over that.

And *that* is the role that I consider rpm's implementation to play here.

Now, purely from a package manager's PoV, creating users and groups can also be considered a fundamental feature, regardless of whether systemd is present or not. So it's equally as relevant on non-systemd platforms, just from a different angle (the package manager's perspective). In rpm's case, we've chosen the sysusers.d format simply because it's at hand and fits the use case perfectly.

So, putting it all together, it indeed is somewhere in between 1. and 2. :laughing:

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/4126#discussion_r2864883408
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/4126/review/3867550122 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260227/ab944a0d/attachment.htm>