On Thu, Jan 2, 2020 at 11:39 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Thu, Jan 02, 2020 at 11:15:57AM -0500, Neal Gompa wrote: > > On Thu, Jan 2, 2020 at 11:04 AM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> wrote: > > > > > > On Thu, Jan 02, 2020 at 10:29:26AM -0500, Neal Gompa wrote: > > > > 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 those cases, a separate package can be split out, similarly to any > > > other case of resources shared between packages. I didn't want to make > > > the split mandatory because I assumed that sharing a user between > > > completely independent packages is something of a fringe case... > > > (The case when there's a single "main" package and a bunch of add-on > > > packages which use the same user doesn't count here, because in that > > > case it's easy enough to define the user in the "main" package.) > > > Apart from web servers, what are the use cases? > > > > > > > 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. > > > > > > Fedora pretty much gave up on static UIDs a while back. We use "dynamic" > > > allocation pretty much all the time. Nevertheless, I don't think that > > > static vs. dynamic matters for this, since all the discussed mechanisms > > > (current useradd+groupadd, proposed mechanism, or opensuse mechanism > > > with separate packages) would give the same id allocations. > > > > > > > This is not true. > What exactly? > > > Static IDs are hard when you potentially have > > multiple packages defining the same user/group, but if they're shared > > somehow, then static IDs are easier. We do not require static IDs by > > default, and indeed most are non-static because they don't need to be > > static. But some are, because if they aren't, things break (mock, for > > example). > > I agree that static IDs have their uses. By "gave up" I only meant > that they are rarely used and new ones are rarely added, not that they > are never used. I guess we are in total agreement here? > I guess so? > > > > Moreover, the *definition* of the user+group is centralized, > > > > making it easier to audit and adjust over time. > > > > > > I don't grok this sentence. In my proposal the definition of a user is > > > a single sysusers.d file. It is owned by some specific package, and in > > > this sense the definition is centralized (unique). IIUC, opensuse has > > > a similar setup, with the main difference being that the file is shunted > > > to a separate package, i.e. there is just as much "centralization". > > > > > > > The ownership is centralized in either case, true, but officially > > supporting the case of splitting out as a package means that if > > multiple consumers of a user/group are a thing, this can be handled a > > lot more gracefully. It's pretty ugly as-is. > > I think this is rather similar to the case of packages co-owning a > directory. For that case we declare that -filesystem package can be split > out. But we do this only when it's actually useful, i.e. when multiple > packages that are fully independent require the same directory and any > of them can be installed independently of others. For the common case > this isn't necessary. > > Would it make you feel better if I added a para to the Change page saying > that the sysusers.d definition may be split out into a separate package > if desired? > Yes, it would. Guidelines for these kinds of splits should also be drafted for FPC review. > > > > 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. > > > > > > This can be added too. > > > > > > > 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.). > > > > > > I was not aware of those problems. Can you give me some pointers to > > > those issues? > > > > > > > Most of the problems I've had are related to me trying to make the > > Pagure package be more flexible (not tied to apache, etc.) while still > > having to deal with the complexities of web app packaging+deployment. > > So far, I haven't been successful to a reasonable degree of > > satisfaction, mostly because users and groups are messy. :( > > > > For $DAYJOB and a couple of other projects, I've encountered issues > > with having to support multiple providers of something, and they "own" > > directories without sharing users and groups, so depending on what is > > installed, I wind up in a situation where things don't work. > > I fully agree that there should be a single definition of the user and > group (i.e. a single package providing the sysuser.d file). > > We have guidelines how to share a directory between packages and they > work. I think we're veering off topic here into bugs in some package. > Perhaps. I just want as part of this Change some clear guidance on how to handle these scenarios, because right now we don't have any. > > > > 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. > > > > > > Sure, I don't see why not. > > > > > > > Cool. > > Zbyszek -- 真実はいつも一つ！/ 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
