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).
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.
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
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.
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.
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.
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 (Axel.Thimm@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
On Mon, May 14, 2007 at 02:30:20PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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 (Axel.Thimm@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
On Mon, May 14, 2007 at 04:47:28PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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 (Axel.Thimm@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
On Mon, May 14, 2007 at 11:23:36PM -0400, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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 (Axel.Thimm@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
On Mon, 14 May 2007, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm@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 -
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
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".
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
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".
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
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.
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
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
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.
Thorsten Leemhuis fedora@leemhuis.info 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
On Fri, May 11, 2007 at 03:09:44PM +0200, Enrico Scholz wrote:
Thorsten Leemhuis fedora@leemhuis.info 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 ...
Thorsten Leemhuis fedora@leemhuis.info 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=recall&a...
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
On 11.05.2007 14:16, Enrico Scholz wrote:
Thorsten Leemhuis fedora@leemhuis.info 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
Thorsten Leemhuis fedora@leemhuis.info 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
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@leemhuis.info 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 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@leemhuis.info 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
Thorsten Leemhuis fedora@leemhuis.info 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
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).
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
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.
Joe Orton (jorton@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
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.
Ville Skyttä (ville.skytta@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
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?
packaging@lists.fedoraproject.org
-
Axel Thimm -
Bill Nottingham -
Enrico Scholz -
Joe Orton -
Panu Matilainen -
Thorsten Leemhuis -
Ville Skyttä