First user/group handling discussion draft

[Ville Skyttä]

Hello,

The first draft about user and group handling (creation etc) is ready for 
discussion: http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups

The draft was presented in yesterday's FPC meeting, but the quick conclusion 
was that it'd be better to discuss it on list first.  The draft currently 
contains only an implementation of the all-dynamic uid/gid mapping scheme - 
more may follow later if the consensus is that other schemes are actually 
required in packages (ie. not adequately addressable outside of them).

Second user/group handling draft

[Ville Skyttä]

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.

Second user/group handling draft

[Axel Thimm]

On Thu, May 10, 2007 at 11:38:34PM +0300, 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. 
Just a recomendation and two minor bits:

o static uids/gids: They are covered, but there are semantically two
  typed of them: such that the Fedora project globally wants to define
  and such that a site admin may want to define. Both go through
  "setup", but we should mention what steps a packager needs to
  undertake if he want to officially register a uid/gid (while at the
  same time discouraging registring static id for the registration's
  sake only). Maybe something like

  "If you think that your package really requires allocation of global
  static uids/gids (because you need to hardwire these values into the
  binaries) then contact <the maintainer of "setup"? the fpc? fesco?>
  and ask for such an allocation. Only very few packages require a
  global static uid/gid, so verify that you indeed need one before
  contacting <>".

o /srv/PACKAGE: We don't want to suggest to packagers to put anything
  under /srv as this is up to the admin to specify the layout. While
  one needs to admit that this may still be controversial within
  Fedora it's safer to not mention it.

o /usr/sbin -> %{_sbindir} just as an educational measure? (Perhaps
  even rpmlint will cry if it's hardcoded?)

Other than that (and even with that): +1
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Ville Skyttä]

On Friday 11 May 2007, Axel Thimm wrote:

>    "If you think that your package really requires allocation of
> global
>    static uids/gids (because you need to hardwire these values into the
>    binaries) then contact <the maintainer of "setup"? the fpc? fesco?>
>    and ask for such an allocation. Only very few packages require a
>    global static uid/gid, so verify that you indeed need one before
>    contacting <>". 
Adding users/groups to the "setup" package in the distro is an upgrade 
problem - /etc/passwd and friends will end up as *.rpmnew so something needs 
to ensure that the users/groups get created by other means - and at that 
point, it's not clear to me that it is a good idea to have this stuff in the 
distro "setup" package any more.

>  o /srv/PACKAGE: We don't want to suggest to packagers to put
> anything
>    under /srv as this is up to the admin to specify the layout. While
>    one needs to admit that this may still be controversial within
>    Fedora it's safer to not mention it. 
Ok, removed all explicit examples, now referring to just "data directory".

>  o /usr/sbin -> %{_sbindir} just as an educational measure?
> (Perhaps
>    even rpmlint will cry if it's hardcoded?) 
Perhaps, as the shadow-utils package uses %{_sbindir} as well, changed to that 
for now.  Another option would be to require shadow-utils (like Bill 
suggested) and use pathless useradd/groupadd.

Second user/group handling draft

[Axel Thimm]

On Sat, May 12, 2007 at 12:18:09PM +0300, Ville Skyttä wrote:
>  On Friday 11 May 2007, Axel Thimm wrote:
>  
>  >   "If you think that your package really requires allocation of global
>  >   static uids/gids (because you need to hardwire these values into the
>  >   binaries) then contact <the maintainer of "setup"? the fpc?
> fesco?>
>  >   and ask for such an allocation. Only very few packages require a
>  >   global static uid/gid, so verify that you indeed need one before
>  >   contacting <>".
>  
>  Adding users/groups to the "setup" package in the distro is an upgrade 
>  problem - /etc/passwd and friends will end up as *.rpmnew 
That's everyday's Fedora setup, the first ever user you create already
modifies these, and how many users are really creating all users in
LDAP/NIS, I think in the Fedora world most are still on nss file
switch, so passwd/group are almost always user modified on each
upgrade.

We wouldn't change anything in today's procedures, we're just writing
them down.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Ville Skyttä]

On Saturday 12 May 2007, Axel Thimm wrote:
>  On Sat, May 12, 2007 at 12:18:09PM +0300, Ville Skyttä wrote:
>  > On Friday 11 May 2007, Axel Thimm wrote:
>  > >   "If you think that your package really requires allocation of global
>  > >   static uids/gids (because you need to hardwire these values into the
>  > >   binaries) then contact <the maintainer of "setup"? the fpc?
> fesco?>
>  > >   and ask for such an allocation. Only very few packages require a
>  > >   global static uid/gid, so verify that you indeed need one before
>  > >   contacting <>".
>  >
>  > Adding users/groups to the "setup" package in the distro is an upgrade
>  > problem - /etc/passwd and friends will end up as *.rpmnew 
[...]
>  We wouldn't change anything in today's procedures, we're
> just writing
>  them down. 
Note that your phrasing above mentions contacting the maintainer of the setup 
package.  This implies to me as if adding users/groups to the distro setup 
package would be a possibility.  That's certainly not today's procedure - 
there has been no user additions to /etc/passwd since RHL 6.2 (maybe even 
earlier?), and only the "lock" group was added to /etc/group in 7.2, 
otherwise no new groups in it since RHL 6.2 either.

Second user/group handling draft

[Axel Thimm]

On Sat, May 12, 2007 at 12:52:05PM +0300, Ville Skyttä wrote:
>  On Saturday 12 May 2007, Axel Thimm wrote:
>  > On Sat, May 12, 2007 at 12:18:09PM +0300, Ville Skyttä wrote:
>  > > On Friday 11 May 2007, Axel Thimm wrote:
>  > > >   "If you think that your package really requires allocation of
> global
>  > > >   static uids/gids (because you need to hardwire these values into the
>  > > >   binaries) then contact <the maintainer of "setup"? the fpc?
> fesco?>
>  > > >   and ask for such an allocation. Only very few packages require a
>  > > >   global static uid/gid, so verify that you indeed need one before
>  > > >   contacting <>".
>  > >
>  > > Adding users/groups to the "setup" package in the distro is an
> upgrade
>  > > problem - /etc/passwd and friends will end up as *.rpmnew
>  [...]
>  > We wouldn't change anything in today's procedures, we're just writing
>  > them down.
>  
>  Note that your phrasing above mentions contacting the maintainer of the setup 
>  package.  This implies to me as if adding users/groups to the distro setup 
>  package would be a possibility.  That's certainly not today's procedure - 
>  there has been no user additions to /etc/passwd since RHL 6.2 (maybe even 
>  earlier?), and only the "lock" group was added to /etc/group in 7.2, 
>  otherwise no new groups in it since RHL 6.2 either. 
Yes, you are right, but still passwd changed as well for other reasons
like the passwd field of root or home of news. So while this package
is being held rather stable (and it will continue to, we are
discouraging static uids if there is not a real need for one) there
are changes made to the files of this package.

OTOH the content of passwd are *always* modified in post install (all
passwd fields are x'd), so you never get a passwd upgrade, which is a
really bad mechanism of the "setup" package, IMHO.

Can we assume that the uid/gids < 100 were always considered sacred to
the users, e.g. only to be set/modified by the vendor and not misused
for local purposes? In other words, can we assume that these uid/gid
are under the authority of the "setup" package?

If we can answer this with yes (which IMHO we should), then we can
have "setup" upgrade passwd/group by removing all uid/gid < 100 in the
files found on the system and insert its fresh ones. This would not
only solve the issues at hand, but is an important mechanism to have
in place for the "setup" package in general.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Bill Nottingham]

Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  Can we assume that the uid/gids < 100 were always considered
> sacred to
>  the users, e.g. only to be set/modified by the vendor and not misused
>  for local purposes? In other words, can we assume that these uid/gid
>  are under the authority of the "setup" package? 
Yes, absolutely.

>  If we can answer this with yes (which IMHO we should), then we can
>  have "setup" upgrade passwd/group by removing all uid/gid < 100 in the
>  files found on the system and insert its fresh ones. This would not
>  only solve the issues at hand, but is an important mechanism to have
>  in place for the "setup" package in general. 
No, you can't. No prereqs allowed that early in the transaction.

Bill

Second user/group handling draft

[Axel Thimm]

On Mon, May 14, 2007 at 02:30:20PM -0400, Bill Nottingham wrote:
>  Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  > Can we assume that the uid/gids < 100 were always considered sacred to
>  > the users, e.g. only to be set/modified by the vendor and not misused
>  > for local purposes? In other words, can we assume that these uid/gid
>  > are under the authority of the "setup" package?
>  
>  Yes, absolutely.
>  
>  > If we can answer this with yes (which IMHO we should), then we can
>  > have "setup" upgrade passwd/group by removing all uid/gid < 100 in the
>  > files found on the system and insert its fresh ones. This would not
>  > only solve the issues at hand, but is an important mechanism to have
>  > in place for the "setup" package in general.
>  
>  No, you can't. No prereqs allowed that early in the transaction. 
prereqs? I was thinking more in the line of %post scripts that create
a new passwd/group with the most current shipped uid/gid < 100 and
save over the >= 100 uid/gids.

E.g. (untested)

# lock passwd/group file
...
# create secure tmpfiles
tmpfile_passwd=...
...
# initialize with sacred uid/gid content
cat /usr/share/setup/passwd > $tmpfile_passwd
# filter out all uid < 100 from current passwd and save them over
grep -v '^[^:]*:[^:]*:[0-9][0-9]?:' < /etc/passwd >> $tmpfile_passwd #
can also use sort -n and sed
...similar with shadow/group/gshadow
# 
cat $tmpfile_passwd > /etc/passwd
rm -f $tmpfile_passwd
...
# unlock passwd/group

That way we could always ensure that if users have installed/upgraded
setup the sacred uid/gid space will be properly under our control.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Bill Nottingham]

Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  > No, you can't. No prereqs allowed that early in the
> transaction.
>  
>  prereqs? I was thinking more in the line of %post scripts that create
>  a new passwd/group with the most current shipped uid/gid < 100 and
>  save over the >= 100 uid/gids. 
You said 'have setup upgrade'. setup cannot have scriptlets (and this
sort of thing is horribly ugly anyways.)

Bill

Second user/group handling draft

[Axel Thimm]

On Mon, May 14, 2007 at 04:47:28PM -0400, Bill Nottingham wrote:
>  Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  > > No, you can't. No prereqs allowed that early in the transaction.
>  > 
>  > prereqs? I was thinking more in the line of %post scripts that create
>  > a new passwd/group with the most current shipped uid/gid < 100 and
>  > save over the >= 100 uid/gids.
>  
>  You said 'have setup upgrade'. setup cannot have scriptlets (and this
>  sort of thing is horribly ugly anyways.) 
Well, what do you propose on how to deal with changes in passwd short
of requiring the user to run anaconda? Every age and a while there are
changes needed after all.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Bill Nottingham]

Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  > You said 'have setup upgrade'. setup cannot have
> scriptlets (and this
>  > sort of thing is horribly ugly anyways.)
>  
>  Well, what do you propose on how to deal with changes in passwd short
>  of requiring the user to run anaconda? Every age and a while there are
>  changes needed after all. 
usermod run somewhere else. It's been done before. Obviously, the answer
is 'don't break anything in the stock passwd file, and don't add things
to it.'

Bill

Second user/group handling draft

[Axel Thimm]

On Mon, May 14, 2007 at 11:23:36PM -0400, Bill Nottingham wrote:
>  Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  > > You said 'have setup upgrade'. setup cannot have scriptlets (and this
>  > > sort of thing is horribly ugly anyways.)
>  > 
>  > Well, what do you propose on how to deal with changes in passwd short
>  > of requiring the user to run anaconda? Every age and a while there are
>  > changes needed after all.
>  
>  usermod run somewhere else. It's been done before. Obviously, the answer
>  is 'don't break anything in the stock passwd file, and don't add things
>  to it.' 
Yes, but where? And do you really want to record all diffs from passwd
over time into usermod statements?
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Bill Nottingham]

Axel Thimm (Axel.Thimm(a)ATrpms.net) said: 
>  > usermod run somewhere else. It's been done before.
> Obviously, the answer
>  > is 'don't break anything in the stock passwd file, and don't add things
>  > to it.'
>  
>  Yes, but where? And do you really want to record all diffs from passwd
>  over time into usermod statements? 
Over 'the history of the world',there have been roughly *two* changes. I
really don't think it's a big deal. For example, changing the homedir
of ftp was done in either wu-ftpd or vsftpd at the time.

Bill

Second user/group handling draft

[Panu Matilainen]

On Mon, 14 May 2007, Bill Nottingham wrote:

>  Axel Thimm (Axel.Thimm(a)ATrpms.net) said:
> >> No, you can't. No prereqs allowed that early in the transaction.
> >
> > prereqs? I was thinking more in the line of %post scripts that create
> > a new passwd/group with the most current shipped uid/gid < 100 and
> > save over the >= 100 uid/gids.
>
>  You said 'have setup upgrade'. setup cannot have scriptlets (and this
>  sort of thing is horribly ugly anyways.) 
Well setup *could* use Lua-scriptlets to "do stuff." Whether it's sane or 
not in this case is another question :)

 	- Panu -

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

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 08:36:32AM +0200, Thorsten Leemhuis wrote:
>  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. 
Just as any guideline, they apply to all, and packages will need to
conform within a reasonable timeframe. It will most certainly
practically not apply anymore to FC5, since this will go EOL almost
the next day this guideline may have gotten through all instances.

>  What does this guideline mean for former Core packages that create
>  groups and users hardcoded GIDs/UIDs? 
Get the uid/gid in "setup" (which all of them already do).

>  "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: 
That's why Ville wrote "generally"

>  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? 
Yes.

>  Should that be handled by the Guideline? 
No, if they have a good reason, then it's a case-by-case situation, we
won't be able to cover every possible sane use. That's why there the
guideline talks about "*should* thus *generally* use /sbin/nologin".

>  Just wondering: Should we have some kind of "user/gid
> registry" in the
>  wiki to track packages that create users/groups? 
Maybe, but this would require the maintainer of "setup" to make
painfully sure wiki and "setup" are always in sync. The moment this
deviates we're in trouble, so if the maintainer(s) of setup can't
commit to simultaneous edits of "setup" and wiki contents, we should
better keep "setup" as the only authoritative source. Which can be
easily checked from the cvs viewer online I guess, so packagers will
be able to check rawhide allocation immediately.

>  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; 
There are no such packages other than "setup" in Ville's draft, so
it's only one place to look this up (and to modify it)

>  that workaround could be of interest for sysadmins that want to have
>  the same UIDs/GIDs everywhere. 
It's far better for them to get the "setup" src.rpm package, edit it
to their liking, and deploy their custom "setup".
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Thorsten Leemhuis]

Hi!

Thx for the answers Axel!

On 11.05.2007 12:00, Axel Thimm wrote:
>  On Fri, May 11, 2007 at 08:36:32AM +0200, Thorsten Leemhuis wrote:
> > 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.
>  Just as any guideline, they apply to all, and packages will need to
>  conform within a reasonable timeframe. It will most certainly
>  practically not apply anymore to FC5, since this will go EOL almost
>  the next day this guideline may have gotten through all instances. 
Side note: Who makes sure stuff gets enforced? FESCO and EPEL SIG? It
generally seems to me hat some of the package guideline changes don't
get applied to existing packages (or only the devel branch) because no
one enforces them. The FPC, FESCO and EPEL SIG probably need to work
something out together to improve that in the future. Especially for
EPEL due to it's long life-time things might get complicated if we
enforce new rules to existing packages for released branches.

But that's a different discussion we probably should not open here and now.

> > Just wondering: Should we have some kind of "user/gid
> registry" in the
> > wiki to track packages that create users/groups?
>  Maybe, but this would require the maintainer of "setup" to make
>  painfully sure wiki and "setup" are always in sync. The moment this
>  deviates we're in trouble, so if the maintainer(s) of setup can't
>  commit to simultaneous edits of "setup" and wiki contents, we should
>  better keep "setup" as the only authoritative source. Which can be
>  easily checked from the cvs viewer online I guess, so packagers will
>  be able to check rawhide allocation immediately. 
Agreed. But sysadmins need to have a list of all possible users accounts
somewhere afaics, otherwise it will be hard for them to modify setup (or
am I missing something?). Maybe we could maintain such a list somewhere
inside the setup rpm or it's cvs?

Cu
knurd

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 12:37:57PM +0200, Thorsten Leemhuis wrote:
>  Side note: Who makes sure stuff gets enforced? FESCO and EPEL SIG?
Yes. The fpc is just the legislative and fesco is the judicial and
executive with veto rights over the legislative's outcome. ;)

>  It generally seems to me hat some of the package guideline changes
>  don't get applied to existing packages (or only the devel branch)
>  because no one enforces them. The FPC, FESCO and EPEL SIG probably
>  need to work something out together to improve that in the
>  future. Especially for EPEL due to it's long life-time things might
>  get complicated if we enforce new rules to existing packages for
>  released branches.
>  
>  But that's a different discussion we probably should not open here and now. 
I agree, the fpc or the packaging discussion is less suited on topics
about hunting down bad & lazy packagers. FWIW until now it was a
cooperative work of the contributors, I hope it doesn't need to change
in the future. But whatever punishment methods against lazyness will
be envised they would not appear in the guidelines ;)

>  >> Just wondering: Should we have some kind of "user/gid
> registry" in the
>  >> wiki to track packages that create users/groups?
>  > Maybe, but this would require the maintainer of "setup" to make
>  > painfully sure wiki and "setup" are always in sync. The moment this
>  > deviates we're in trouble, so if the maintainer(s) of setup can't
>  > commit to simultaneous edits of "setup" and wiki contents, we should
>  > better keep "setup" as the only authoritative source. Which can be
>  > easily checked from the cvs viewer online I guess, so packagers will
>  > be able to check rawhide allocation immediately.
>  
>  Agreed. But sysadmins need to have a list of all possible users accounts
>  somewhere afaics, otherwise it will be hard for them to modify setup (or
>  am I missing something?). Maybe we could maintain such a list somewhere
>  inside the setup rpm or it's cvs? 
The list *is* part of "setup": passwd and group are *the*
authoritative source and uidgid is a documented registry which already
has to be manually maintained. So a wiki entry would make three
different manually to maintain master lists.

Unfortunately "setup" contents in cvs are "tarball-protected", but
you
could ask the maintainer(s) (officially Phil, but Bill is the uid/gid
man) to keep these 20 files out of the tarball for the sake of online
viewing of the latest bits. It would also make it easier for
customizing "setup".
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Thorsten Leemhuis]

On 11.05.2007 13:01, Axel Thimm wrote:
>  On Fri, May 11, 2007 at 12:37:57PM +0200, Thorsten Leemhuis wrote:
>
> > But that's a different discussion we probably should not open here and now.
>  I agree, the fpc or the packaging discussion is less suited on topics
>  about hunting down bad & lazy packagers. FWIW until now it was a
>  cooperative work of the contributors, I hope it doesn't need to change
>  in the future. But whatever punishment methods against lazyness will
>  be envised they would not appear in the guidelines ;) 
Well, some "punishment methods" might be needed -- but I'm had mainly
stuff like scripts in mind, that simply change spec files
(semi-)automatically. Or a kind of QA-gang, that makes adjustments where
needed.

> >>> Just wondering: Should we have some kind of
> "user/gid registry" in the
> >>> wiki to track packages that create users/groups?
> >> Maybe, but this would require the maintainer of "setup" to make
> >> painfully sure wiki and "setup" are always in sync. The moment this
> >> deviates we're in trouble, so if the maintainer(s) of setup can't
> >> commit to simultaneous edits of "setup" and wiki contents, we should
> >> better keep "setup" as the only authoritative source. Which can be
> >> easily checked from the cvs viewer online I guess, so packagers will
> >> be able to check rawhide allocation immediately.
> > Agreed. But sysadmins need to have a list of all possible users accounts
> > somewhere afaics, otherwise it will be hard for them to modify setup (or
> > am I missing something?). Maybe we could maintain such a list somewhere
> > inside the setup rpm or it's cvs?
>  The list *is* part of "setup":  
Seems we don't understand each other here :-/

So I'm trying it in a different way: say I'm a sysadmin and I want to
have the same static UIDs and GIDs on all my systems for *all* Fedora
packages that create UIDs or GIDs during install. I need a list of
groupnames and usernames such packages might create to prepare a
modified setup package.

So we need to have a kind of list like this somewhere:

||package||groupname||username||
||clamav||clamavfoo||clamavbar||
||zaptel||zaptelfoo||zaptelbar||

Then I as a sysadmin could easily create a modified setup.rpm with
static UID and GIDs in case clamav or zaptel get installed sooner or
later. Without such a list it would be really hard to modify setup.

CU
thl

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote:
>  >>>> Just wondering: Should we have some kind of
> "user/gid registry" in the
>  >>>> wiki to track packages that create users/groups? 
>  Seems we don't understand each other here :-/
>  
>  So I'm trying it in a different way: say I'm a sysadmin and I want to
>  have the same static UIDs and GIDs on all my systems for *all* Fedora
>  packages that create UIDs or GIDs during install. I need a list of
>  groupnames and usernames such packages might create to prepare a
>  modified setup package. 
I understand, I thought you wanted to have an official registry for
uid/gid mappings, but you just want to know which user/groups exist at
all.

>  Then I as a sysadmin could easily create a modified setup.rpm with
>  static UID and GIDs in case clamav or zaptel get installed sooner or
>  later. Without such a list it would be really hard to modify setup. 
I think if the site admin does not know what users/groups he would
like to sync across his site, then he doesn't really need to sync
them.

The site syncing makes sense when

o mixing different Linuxes/Unices (but there you have even worse
  problems like different user/group splitting, so this use case is
  hardly worth going through troubles anyway)

o or sharing package controlled parts over the network (like apache owned
  nfs shares). In these cases the admin has to know beforehand what his
  setup requires from a uid/gid POV, since these setups are his unique,
  custom deployment.

So instead of requiring from all packagers that creat a group to
maintain a list, which 10% won't do no matter what punishment you will
threaten and being poked on bad quality by the site admins that think
that Fedora should design their customized setups, have them (the
admins) do their work and really think and design about their
deployment including which user/groups they might need.

But maybe the following can make you happy: A script that greps
through the CVS and extracts these for you automatically. so no
hunting down bad and lazy packagers and a rather up to date table to
weekly import into the wiki. But that's not something we would mention
in the guidelines.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Thorsten Leemhuis]

On 11.05.2007 14:04, Axel Thimm wrote:
>  On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote:
> >
> > So I'm trying it in a different way: say I'm a sysadmin and I want to
> > have the same static UIDs and GIDs on all my systems for *all* Fedora
> > packages that create UIDs or GIDs during install. I need a list of
> > groupnames and usernames such packages might create to prepare a
> > modified setup package.
>  I understand, I thought you wanted to have an official registry for
>  uid/gid mappings, but you just want to know which user/groups exist at
>  all. 
Yes.

>  [...]
>  But maybe the following can make you happy: A script that greps
>  through the CVS and extracts these for you automatically. 
If that works: sure. But we should not force sysadmins to download the
whole cvs and run such a script -- we instead should autogenerate and
upload it somewhere IMHO.

>  But that's not something we would mention in the guidelines.
Agreed.

CU
thl

Second user/group handling draft

[Thorsten Leemhuis]

On 11.05.2007 14:18, Thorsten Leemhuis wrote:
>  On 11.05.2007 14:04, Axel Thimm wrote:
> > On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote:
> > But that's not something we would mention in the guidelines.
>  Agreed. 
Or better: Agreed if someone creates such a script. Otherwise I'm for
the wiki solution for now, and then it should be mentioned in the
guidelines.

Sure, some packagers will forget to update the wiki now and then, but
that what we have the review for. And even if now and then a package
gets forgotten: that happens, will get noticed, and then can easily get
added to the wiki.

CU
thl

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 02:18:22PM +0200, Thorsten Leemhuis wrote:
>  On 11.05.2007 14:04, Axel Thimm wrote:
>  > On Fri, May 11, 2007 at 01:40:21PM +0200, Thorsten Leemhuis wrote:
>  >>
>  >> So I'm trying it in a different way: say I'm a sysadmin and I want to
>  >> have the same static UIDs and GIDs on all my systems for *all* Fedora
>  >> packages that create UIDs or GIDs during install. I need a list of
>  >> groupnames and usernames such packages might create to prepare a
>  >> modified setup package.
>  > I understand, I thought you wanted to have an official registry for
>  > uid/gid mappings, but you just want to know which user/groups exist at
>  > all.
>  
>  Yes.
>  
>  > [...]
>  > But maybe the following can make you happy: A script that greps
>  > through the CVS and extracts these for you automatically.
>  
>  If that works: sure. But we should not force sysadmins to download the
>  whole cvs and run such a script -- we instead should autogenerate and
>  upload it somewhere IMHO. 
Yes, that's what I meant.

>  > But that's not something we would mention in the
> guidelines.
>  
>  Agreed. 
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Enrico Scholz]

Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:

> > But maybe the following can make you happy: A script that greps
> > through the CVS and extracts these for you automatically.
>
>  If that works: sure. But we should not force sysadmins to download the
>  whole cvs and run such a script 
Before I see such a script I do not believe that a such one is possible.
E.g. please extract the needed information (username, homedir, gecos)
from:

| %global user foo
| %global home %_var/lib/%name
|
| %post
| useradd -r -d '%home' %user
|
| u='%user'
| prog=/usr/sbin/useradd
| $prog -r \
|   $u



Enrico

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 03:09:44PM +0200, Enrico Scholz wrote:
>  Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:
>  
>  >> But maybe the following can make you happy: A script that greps
>  >> through the CVS and extracts these for you automatically.
>  >
>  > If that works: sure. But we should not force sysadmins to download the
>  > whole cvs and run such a script
>  
>  Before I see such a script I do not believe that a such one is possible. 
There is a proposed guideline that says how to create users/groups. Of
course we can obscure anything so that one can't even read off the
Name: tag of the package ...
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Enrico Scholz]

Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:

>  So I'm trying it in a different way: say I'm a sysadmin and I
> want to
>  have the same static UIDs and GIDs on all my systems for *all* Fedora
>  packages that create UIDs or GIDs during install. I need a list of
>  groupnames and usernames such packages might create to prepare a
>  modified setup package.
>
>  So we need to have a kind of list like this somewhere:
>
>  ||package||groupname||username||
>  ||clamav||clamavfoo||clamavbar||
>  ||zaptel||zaptelfoo||zaptelbar|| 
Such a list exists already:

  http://fedoraproject.org/wiki/PackageUserRegistry

Additional requirements (full 'useradd' commandline, delay of 7-14 days
before pushing into repos) are given in

  http://fedoraproject.org/wiki/PackagingDrafts/UsersAndGroups?action=recal...


Using wrappers like 'fedora-usermgmt' will make life of admins easier
because they have to configure their system only once instead of updating
their 'setup' package regularly.



Enrico

Second user/group handling draft

[Thorsten Leemhuis]

On 11.05.2007 14:16, Enrico Scholz wrote:
>  Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:
>  
> > So I'm trying it in a different way: say I'm a sysadmin and I want to
> > have the same static UIDs and GIDs on all my systems for *all* Fedora
> > packages that create UIDs or GIDs during install. I need a list of
> > groupnames and usernames such packages might create to prepare a
> > modified setup package.
> > So we need to have a kind of list like this somewhere:
> > ||package||groupname||username||
> > ||clamav||clamavfoo||clamavbar||
> > ||zaptel||zaptelfoo||zaptelbar||
>  Such a list exists already:
>    http://fedoraproject.org/wiki/PackageUserRegistry 
It misses username and groupname -- those would be needed for the
proposed solution. And the list only contains packages that use
fedora-usermgmt.

>  [...]
>  Using wrappers like 'fedora-usermgmt' will make life of admins easier
>  because they have to configure their system only once instead of updating
>  their 'setup' package regularly. 
Maybe. But it seems it made lots of people really unhappy, so something
is wrong somewhere.

/me prefers not to comment more then the above -- I leave the user/group
handling stuff to the packaging committee and trust it to make a good
decision

CU
thl

Second user/group handling draft

[Enrico Scholz]

Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:

> >> So we need to have a kind of list like this somewhere:
> >> ||package||groupname||username||
> >> ||clamav||clamavfoo||clamavbar||
> > Such a list exists already:
> >   http://fedoraproject.org/wiki/PackageUserRegistry
>
>  It misses username and groupname 
You mean supplementary groups? They are not listed in your proposal
either and afais, they are not covered by the draft either. Packagers
will have to execute

| usermod -a -G <sup-group> <user>

They MUST NOT be set by 'useradd -G ...'


Else, imo there is no special reason to distinguish between users and
groups in the table. It does not cost extra when you need only one but
register both.



EnricoOB

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 02:32:57PM +0200, Thorsten Leemhuis wrote:
>  On 11.05.2007 14:16, Enrico Scholz wrote:
>  > Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:
>  > Using wrappers like 'fedora-usermgmt' will make life of admins easier
>  > because they have to configure their system only once instead of updating
>  > their 'setup' package regularly. 
Well, 'fedora-usermgmt' is a masterpiece of marketing: Promising the
best of static and dynamic uid/gid and delivering the worst ;)

>  Maybe. But it seems it made lots of people really unhappy, so
> something
>  is wrong somewhere. 
The I wonder why you voted for keeping it.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Thorsten Leemhuis]

Axel Thimm schrieb:
>  On Fri, May 11, 2007 at 02:32:57PM +0200, Thorsten Leemhuis wrote:
> > On 11.05.2007 14:16, Enrico Scholz wrote:
> >> Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:
> >> Using wrappers like 'fedora-usermgmt' will make life of admins easier
> >> because they have to configure their system only once instead of updating
> >> their 'setup' package regularly.
>  Well, 'fedora-usermgmt' is a masterpiece of marketing: Promising the
>  best of static and dynamic uid/gid and delivering the worst ;) 
You should be aware that some people think different about
fedora-usermgmt. Especially as Enrico is the creator of fedora-usermgmt.
So please be a bit more diplomatic and avoid such flamebits, as that
might help to avoid yet another flamewar.

> > Maybe. But it seems it made lots of people really unhappy, so
> something
> > is wrong somewhere.
>  The I wonder why you voted for keeping it. 
In EPEL? I didn't want rules for packaging to be different between
Fedora and EPEL.

CU
thl

Second user/group handling draft

[Enrico Scholz]

Thorsten Leemhuis <fedora(a)leemhuis.info&gt; writes:

> > Using wrappers like 'fedora-usermgmt' will make life of
> admins easier
> > because they have to configure their system only once instead of
> > updating their 'setup' package regularly.
>
>  Maybe. But it seems it made lots of people really unhappy, so something
>  is wrong somewhere. 
Yep... although 'fedora-usermgmt' delivers the best of of static and
dynamic uid/gid, it has an horrible marketing :(


Enrico

Second user/group handling draft

[Ville Skyttä]

On Friday 11 May 2007, Thorsten Leemhuis wrote:

>  Agreed. But sysadmins need to have a list of all possible users
> accounts
>  somewhere afaics, otherwise it will be hard for them to modify setup (or
>  am I missing something?). Maybe we could maintain such a list somewhere
>  inside the setup rpm or it's cvs? 
I do think such a list would be a good thing, not only because of the above, 
but it could also be helpful in the case where a same-named user/group exists 
beforehand for an unrelated purpose (the last paragraph in the draft).

Second user/group handling draft

[Joe Orton]

On Thu, May 10, 2007 at 11:38:34PM +0300, 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. 
Is it really a good idea to run /bin/id in scriptlets?  Depending on 
nsswitch configuration, couldn't this block waiting for NIS/etc lookups?

(though maybe the same is true of useradd; I've always wondered whether 
it would be better to be using l{user,group}add instead)

joe

Second user/group handling draft

[Axel Thimm]

On Fri, May 11, 2007 at 11:42:39AM +0100, Joe Orton wrote:
>  On Thu, May 10, 2007 at 11:38:34PM +0300, 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.
>  
>  Is it really a good idea to run /bin/id in scriptlets?  Depending on 
>  nsswitch configuration, couldn't this block waiting for NIS/etc lookups? 
You do have a point there, but the same is true for a simple ls -l
command, so if NIS is in trouble rpm installs/upgrades will be the
least that break, and they do break in %pre, e.g. there is no harm
done.
-- 
Axel.Thimm at ATrpms.net

Second user/group handling draft

[Bill Nottingham]

Joe Orton (jorton(a)redhat.com) said: 
>  > 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.
>  
>  Is it really a good idea to run /bin/id in scriptlets?  Depending on 
>  nsswitch configuration, couldn't this block waiting for NIS/etc lookups? 
Why not just check the exit status of useradd? There is a specific
exit status for 'user already exists'.

I'm of the opinion that we should handle static IDs by just assigning
static IDs up to 500 for everything. That's orthogonal to this, though.

Bill

Second user/group handling draft

[Ville Skyttä]

On Friday 11 May 2007, Bill Nottingham wrote:

>  Why not just check the exit status of useradd? There is a specific
>  exit status for 'user already exists'. 
Possible, but would result in quite a bit of "useradd: user foo exists" noise 
on package upgrades or more complicated %pre scriptlets that filter out this 
particular error message but let others through.  useradd would benefit from 
an option similar to groupadd's -f.

Second user/group handling draft

[Bill Nottingham]

Ville Skyttä (ville.skytta(a)iki.fi) said: 
>  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. 
Requiring shadow-utils as opposed to /usr/sbin/{user,group}add cuts down
on a layer of indirection when resolving deps.

Bill

Second user/group handling draft

[Ville Skyttä]

On Friday 11 May 2007, Bill Nottingham wrote:
>  Requiring shadow-utils as opposed to /usr/sbin/{user,group}add cuts down
>  on a layer of indirection when resolving deps. 
Sure, but it also introduces an indirection within the specfile as we'd no 
longer have explicit scriptlet dependencies to executables being used in 
them.  I think this is somewhat frowned upon, but I can't find a guideline 
reference right now.

BTW, somehow I feel that if the dependency would be on shadow-utils, it'd be 
more natural to also invoke useradd/groupadd from $PATH without 
hardwired /usr/sbin (or %{_sbindir}).  Anyone else have the same feeling?