[Fedora-packaging] Second user/group handling draft

[Thorsten Leemhuis]

On 10.05.2007 22:38, Ville Skyttä wrote:
> On Wednesday 25 April 2007, I wrote:
> 
>> The first draft about user and group handling (creation etc) is ready for
>> discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups
> 
> As noted in this week's FPC meeting minutes, the draft is probably going to be 
> voted on next week.  A more fleshed out and cleaned up version which also 
> takes into account some findings in the FPC meeting as well as other feedback 
> on -maintainers is now online.  Comments still welcome.

Thx for writing this up; some comments (if they were discussed already
then sorry for the noise):

----

I'd like to see clarifications somewhere for which existing branches we
applies this/what it means to existing packages that use some magic
tools to create users and groups currently.

This probably should be tracked in a separate document, to not mix up
"general good packaging standards" with packaging in practice for
Fedora/EPEL.

----

What does this guideline mean for former Core packages that create
groups and users hardcoded GIDs/UIDs?


----

"User accounts created by packages are rarely used for interactive
logons, and should thus generally use /sbin/nologin as the user's shell."

What about those core packages that don't follow this? My system has some:

sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
news:x:9:13:news:/etc/news:
netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash

I suspect there are more in former Core packages. Do they have a good
reason for their doings maybe? Should that be handled by the Guideline?


----

Just wondering: Should we have some kind of "user/gid registry" in the
wiki to track packages that create users/groups? Then sysadmins could
create a fedora-meta-users-and-groups package in their private repo that
creates all the users and groups that Fedora packages might create
beforeband with static numbers; that workaround could be of interest for
sysadmins that want to have the same UIDs/GIDs everywhere.

----

CU
knurd