On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > == Summary == > Files in sysusers.d format will be used to declare systems users so it > will be possible to introspect system users. Users will still be > created using old-style useradd calls. > > == Owner == > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in waw pl > > == Detailed Description == > > Many packages define their own user. Right now, those users are > created in %pre by calling getent, useradd, and groupadd > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > guidelines]). This will be changed to define users in the > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html > sysusers.d format]. A macro will be provided to generate a %pre > scriptlet that will call useradd and groupadd similarly to the > scriptlets that are currently required by the packaging guidelines. > > In this proposal, systemd-sysusers will not be used to create the > user. Using the sysusers.d format makes it easy to switch to > systemd-sysusers as the implementation, and to experiment with > different way to actually create the users based on the declarative > syntax. > > This approach is heavily based on OpenSUSE's > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups > guidelines]), but does not use separate rpm packages. I think using a > %pre macro is good enough. > > == Benefit to Fedora == > > System users are declared by packages using a uniform syntax. > > The scriptlet part is standardized. Current implementation of creating > users and groups is not changed, but may be switched easily in the > future. For example, for container images, the macro may be replaced > by a noop implementation, and the users created externally without > installing the user creation tools in the container. > > Admins may easily introspect the system user list and which packages > require users. > > Admins may easily override definitions of system users by providing > appropriate sysusers.d files with higher priority. > > The difference between Fedora and other distros like OpenSUSE is reduced. > While this *is* incrementally better than before, there *is* a reason for using separate RPM packages as openSUSE does. There are many cases where a user+group is actually shared across multiple packages, and having the user+group definition broken out into a subpackage means that it's easy for multiple packages to depend on it without having to depend on the program package. For example, in openSUSE, there is a wwwrun user paired with the www group (there's also a wwwrun group, but it doesn't matter quite that much). This user+group combination is used by *all* webservers. It also has a static ID, so that it's consistent across installs. Having this be a package instead of being a scriptlet run by each of the webservers means that it's easy for the webserver packages to depend on them. Moreover, the *definition* of the user+group is centralized, making it easier to audit and adjust over time. Also importantly, there's a dependency generator that generates user() and group() Provides for this, so that packages can just declare they need that user+group combo to exist first before the package can be installed. I would like us to be able to do that in Fedora too, as it would drastically simplify some of the odd issues we have with managing shared users and groups across multiple packages (web servers, language runtime environments, git services, etc.). For us, since we don't have the SUSE patches that make PreReq do things, the way we'd declare this with upstream RPM features would be: Requires: user(wwwrun) OrderWithRequires: user(wwwrun) That way, it's always installed before the package in question is. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
