Is there an official policy for what packages that add users for their processes to run as ought to do? I notice the recent clamav package still uses fedora-usrmgmt, but I can't find any reference to that in the current wiki, and that package still has the obsolete fedora.us wiki as its URL.
What's the Right Thing here?
On Fri, 2005-07-01 at 16:47 -0400, Matthew Miller wrote:
Is there an official policy for what packages that add users for their processes to run as ought to do? I notice the recent clamav package still uses fedora-usrmgmt, but I can't find any reference to that in the current wiki, and that package still has the obsolete fedora.us wiki as its URL.
What's the Right Thing here?
It seems like all fedora-usermgmt was doing is as follows:
- Reserve a UID for a package to use. - Add 30000 to that UID.
Why don't we just have packagers request a UID for a package on a wiki page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the normal tools to create the user.
Alternately, we could just keep using fedora-usermgmt. I'd assume it made its way into the FE repo, since clamav is using it? We just need to migrate the wiki pages.
~spot
On Fri, Jul 01, 2005 at 06:51:50PM -0500, Tom 'spot' Callaway wrote:
- Reserve a UID for a package to use.
- Add 30000 to that UID.
Why don't we just have packagers request a UID for a package on a wiki page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the normal tools to create the user.
While I'm in favor of just having a registry rather than the added complication of the wrapper tool, I'd really, really, really like to use a different range, because those 30000-range UIDs already belong to people at BU and it will make using Fedora a Vast Pain.
Since Extras is now "not a second class citizen", maybe we could use something in the 100-499 numbers?
On Fri, 2005-07-01 at 22:35 -0400, Matthew Miller wrote:
On Fri, Jul 01, 2005 at 06:51:50PM -0500, Tom 'spot' Callaway wrote:
- Reserve a UID for a package to use.
- Add 30000 to that UID.
Why don't we just have packagers request a UID for a package on a wiki page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the normal tools to create the user.
While I'm in favor of just having a registry rather than the added complication of the wrapper tool, I'd really, really, really like to use a different range, because those 30000-range UIDs already belong to people at BU and it will make using Fedora a Vast Pain.
Since Extras is now "not a second class citizen", maybe we could use something in the 100-499 numbers?
+1.
agreed. let's keep the range low - and in the area we expect to be for 'system accounts'
-sv
On Fri, 2005-07-01 at 22:35 -0400, Matthew Miller wrote:
On Fri, Jul 01, 2005 at 06:51:50PM -0500, Tom 'spot' Callaway wrote:
- Reserve a UID for a package to use.
- Add 30000 to that UID.
Why don't we just have packagers request a UID for a package on a wiki page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the normal tools to create the user.
While I'm in favor of just having a registry rather than the added complication of the wrapper tool, I'd really, really, really like to use a different range, because those 30000-range UIDs already belong to people at BU and it will make using Fedora a Vast Pain.
Since Extras is now "not a second class citizen", maybe we could use something in the 100-499 numbers?
+1
In standard configurations, this also avoid these accounts infecting yppasswd uid-space (The standard yp config in Fedora use MINUID=500)
Ralf
mattdm@mattdm.org (Matthew Miller) writes:
While I'm in favor of just having a registry rather than the added complication of the wrapper tool, I'd really, really, really like to use a different range, because those 30000-range UIDs already belong to people at BU and it will make using Fedora a Vast Pain.
As told in another posting,
| echo 63000 >/etc/fedora/usermgmt/basegid | echo 63000 >/etc/fedora/usermgmt/baseuid
would change the used range to 63000-....
But somebody seems to have configured it already as:
* the predefined base-ids are '300' in the fedora-usermgmt-setup package * the 'predictable uid' mechanism is turned off by default and users will be created dynamically. You have to turn it on explicitly by
| /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils
Enrico
On Sat, Jul 02, 2005 at 10:08:34AM +0200, Enrico Scholz wrote:
As told in another posting,
| echo 63000 >/etc/fedora/usermgmt/basegid | echo 63000 >/etc/fedora/usermgmt/baseuid
would change the used range to 63000-....
We're already using those too. As I imagine a lot of large instituations are.
But somebody seems to have configured it already as:
- the predefined base-ids are '300' in the fedora-usermgmt-setup package
- the 'predictable uid' mechanism is turned off by default and users will be created dynamically. You have to turn it on explicitly by
Hmmm. I think we *do* need some consistent system.
tcallawa@redhat.com ("Tom 'spot' Callaway") writes:
Is there an official policy for what packages that add users for their processes to run as ought to do? I notice the recent clamav package still uses fedora-usrmgmt, but I can't find any reference to that in the current wiki, and that package still has the obsolete fedora.us wiki as its URL.
What's the Right Thing here?
Good question... IMO, in mid- to longterm, this should be abstracted by some rpm mechanism. Another question might be whether created users shall be removed at package removal or not.
It seems like all fedora-usermgmt was doing is as follows:
- Reserve a UID for a package to use.
- Add 30000 to that UID.
Not exactly 30000... but see below.
Why don't we just have packagers request a UID for a package on a wiki page, starting at 30012 (fedora.us had 30000 - 30011)? Then, use the normal tools to create the user.
That's not possible. Only the range 0-99 is reserved for fixed user ids. All other ranges are free for local uses. For example the range 100-499 mentioned in another posting: every third party package which adds user, or just a simple 'useradd -r' will assign the next unused uid in this area. So you can not assign fixed UIDs in this range as it *will* cause conflicts.
Using another UID range will be similarly; it may be/is possible that this range is used on some system.
That's why, fedora-usermgmt was written. It creates an UID relative to a configurable base (the value in /etc/fedora/usermgmt/base[gu]id). How you fill an entry into this file is your thing... I use cfengine for it and it works well.
Alternately, we could just keep using fedora-usermgmt. I'd assume it made its way into the FE repo, since clamav is using it?
I created it for other packages also. See
http://www.fedora.us/wiki/PackageUserRegistry
for list of packages and
http://www.fedora.us/wiki/PackageUserCreation http://www.fedora.us/wiki/PackageDynamicUserCreationConsideredBad
for other information about fedora-usermgmt.
Enrico
On Sat, Jul 02, 2005 at 10:01:26AM +0200, Enrico Scholz wrote:
That's not possible. Only the range 0-99 is reserved for fixed user ids. All other ranges are free for local uses. For example the range 100-499 mentioned in another posting: every third party package which adds user, or just a simple 'useradd -r' will assign the next unused uid in this area. So you can not assign fixed UIDs in this range as it *will* cause conflicts.
Using another UID range will be similarly; it may be/is possible that this range is used on some system.
Yes, but the range under 500 is already defined as "special". I don't think it's unreasonable for a certain subset of that to be now marked as reserved for Fedora Extras packages. We could make it start at 300 to be less likely to conflict with random "useradd -r" done earlier.
(Does useradd -r still use the wacky logic of picking the next-highest UID instead of the lowest available? That should be fixed if so -- I have a patch to change the general behavior but haven't checked if useradd -r follows its own logic.)
That's why, fedora-usermgmt was written. It creates an UID relative to a configurable base (the value in /etc/fedora/usermgmt/base[gu]id). How you fill an entry into this file is your thing... I use cfengine for it and it works well.
We can't have a *default* that breaks in large environments. I guess I'm not terribly opposed to continuing to use the abstraction tools so someone can pick another range if they've already got many non-standard system accounts.
On Sat, 2005-07-02 at 09:44 -0400, Matthew Miller wrote:
(Does useradd -r still use the wacky logic of picking the next-highest UID instead of the lowest available? That should be fixed if so -- I have a patch to change the general behavior but haven't checked if useradd -r follows its own logic.)
If you are going to patch useradd with the -r switch - can it also be changed to use a group ID that matches the UID?
Fedora installs a group with group ID 100 but no user with uid 100 so when you use useradd with the -r switch, you end up with a different uid/gid - which isn't a functional problem, but isn't how other pairs of user/group are done.
I filed an RFE bug on that some time ago, it doesn't appear to have been acted on however.
mattdm@mattdm.org (Matthew Miller) writes:
That's not possible. Only the range 0-99 is reserved for fixed user ids. All other ranges are free for local uses. For example the range 100-499 mentioned in another posting: every third party package which adds user, or just a simple 'useradd -r' will assign the next unused uid in this area. So you can not assign fixed UIDs in this range as it *will* cause conflicts.
Using another UID range will be similarly; it may be/is possible that this range is used on some system.
Yes, but the range under 500 is already defined as "special". I don't think it's unreasonable for a certain subset of that to be now marked as reserved for Fedora Extras packages. We could make it start at 300 to be less likely to conflict with random "useradd -r" done earlier.
Assigning fixed IDs in this range would violate LSB which states
| The system User IDs from 100 to 499 should be reserved for dynamic | allocation by system administrators and post install scripts using | useradd. [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html]
That's why it would be a bad idea when Fedora Extras claims fixed UIDs there. I agree with you that every large organisation has its assigned UID ranges and it will not be possible to find a free range which can be assigned to Fedora Extras.
Perhaps we could find such a range in the 32bit UID space which is allowed by Linux; but I am not sure whether we cause portability problems.
Enrico
On Sun, Jul 03, 2005 at 12:08:32PM +0200, Enrico Scholz wrote:
for Fedora Extras packages. We could make it start at 300 to be less likely to conflict with random "useradd -r" done earlier.
Assigning fixed IDs in this range would violate LSB which states
| The system User IDs from 100 to 499 should be reserved for dynamic | allocation by system administrators and post install scripts using | useradd. [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html]
Well, that leaves us with stuffing Extras system UIDs into 0-99, or violating the above-500 space, which is worse. Note that the LSB doesn't say "must" -- it says "should", so it's a recommendation, not a requirement. Since we've got a need that's not really covered, goint against this recommendation is better than having the worse problem of dynamic system IDs (a nightmare for upgrades and for enterprise deployment).
That's why it would be a bad idea when Fedora Extras claims fixed UIDs there. I agree with you that every large organisation has its assigned UID ranges and it will not be possible to find a free range which can be assigned to Fedora Extras.
Perhaps we could find such a range in the 32bit UID space which is allowed by Linux; but I am not sure whether we cause portability problems.
OpenAFS makes this same (wrong) assumption that the higher numbers present some sort of unused dumping ground. The 32-bit UID space isn't a bunch of secret numbers for fun to play with. It's needed because some places actually require that many accounts. Let's not go there.
On Sun, 2005-07-03 at 09:43 -0400, Matthew Miller wrote:
On Sun, Jul 03, 2005 at 12:08:32PM +0200, Enrico Scholz wrote:
for Fedora Extras packages. We could make it start at 300 to be less likely to conflict with random "useradd -r" done earlier.
Assigning fixed IDs in this range would violate LSB which states
| The system User IDs from 100 to 499 should be reserved for dynamic | allocation by system administrators and post install scripts using | useradd. [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html]
Well, that leaves us with stuffing Extras system UIDs into 0-99, or violating the above-500 space, which is worse. Note that the LSB doesn't say "must" -- it says "should", so it's a recommendation, not a requirement. Since we've got a need that's not really covered, goint against this recommendation is better than having the worse problem of dynamic system IDs (a nightmare for upgrades and for enterprise deployment).
I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. Starting at 300 seems sensible, to give FC some room.
~spot
On Jul 3, 2005, "Tom 'spot' Callaway" tcallawa@redhat.com wrote:
I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. Starting at 300 seems sensible, to give FC some room.
Erhm... But what about all those existing user bases introduced when only the range below 100 was reserved? My uid at the uni has been 404 since 1991. FWIW, it wasn't an HTTP error code back then, to the best of my knowledge; it was just the number right after 403.
On Sun, Jul 03, 2005 at 04:42:40PM -0300, Alexandre Oliva wrote:
Erhm... But what about all those existing user bases introduced when only the range below 100 was reserved? My uid at the uni has been 404 since 1991. FWIW, it wasn't an HTTP error code back then, to the best of my knowledge; it was just the number right after 403.
How long ago was that? If I remember right, the default start number in Red Hat Linux 4.2 was 500....
But anyway, there's not enough room below 100, so something has to give.
On Jul 3, 2005, Matthew Miller mattdm@mattdm.org wrote:
On Sun, Jul 03, 2005 at 04:42:40PM -0300, Alexandre Oliva wrote:
Erhm... But what about all those existing user bases introduced when only the range below 100 was reserved? My uid at the uni has been 404 since 1991. FWIW, it wasn't an HTTP error code back then, to the best of my knowledge; it was just the number right after 403.
How long ago was that? If I remember right, the default start number in Red Hat Linux 4.2 was 500....
That's no use if you created the userbase on say SunOS 4.0.
But anyway, there's not enough room below 100, so something has to give.
Which is exactly why making it configurable is a good idea IMHO.
On Sun, 2005-07-03 at 16:42 -0300, Alexandre Oliva wrote:
On Jul 3, 2005, "Tom 'spot' Callaway" tcallawa@redhat.com wrote:
I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. Starting at 300 seems sensible, to give FC some room.
Erhm... But what about all those existing user bases introduced when only the range below 100 was reserved? My uid at the uni has been 404 since 1991. FWIW, it wasn't an HTTP error code back then, to the best of my knowledge; it was just the number right after 403.
Yes - and I had users who had uid's of 10 b/c they started out on ultrix and sunos.
sucks to be in that situation. Change your uid and chown all your files. This is the nature of legacy. At some point it has to change.
-sv
On Sun, 2005-07-03 at 16:42 -0300, Alexandre Oliva wrote:
On Jul 3, 2005, "Tom 'spot' Callaway" tcallawa@redhat.com wrote:
I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. Starting at 300 seems sensible, to give FC some room.
Erhm... But what about all those existing user bases introduced when only the range below 100 was reserved? My uid at the uni has been 404 since 1991. FWIW, it wasn't an HTTP error code back then, to the best of my knowledge; it was just the number right after 403.
:)
I suspect that we'll find that due to poor historical planning, every UID above 100 is used by someone, somewhere.
~spot
tcallawa@redhat.com ("Tom 'spot' Callaway") writes:
I suspect that we'll find that due to poor historical planning, every UID above 100 is used by someone, somewhere.
Exactly; that's why, Fedora Extras can not claim a fixed UID range there. Neither in 100-499, nor in 500-2^16, nor in the upper 32 bit range.
Enrico
On Mon, 2005-07-04 at 17:27 +0200, Enrico Scholz wrote:
tcallawa@redhat.com ("Tom 'spot' Callaway") writes:
I suspect that we'll find that due to poor historical planning, every UID above 100 is used by someone, somewhere.
Exactly; that's why, Fedora Extras can not claim a fixed UID range there. Neither in 100-499, nor in 500-2^16, nor in the upper 32 bit range.
Nevertheless, we need to have a default. I'm not opposed to using the existing user tools to create the IDs, merely that the default starting UID should be 300.
~spot
On Mon, Jul 04, 2005 at 10:41:14AM -0500, Tom 'spot' Callaway wrote:
Exactly; that's why, Fedora Extras can not claim a fixed UID range there. Neither in 100-499, nor in 500-2^16, nor in the upper 32 bit range.
Nevertheless, we need to have a default. I'm not opposed to using the existing user tools to create the IDs, merely that the default starting UID should be 300.
And that we should have a registry of standard fixed UIDs within that range, right?
mattdm@mattdm.org said:
And that we should have a registry of standard fixed UIDs within that range, right?
That's the part I don't understand: why a global registry ?
Isn't the point of adding local UIDs to get a kind of macro thing, i.e. what is standard is the name, which should be the same on all machines, but nobody cares what the actual UID is ?
I agree it can get a bit hairy when several machines share things by NFS, but having a central global UID registry also seems hairy.
The only real special UID is numbered 0.
But probably I'm overlooking something obvious :)
Anybody cares to explain ?
Thanks, Christian
On Mon, Jul 04, 2005 at 06:31:42PM +0200, Christian.Iseli@licr.org wrote:
mattdm@mattdm.org said:
And that we should have a registry of standard fixed UIDs within that range, right?
That's the part I don't understand: why a global registry ?
So that multiple systems have the same ids. Or so that if you do a reinstall, your files have the same owners.
Isn't the point of adding local UIDs to get a kind of macro thing, i.e. what is standard is the name, which should be the same on all machines, but nobody cares what the actual UID is ?
The filesystem cares. Therefore, we have to.
On Mon, 2005-07-04 at 12:54 -0400, Matthew Miller wrote:
On Mon, Jul 04, 2005 at 06:31:42PM +0200, Christian.Iseli@licr.org wrote:
mattdm@mattdm.org said:
And that we should have a registry of standard fixed UIDs within that range, right?
That's the part I don't understand: why a global registry ?
So that multiple systems have the same ids. Or so that if you do a reinstall, your files have the same owners.
I save my /etc/passwd file for reinstall.
For multiple machines where identical UID/GID is needed - you generally should not be relying on local /etc/passwd. If you have a laptop that needs to share UID/GID - then you manually set up the /etc/passwd and /etc/group for that laptop.
A system administrator on a network where keeping UID/GID in sync is important should know how to do it w/o Fedora needing to specify a registry of unames and groups.
Follow the FHS - below 100 reserved for vendor, 100-499 for system accounts not specified by vendor, 500 and above for user accounts.
That works now, and no registry (which needs maintenance) is needed.
Le mercredi 06 juillet 2005 à 11:16 -0700, Michael A. Peters a écrit :
Follow the FHS - below 100 reserved for vendor, 100-499 for system accounts not specified by vendor, 500 and above for user accounts.
That works now, and no registry (which needs maintenance) is needed.
That does not work at all now. 100 numbers is way too little for vendor. A big reasons UIDs are not the same across distros for example is they need to manage this sparse resource, so they can not preallocate an UID when it's used in another distro - they have to reserve this space to the main products they ship. Even if after a few years the same product is adopted by everyone, each distro will by then have reallocated a different hole in its 100 range to it.
Christian.Iseli@licr.org wrote :
That's the part I don't understand: why a global registry ?
[...]
I agree it can get a bit hairy when several machines share things by NFS, but having a central global UID registry also seems hairy.
That's the point : Fixed uid/gid is often a good thing, I have many setups where a bunch of redundant servers access the same nfs share, and I'm in trouble when I install packages on those servers which create a user with a non fixed uid, and one gets say 201 and the other 202...
I'm really grateful to know I can expect apache to be uid 48 everywhere, for instance.
Matthias
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net said:
That's the point : Fixed uid/gid is often a good thing, I have many setups where a bunch of redundant servers access the same nfs share, and I'm in trouble when I install packages on those servers which create a user with a non fixed uid, and one gets say 201 and the other 202...
I'm really grateful to know I can expect apache to be uid 48 everywhere, for instance.
I think there are two cases: standalone machines, and machines that share data.
For standalone machines, the only trouble is when they are re-installed or upgraded. If the old passwd file can still be read, the problem is easy to solve: just reuse the old UIDs. When the old passwd file is damaged: you are in trouble anyway: the user probably created a few accounts which contain files, and those accounts will need to be hand-recreated with the proper UID anyway... Having fixed UIDs helps some, but not that much.
For machines that share data, IMHO the proper way is to put all accounts with distributed files in a UID management thing like LDAP or NIS. It doesn't buy you much that a few of those UIDs are fixed. Plus, people running such setups are supposed to be pretty knowledgeable about managing a local UID database.
I'm still of the opinion that fixed UIDs don't solve much, and are not easy to manage.
In a way, it seems things might be a bit simpler if a username->UID mapping was stored somewhere in the filesystem, at mount/fsck/umount time... Ah well, just daydreaming I guess :)
Cheers, Christian
On Wed, Jul 06, 2005 at 10:49:07AM +0200, Christian.Iseli@licr.org wrote:
For standalone machines, the only trouble is when they are re-installed or upgraded. If the old passwd file can still be read, the problem is easy to solve: just reuse the old UIDs. When the old passwd file is damaged: you are in trouble anyway: the user probably created a few accounts which contain files, and those accounts will need to be hand-recreated with the proper UID anyway... Having fixed UIDs helps some, but not that much.
I often upgrade by preserving /home and a few key config files but wiping the system disk. Much faster than the anaconda upgrade option, with cleaner results. But if I do that, and the UIDs used by packages at install time change, there will be mis-owned files on the system.
For machines that share data, IMHO the proper way is to put all accounts with distributed files in a UID management thing like LDAP or NIS. It
As previously mentioned, that's not the right thing for system accounts. For example, it doesn't help the above situation.
mattdm@mattdm.org said:
I often upgrade by preserving /home and a few key config files but wiping the system disk. Much faster than the anaconda upgrade option, with cleaner results. But if I do that, and the UIDs used by packages at install time change, there will be mis-owned files on the system.
Why is /etc/passwd not included in your "and a few key config files" ?
I'm not saying the current situation is ideal. I'm saying I'd rather have anaconda preserve existing system account UIDs and/or use those from the local LDAP/NIS/whatever, than a centralized fixed UIDs assignation...
Christian
On Wed, 2005-07-06 at 07:31 -0400, Matthew Miller wrote:
I often upgrade by preserving /home and a few key config files but wiping the system disk. Much faster than the anaconda upgrade option, with cleaner results. But if I do that, and the UIDs used by packages at install time change, there will be mis-owned files on the system.
A system service should NOT have a home directory in /home so all of the UIG/GID in /home should be above 500.
For machines that share data, IMHO the proper way is to put all accounts with distributed files in a UID management thing like LDAP or NIS. It
As previously mentioned, that's not the right thing for system accounts. For example, it doesn't help the above situation.
system accounts should not have home directories in /home anyway. If someone packages a fedora or extras package that uses a system account and has a directory in /home that is a packaging bug.
But really - just like you need to preserve your ssl keys, a sysadmin should preserve /etc/passwd and /etc/group. I never personally save /etc/shadow - I just use the saved /etc/passwd to recreate users keeping uid/gid the same.
On Wed, Jul 06, 2005 at 05:40:20PM -0700, Michael A. Peters wrote:
I often upgrade by preserving /home and a few key config files but wiping the system disk. Much faster than the anaconda upgrade option, with cleaner results. But if I do that, and the UIDs used by packages at install time change, there will be mis-owned files on the system.
A system service should NOT have a home directory in /home so all of the UIG/GID in /home should be above 500.
That's irrelevant. If it creates files in (say) /var as whatever user it picks at random, and then I copy my old password file over the new one, it will be All Br0ke. (And that's not even considering the annoyance of dealing with any *new* system users.)
[...]
system accounts should not have home directories in /home anyway.
I have no idea why you're all on about /home.
But really - just like you need to preserve your ssl keys, a sysadmin should preserve /etc/passwd and /etc/group. I never personally save /etc/shadow - I just use the saved /etc/passwd to recreate users keeping uid/gid the same.
See above. :)
On Wed, 2005-07-06 at 20:52 -0400, Matthew Miller wrote:
I have no idea why you're all on about /home.
Because you described the same process I use - /home is its own partition, I don't do upgrades - I do clean installs formatting / but not formatting /home.
Then after firstboot - I add my user accounts, and yum install anything from extras/livna.
No uid/gid problems.
If there is other data I need to preserve that are not already owned by core, I can add those uid/gid's from my saved passwd and group files so that the same uid/gid is used.
There is thus no conflict - no need to reserve an extra range of uid/gid for extras (or any other repository). As long as the package adds its user as a system account or is already present from previous /etc/passwd file - there are no conflicts, none. If the rpm doesn't add the user as a system user - then there is a bug in the packaging.
non core packages that depend on a particular user/group really should add that user itself - that way you can use a macro do define where its home directory is (if needed) and if it adds the user/group itself, with the -r switch, it won't conflict with anything else. Sure - it may be a different uid/gid on my machine than yours - but so what? That's only an issue if we are on the same network, in which case the network admin should decide what uid/gid is used.
I guess what I'm trying to say is I don't see a problem with the way it is currently done, nor do I see how a registry of uid/gid's solves anything.
On Wed, Jul 06, 2005 at 07:17:43PM -0700, Michael A. Peters wrote:
There is thus no conflict - no need to reserve an extra range of uid/gid for extras (or any other repository). As long as the package adds its user as a system account or is already present from previous /etc/passwd file - there are no conflicts, none. If the rpm doesn't add the user as a system user - then there is a bug in the packaging.
let's say you have server-program-foo, and server-program-bar. On your first install, server-program-foo got installed first and created user "serverfoo" as uid 101, and server-program-bar created "serverbar" with uid 102. Now, on the second install, for arcane RPM transaction ordering reasons, server-program-bar gets installed first -- and gets stuff owned by new user "serverbar" uid 101. Now, when you put your password file back, uid 101 reverts to "serverfoo", all of the files are owned by the wrong user. You may not even notice it until something breaks, but it ain't right.
(And that's not even considering that you accidentally wiped out the new user created by server-program-baz, which requires a separate user account in the new version and you didn't notice before copying your passwd file on top of the new one.)
I guess what I'm trying to say is I don't see a problem with the way it is currently done, nor do I see how a registry of uid/gid's solves anything.
It solves the above problem, and *also* issues with backup, with networked filesystems, and more.
It solves the above problem, and *also* issues with backup, with networked filesystems, and more.
It's come to my attention that I've spent way too much energy on this thread. I think I've made my point; I'll shut up now. :)
I hate to revive a dead thread, but I don't think we came to a decision on this.
Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs.
This seems to be doing roughly the same thing as fedora-usermgt. Does this seem like an acceptable way to create system user/groups in %post?
~spot
On Tue, Sep 06, 2005 at 04:39:26PM -0500, Tom 'spot' Callaway wrote:
Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs.
This seems to be doing roughly the same thing as fedora-usermgt. Does this seem like an acceptable way to create system user/groups in %post?
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
And then just *don't touch the account* on removal. If this is the stated policy, then no sysadmin can be surprised by it. If unused accounts bother them, they can do "userdel foo" manually.
If for some reason useradd will not work, doing this in %pre should make package installation fail, right? Then the sysadmin can go add the user in LDAP/NIS/whatever and reinstall the package.
IMHO trying to support anything more elaborate than this is going to cause more problems than it solves...
Steve
On Tue, 2005-09-06 at 16:52 -0500, Steven Pritchard wrote:
On Tue, Sep 06, 2005 at 04:39:26PM -0500, Tom 'spot' Callaway wrote:
Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs.
This seems to be doing roughly the same thing as fedora-usermgt. Does this seem like an acceptable way to create system user/groups in %post?
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
And then just *don't touch the account* on removal. If this is the stated policy, then no sysadmin can be surprised by it. If unused accounts bother them, they can do "userdel foo" manually.
If for some reason useradd will not work, doing this in %pre should make package installation fail, right? Then the sysadmin can go add the user in LDAP/NIS/whatever and reinstall the package.
IMHO trying to support anything more elaborate than this is going to cause more problems than it solves...
This all seems to make sense to me. Agree or disagree?
~spot
Tom 'spot' Callaway wrote :
On Tue, 2005-09-06 at 16:52 -0500, Steven Pritchard wrote:
On Tue, Sep 06, 2005 at 04:39:26PM -0500, Tom 'spot' Callaway wrote:
Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs.
This seems to be doing roughly the same thing as fedora-usermgt. Does this seem like an acceptable way to create system user/groups in %post?
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
And then just *don't touch the account* on removal. If this is the stated policy, then no sysadmin can be surprised by it. If unused accounts bother them, they can do "userdel foo" manually.
If for some reason useradd will not work, doing this in %pre should make package installation fail, right? Then the sysadmin can go add the user in LDAP/NIS/whatever and reinstall the package.
IMHO trying to support anything more elaborate than this is going to cause more problems than it solves...
This all seems to make sense to me. Agree or disagree?
I tend to agree, and personally dislike the added complexity of this fedora-usermgmt that got imported from the fedora.us days. But I also think that in some cases, fixed uid/gids are best, most importantly when chances of having files shared across machines are high, like with apache (uid/gid 48) owned files for instance.
Matthias
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes:
Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs.
... I tend to agree, and personally dislike the added complexity of this fedora-usermgmt
Which added complexity? Usage of fedora-usermgmt is very simple:
1. Register a user/uid pair at http://fedoraproject.org/wiki/PackageUserRegistry
2. Add a 'Requires(pre): fedora-usermgmt' (which replaces the shadowutils counterpart). Complains about this additional dependency are bogus in the age of smartpm or yum.
3. Call 'fedora-useradd' with an additional parameter (the uid)
Additional configuration is very simple also; when you want semi-static uids:
1. just activate the mode with
| /usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils
2. configure your prefered baseuids/gids in /etc/fedora/usermgmt/base[gu]id (which are simple textfiles). This setup can be done easily e.g. with custom configuration-package or cfengine.
that got imported from the fedora.us days. But I also think that in some cases, fixed uid/gids are best, most importantly when chances of having files shared across machines are high,
My experiences show that this applies to most packages.
Enrico
steve@silug.org (Steven Pritchard) writes:
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
This does not solve the problem that users will have different UIDs on different machines.
And then just *don't touch the account* on removal.
This rule is ok with me.
If for some reason useradd will not work, doing this in %pre should make package installation fail, right? Then the sysadmin can go add the user in LDAP/NIS/whatever and reinstall the package.
IMO, managing service-accounts with LDAP/NIS is a bad idea. It is ideal for normal users but I do not want to rely on them for services. You will run into bootstrap issues (e.g. think of slapd which tries to resolve the 'ldap' user), configuration errors like outdated TLS certificates (which make LDAP lookups impossible) or added complexity for critical services (I saw enough problems with nss_ldap and nscd).
Additionally, there is no way to see whether users are created by an rpm package or which parameters are used for these users. So it is not possible to create users on the LDAP server *before* the package is installed.
Enrico
Enrico Scholz wrote :
This does not solve the problem that users will have different UIDs on different machines.
Regarding fixed uid/gid pairs, I fail to see where fedora-usermgmt improves anything over a default useradd/groupadd. If it's the configurable offset, then it's the opposite : It brings back the possibility of having different uid/gid pairs on differently configured machines...
...or am I missing something?
Matthias
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes:
This does not solve the problem that users will have different UIDs on different machines.
Regarding fixed uid/gid pairs, I fail to see where fedora-usermgmt improves anything over a default useradd/groupadd. If it's the configurable offset, then it's the opposite : It brings back the possibility of having different uid/gid pairs on differently configured machines...
...or am I missing something?
Yes... you can configure different machines in the same way (e.g. with cfengine or a custom 'setup(fedora-usermgmt)' package in the local repository which provides common base[ug]id files).
Enrico
On Wed, 2005-09-07 at 00:29 +0200, Enrico Scholz wrote:
steve@silug.org (Steven Pritchard) writes:
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
This does not solve the problem that users will have different UIDs on different machines.
Note the -r. We are talking about system accounts.
I fail to see why system accounts should be shared across networks and why there is any need to force unique UIDs on them.
IMO, system users must be local, only.
And then just *don't touch the account* on removal.
This rule is ok with me.
Not OK with me.
Cf. above.
The only reason for not wanting to remove accounts on package removal to me is "accounts leaving stray files somewhere".
However, rpms should have always have control over all files it owns.
If for some reason useradd will not work, doing this in %pre should make package installation fail, right? Then the sysadmin can go add the user in LDAP/NIS/whatever and reinstall the package.
IMO, managing service-accounts with LDAP/NIS is a bad idea.
ACK.
Ralf
rc040203@freenet.de said:
I fail to see why system accounts should be shared across networks and why there is any need to force unique UIDs on them.
IMO, system users must be local, only.
+1
Looks like the opinions of the various people didn't change much since the last round :-)
rc040203@freenet.de said:
The only reason for not wanting to remove accounts on package removal to me is "accounts leaving stray files somewhere".
However, rpms should have always have control over all files it owns.
Well, there are many cases of packages producing some files while they run, which they will not own. E.g.,
root: rpm -qf /var/log/mysqld.log.4 file /var/log/mysqld.log.4 is not owned by any package root: ls -l /var/log/mysqld.log.4 -rw-r----- 1 mysql mysql 0 Aug 7 03:02 /var/log/mysqld.log.4
So I think the UID should stay... until the sysadm removes it.
Cheers, Christian
On Wed, 2005-09-07 at 08:32 +0200, Christian.Iseli@licr.org wrote:
rc040203@freenet.de said:
The only reason for not wanting to remove accounts on package removal to me is "accounts leaving stray files somewhere".
However, rpms should have always have control over all files it owns.
Well, there are many cases of packages producing some files while they run,
That's why I said "should".
It is possible in many cases (%postun, %ghost or %triggerun scripts), but won't be possible or useful in all cases.
E.g. I would not want an mysql update remove my mysql data bases.
which they will not own. E.g.,
root: rpm -qf /var/log/mysqld.log.4 file /var/log/mysqld.log.4 is not owned by any package root: ls -l /var/log/mysqld.log.4 -rw-r----- 1 mysql mysql 0 Aug 7 03:02 /var/log/mysqld.log.4
So I think the UID should stay... until the sysadm removes it.
IMO, this is an example where removing files is possible:
E.g.
%postun rm -f /var/log/mysqld.log*
Ralf
rc040203@freenet.de said:
Christian.Iseli@licr.org wrote:
rc040203@freenet.de said:
The only reason for not wanting to remove accounts on package removal to me is "accounts leaving stray files somewhere".
However, rpms should have always have control over all files it owns.
Well, there are many cases of packages producing some files while they run,
That's why I said "should".
It is possible in many cases (%postun, %ghost or %triggerun scripts), but won't be possible or useful in all cases.
E.g. I would not want an mysql update remove my mysql data bases.
Which is precisely why I think the ID should not be automatically removed... Yes, I also used "should" :-) There certainly are packages where removing the ID is fine, but I think the general rule should be conservative.
which they will not own. E.g.,
root: rpm -qf /var/log/mysqld.log.4 file /var/log/mysqld.log.4 is not owned by any package root: ls -l /var/log/mysqld.log.4 -rw-r----- 1 mysql mysql 0 Aug 7 03:02 /var/log/mysqld.log.4
So I think the UID should stay... until the sysadm removes it.
IMO, this is an example where removing files is possible:
E.g.
%postun rm -f /var/log/mysqld.log*
I agree. I only spent a few seconds looking for some valid example of unowned files. But I suspect there are tougher nuts.
Christian
rc040203@freenet.de (Ralf Corsepius) writes:
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
This does not solve the problem that users will have different UIDs on different machines.
Note the -r. We are talking about system accounts.
The '-r' makes only
* that the generated UID is in a certain range; the exact values are unpredictable and it's highly probably that they differ on different machines
* that there is no expiration date for the account (that's why '-r' should be used with fedora-usermgmt also)
I fail to see why system accounts should be shared across networks and why there is any need to force unique UIDs on them.
ok, some examples:
* 'vdr' and 'vdradmin' (from livna) are running on different hosts as the 'vdr:video' user. Both share configuration files and data which is exported by NFS
* some data in a shared filesystem which shall be read by apache only but not by other users -> all affected machines will need the same uid/gid for apache
* programs (e.g. milters) which are installed in chroot environments and use unix-sockets as communication points. Access restrictions can be installed easily with filesystem permissions when all chroots are seeing the same user-uid pairs
* backup/copying between hosts; when user does not exist at the destination yet, resulting files will be readable by the wrong user
* the 'owner' module of iptables requires predictable uids
* it is confusing and unesthetically when users are having different identities
IMO, system users must be local, only.
Yes; but they can access/own files on shared filesystems so all systems should have the same view about them.
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this. I am not aware of any drawbacks, it solves the problem of unpredictable uids and without explicit configuration it is transparent to users because it has the same behavior as plain 'useradd' then. So I do not see reasons why it should not be used.
Enrico
enrico.scholz@informatik.tu-chemnitz.de said:
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this.
IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? So, you need a machine connected to the Internet. I think it's a problem. If you really want a fixed ID, why not hardcode it in the package itself ?
Christian
Christian.Iseli@licr.org writes:
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this.
IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ?
No; you are telling the uid (ditto for gids) in a way like
| %pre | fedora-useradd 23 -r ... foo
The '23' was "requested" by adding a corresponding entry into the wiki (http://fedoraproject.org/wiki/PackageUserRegistry) and written statically into the spec-file.
By default, this hint will be ignored. But when enabling it with
/usr/sbin/update-alternatives --set fedora-usermgmt /etc/fedora/usermgmt/scripts.shadow-utils
user 'foo' will get a static uid of BASE+23 where BASE is configured in /etc/fedora/usermgmt/baseuid. When you set BASE to the same value on all machines, user 'foo' will have the same uid everywhere.
Making BASE configurable is necessary because there does not exist a free range for static uids; only 0-99 is reserved for static uids but too small for FE. All other uid ranges might fall under local policies and are not available.
Enrico
Christian.Iseli@licr.org wrote :
enrico.scholz said:
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this.
IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? So, you need a machine connected to the Internet. I think it's a problem. If you really want a fixed ID, why not hardcode it in the package itself ?
The fixed id is in the package itself (without the offset), which is why I fail to see any reason to add a dependency on some custom user management scripts when plain useradd/groupadd is sufficient.
There are two mixed discussions here : - Should we rely on fedora-usermgmt from fedora.us to manage system users? - Should some system users have fixed uid/gid pairs?
Those are two completely separate debates, to which I personally answer "no" and "yes" respectively.
Matthias
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes:
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this.
IIUC, fedora-usermgmt looks the ID up on some wiki page somewhere ? So, you need a machine connected to the Internet. I think it's a problem. If you really want a fixed ID, why not hardcode it in the package itself ?
The fixed id is in the package itself (without the offset), which is why I fail to see any reason to add a dependency on some custom user management scripts when plain useradd/groupadd is sufficient.
Ok, you could do
| useradd -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 23 ] ...
in every %scriptlet also. But when adding sanity checks and fallback methods for the traditional 'useradd', this will end in >5 lines of complex and redundant code in the %scriptlets.
'fedora-usermgmt' provides a high grade of customization: by writing own backends, e.g. you can calculate the final uid/gid by ldap lookups (which might be needed in environments with a high uid-dense). Writing scripts like above restricts you to exactly one configuration scheme.
Using the wrapper method (where fedora-usermgmt is a such one) simplifies the scriptlets significantly in other aspects also. Currently there are several methods how to add users. Some people use simple
| useradd ... &>/dev/null || :
other
| grep '<uid>' /etc/password || useradd ...
other
| id '<uid>' || useradd ...
or ...
Using a wrapper like 'fedora-useradd' can do this steps in a common (and configurable) way.
There are two mixed discussions here :
- Should we rely on fedora-usermgmt from fedora.us to manage system users?
I do not insist on this implementation, but IMO it is clean and offers lot of ways to adapt it to your needs.
- Should some system users have fixed uid/gid pairs?
At the end, it will not make a difference if these are only 'some' or 'all' system users.
Enrico
enrico.scholz@informatik.tu-chemnitz.de said:
you could do | useradd -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 23 ] ...
Hmm. If all you're trying to achieve is to have a default fixed UID, but still allow for some local customization, why not something along the lines of:
| %{name}_UID=${%{name}_UID:-23} | useradd -u $%{name}_UID
And then the admin who wants to customize package foo can run: $ foo_UID=1012 rpm -ivh foo-1.0-1.blah.rpm or $ foo_UID=1012 yum install foo
(Note that I haven't tested this...)
Christian
Christian.Iseli@licr.org writes:
| useradd -u $[ $(cat /etc/fedora/usermgmt/baseuid) + 23 ] ...
Hmm. If all you're trying to achieve is to have a default fixed UID, but still allow for some local customization, why not something along the lines of:
| %{name}_UID=${%{name}_UID:-23} | useradd -u $%{name}_UID
Interesting idea. But it suffers from the same complex-scriptlet problem which was explained later in the cited posting.
It has the additional problem that it is difficultly to handle; you will have to write wrappers for all rpm aware tools so that the *_UID environment is set for them (e.g. think on system initialization which adds 400-500 packages and 20-30 new users in one 'yum install' transaction).
It requires high maintenance also because it will miss new accounts else.
'fedora-usermgmt' has to be configured only once (or keep it as-is, when the functionality is not needed) and has very simple %scriptlets.
Enrico
On 9/7/05, Christian.Iseli@licr.org Christian.Iseli@licr.org wrote:
And then the admin who wants to customize package foo can run: $ foo_UID=1012 rpm -ivh foo-1.0-1.blah.rpm or $ foo_UID=1012 yum install foo
this very much assumes that you know exactly what packages by name you want to install. When using rpm on the cmdline that might very well be the case, since you are forced to explictly add deps to the calling command. Using yum groupinstall or yum install which pulls in deps is going to quickly lead to problems unless you do a lot of work reviewing exactly which packages are going to be installed so you can setup the environment variables for each package that might be pulled in via an install request. Fragile very very fragile. And as soon as we start seeing gui yum-aware tools mature, having to manipulate environment variables is going to seem a bit more arcane. I can only imagine how much fun playing with all those per package environment variables would be in a kickstarted yum-aware install. Ideally a solution that will work equally well for whatever rpm-aware/yum-aware tool that local admin wants to use. Packages that use the fedora-usermgmt approach should work equally well for whatever package mangement tool you choose to use.
Assuming there is no perfect solution here..exactly what is the drawback with the fedora-usermgmt approach compared to other approaches. Is complexity the only percieved problem? Its going to be a much bigger maintainence problem over time trying to have each packager write and maintain their own scriplet logic.... especially when there is no clear policy on the specifics on uid/gid creation to follow moving forward. The more logic you can shove off into an on-system script the more freedom you have to adjust the default policy on down the road without having to rebuild the world to adjust each specfile. Having individual packagers implement the full script in individual specfiles is asking for the approach to be cast-in-stone.
Considering the lack of consensous so far among the informed people in this discussion, I would strongly encourage avoiding hardwiring this policy into individual specfiles to avoid more "historical" problems in the future. Pick a wrapper solution, adjust the wrapper as needed as thoughts on the specifics evolve.
-jef
jspaleta@gmail.com said:
Assuming there is no perfect solution here..exactly what is the drawback with the fedora-usermgmt approach compared to other approaches. Is complexity the only percieved problem?
My opinion (all mine :-) ):
1. I haven't seen a convincing argument why FE packages need to add fixed IDs
2. If it is deemed so important to have fixed IDs, why doesn't Fedora Core provide a mechanism to add them ? Even if I can be convinced at some point that fixed IDs are really needed, I doubt the proper place for the mechanism is in FE.
Christian
On Wed, 2005-09-07 at 11:11 +0200, Enrico Scholz wrote:
rc040203@freenet.de (Ralf Corsepius) writes:
My personal feeling (as a sysadmin and a packager) is that doing something like this in %pre (not %post, if you want files owned by the new user) is the Right Thing:
%pre if ! id foo > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c 'BAR' [...] foo fi
This does not solve the problem that users will have different UIDs on different machines.
Note the -r. We are talking about system accounts.
The '-r' makes only
- that the generated UID is in a certain range; the exact values are unpredictable and it's highly probably that they differ on different machines
Yes, but ... who cares? All that matters is using consistent ranges in a local network.
I fail to see why system accounts should be shared across networks and why there is any need to force unique UIDs on them.
ok, some examples:
- 'vdr' and 'vdradmin' (from livna) are running on different hosts as the 'vdr:video' user. Both share configuration files and data which is exported by NFS
Then these UID/GIDs probably better should be ordinary uids, instead of system-user ids.
- some data in a shared filesystem which shall be read by apache only but not by other users -> all affected machines will need the same uid/gid for apache
To me this is a classical case of a customized network setup. It's the admin's responsibility to synchronize the uids.
I am doing the same with other dirs on my local network.
- programs (e.g. milters) which are installed in chroot environments and use unix-sockets as communication points. Access restrictions can be installed easily with filesystem permissions when all chroots are seeing the same user-uid pairs
I can't comment on these.
- backup/copying between hosts; when user does not exist at the destination yet, resulting files will be readable by the wrong user
Yes, local network admin responsibility.
- the 'owner' module of iptables requires predictable uids
I can't comment on this.
- it is confusing and unesthetically when users are having different identities
Let me turn this coin around: You are trying to be stylish and seem to be trying to project your personal conventions to the public.
You are missing: * These points are irrelevant in heterogenious networks. Each OS has different conventions, so any convention is always somehow wrong and requires hand-crafting. * Using fixed uids unnecessarily restricts the number of available uids. You will sooner or later face the problems of all fixed-table based configuration approaches. * There is nothing which prevents you to generate consistent uids in your network.
IMO, system users must be local, only.
Yes; but they can access/own files on shared filesystems so all systems
Depends on your setup.
should have the same view about them.
I don't understand.
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this. I am not aware of any drawbacks, it solves the problem of unpredictable uids and without explicit configuration it is transparent to users because it has the same behavior as plain 'useradd' then. So I do not see reasons why it should not be used.
Frankly speaking, I am no friend of fedora-usermgmt. To the same extent it might help you, it interferes with my demands.
Ralf
rc040203@freenet.de (Ralf Corsepius) writes:
I fail to see why system accounts should be shared across networks and why there is any need to force unique UIDs on them.
ok, some examples:
- 'vdr' and 'vdradmin' (from livna) are running on different hosts as the 'vdr:video' user. Both share configuration files and data which is exported by NFS
Then these UID/GIDs probably better should be ordinary uids, instead of system-user ids.
These users are created by an rpm, this package contains files owned by them and they are set in global configuration files. So, they must be system accounts.
- some data in a shared filesystem which shall be read by apache only but not by other users -> all affected machines will need the same uid/gid for apache
To me this is a classical case of a customized network setup. It's the admin's responsibility to synchronize the uids.
There is no way to see whether an rpm package creates an account or to determine the parameters of this account.
- it is confusing and unesthetically when users are having different identities
Let me turn this coin around: You are trying to be stylish and seem to be trying to project your personal conventions to the public.
You are missing:
- These points are irrelevant in heterogenious networks. Each OS has
different conventions, so any convention is always somehow wrong and requires hand-crafting.
The uid/gid concept exists on all Posix compliant systems. 'fedora-usermgmt' would work fine e.g. on Solaris also.
- Using fixed uids unnecessarily restricts the number of available uids.
You will sooner or later face the problems of all fixed-table based configuration approaches.
I do not expect that the number of registered UIDs reaches a range where this is critical. And when you have really an environment without a free range of perhaps 1000-2000 uids, then write your own 'fedora-usermgmt' backend which calculates the resulting UID in a clever way.
It is easy to create users with predictable uids and fedora-usermgmt offers a simple method doing this. I am not aware of any drawbacks, it solves the problem of unpredictable uids and without explicit configuration it is transparent to users because it has the same behavior as plain 'useradd' then. So I do not see reasons why it should not be used.
Frankly speaking, I am no friend of fedora-usermgmt. To the same extent it might help you, it interferes with my demands.
Where does it interferes with your demands? When you did nothing (used fedora-usermgmt out-of-the-box), there is no difference to the plain 'useradd'. When you did something, you did it wrong perhaps or encountered a bug in fedora-usermgmt.
Enrico
On Sep 7, 2005, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
These users are created by an rpm, this package contains files owned by them and they are set in global configuration files. So, they must be system accounts.
Err... The rpm cpio payload contains user ids encoded in the form of user/group names, not numbers, I hope, just like tar. Doesn't it? If so, all it takes to get a single, consistent uid is to add the username to the central uid database before installing the rpms anywhere, then the system will find the users to exist and install the contents with the right uid. If you have your hosts configured to trust the database over local user info, and you've already installed rpms before that chose random uids, then you might have to remove the local user by hand and reinstall the packages.
There is no way to see whether an rpm package creates an account or to determine the parameters of this account.
Should we perhaps think of abstracting out user ids into separate rpm packages? It sounds yucky at first, but it would be a clean way to address the issue of removing lingering accounts or not. The account would be brought in as a dependency of the actual package, but wouldn't be removed automatically when the package is removed, but there would be a clean, simple, standard way to remove it.
The uid/gid concept exists on all Posix compliant systems. 'fedora-usermgmt' would work fine e.g. on Solaris also.
Heck, it would probably work even on Cygwin :-)
aoliva@redhat.com (Alexandre Oliva) writes:
These users are created by an rpm, this package contains files owned by them and they are set in global configuration files. So, they must be system accounts.
Err... The rpm cpio payload contains user ids encoded in the form of user/group names, not numbers, I hope, just like tar. Doesn't it? If so, all it takes to get a single, consistent uid is to add the username to the central uid database
"central uid database" implicates something like LDAP or NIS. But as explained in previous postings, LDAP/NIS is a bad idea for service accounts.
before installing the rpms anywhere,
When doing an 'yum install <something>' which adds 100 new packages, it is impossible to determine which users will be created in this transaction.
then the system will find the users to exist and install the contents with the right uid. If you have your hosts configured to trust the database over local user info, and you've already installed rpms before that chose random uids, then you might have to remove the local user by hand and reinstall the packages.
Yes, I remember some 'find -uid ... | xargs chown'. Such actions are tending to evolve to a huge mess, especially when a '-h' flag was forgotten or already assigned uids were used...
That's why I prefer (semi)static uids for all service accounts.
There is no way to see whether an rpm package creates an account or to determine the parameters of this account.
Should we perhaps think of abstracting out user ids into separate rpm packages?
Ok with me, but there are enough people who will complain about added dependencies...
IMO; created users should be declared in rpm in a way like files and their creation should be done without explicit scriptlets. But this enhancement will not happen in the near future.
Enrico
On Sep 7, 2005, Enrico Scholz enrico.scholz@informatik.tu-chemnitz.de wrote:
"central uid database" implicates something like LDAP or NIS.
Nah... It might as well be something based on GNU Ad HoC, cfengine or something even simpler based on rdist.
Yes, I remember some 'find -uid ... | xargs chown'. Such actions are tending to evolve to a huge mess, especially when a '-h' flag was forgotten or already assigned uids were used...
Yuck
On Wednesday, 07 September 2005 at 12:35, Enrico Scholz wrote:
rc040203@freenet.de (Ralf Corsepius) writes:
[...]
- some data in a shared filesystem which shall be read by apache only but not by other users -> all affected machines will need the same uid/gid for apache
To me this is a classical case of a customized network setup. It's the admin's responsibility to synchronize the uids.
There is no way to see whether an rpm package creates an account or to determine the parameters of this account.
What about adding Provides: username(uid) Provides: groupname(gid) or something along these lines?
Regards, R.
On Mer 7 septembre 2005 12:06, Ralf Corsepius wrote:
- 'vdr' and 'vdradmin' (from livna) are running on different hosts as the 'vdr:video' user. Both share configuration files and data which is exported by NFS
Then these UID/GIDs probably better should be ordinary uids, instead of system-user ids.
Except "ordinary IDs" can and will be put into LDAP/kerberos/whatever.
Come on folks, the sad truth is - user and system ID ranges need to be kept separate in any medium-to-big network. Any mixed system is an admin nightmare, and they're not kept in the same ID databases - system IDs must be fixed (fixed as in same in all the nodes of a local network) for lots of people (maybe not you but don't make life miserable for others just because you don't need something) - the current "official" fixed system ID range is much too small
So you need a fedora.us-style solution to create a bigger local fixed system ID range.
If the original system ID range were ~500 entries instead of 100 we wouldn't be writing about it today (later though...)
And the problem is more accute for FE than FC because FE ships a lot more stuff with system IDs *and* the current fixed system ID range is almost fully used by FC packages.
That being said, I've no special love for the fedora.us way, but the problem needs to be solved somehow and claiming there is not problem when lots of people say there is won't help solving it faster.
Regards,
On Sep 7, 2005, Ralf Corsepius rc040203@freenet.de wrote:
The only reason for not wanting to remove accounts on package removal to me is "accounts leaving stray files somewhere".
However, rpms should have always have control over all files it owns.
Unfortunately rpms can't hunt for backup tapes containing and wipe content out of them just to keep them consistent. When you restore data from a backup tape, wouldn't it be nice to still have the user that owned that data?
That's why it's policy on several locations to never ever reuse uids. If you need a new account, get the next available uid. If you need to close an account, change its password and shell to something unusable, and that's it. Leave the user information alone.
tcallawa@redhat.com ("Tom 'spot' Callaway") writes:
Someone recently pointed out to me the existence of useradd -r and groupadd -r (they're Red Hat added functionality). When used, these commands create the first available UID and GID below UID_MAX and GID_MAX, as defined in /etc/login.defs.
This seems to be doing roughly the same thing as fedora-usermgt.
fedora-usermgt does more. It can assign the same uid/gid for a user in the entire system. With plain 'useradd -r', users can/will have different ids on different machines which is very bad with NFS mounts or in chroot environments.
Enrico
On Mon, Jul 04, 2005 at 06:31:42PM +0200, Christian.Iseli@licr.org wrote:
That's the part I don't understand: why a global registry ?
Isn't the point of adding local UIDs to get a kind of macro thing, i.e. what is standard is the name, which should be the same on all machines, but nobody cares what the actual UID is ?
I have to agree. I can't think of a single reason why it would matter (for example) what UID the openvpn user is on any system. It's just an unprivileged user that openvpn can be configured to run as (after starting as root). I could use "nobody", but, well, that seems to be bad form these days.
I agree it can get a bit hairy when several machines share things by NFS, but having a central global UID registry also seems hairy.
In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package.
Steve
On Tue, Jul 05, 2005 at 11:01:30AM -0500, Steven Pritchard wrote:
I have to agree. I can't think of a single reason why it would matter (for example) what UID the openvpn user is on any system. It's just an unprivileged user that openvpn can be configured to run as (after starting as root). I could use "nobody", but, well, that seems to be bad form these days.
That's all well and good until the user owns files.
In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package.
Why should the *default* be "you have to do some extra work"? The standard case should be just that -- standard.
On Tue, 2005-07-05 at 12:25 -0400, Matthew Miller wrote:
On Tue, Jul 05, 2005 at 11:01:30AM -0500, Steven Pritchard wrote:
In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package.
Agreed on all counts. And in addition to the above, NFS4 should help in some specific cases too.
Why should the *default* be "you have to do some extra work"?
It shouldn't, but what do you think can be done about it? Not really an argument to any direction, but IMO the extra work not fatally wrong either because to get into a situation where any of this matters, one has already had to do some extra work, and could just take care of the uid mappings while at it. Shouldn't be a big deal.
The standard case should be just that -- standard.
If someone can come up with a standard or defaults that do not bluntly declare existing standards and policies, which have really nothing wrong in them, as broken or incompatible, that would be cool. FWIW, personally I think the time when that would have been really possible has passed a looooong time ago.
One semi-related point: migrating existing packages in public, supported repositories that have not used a fixed uid mapping scheme before to use one is probably not going to be feasible.
On Tue, Jul 05, 2005 at 09:33:45PM +0300, Ville Skyttä wrote:
One semi-related point: migrating existing packages in public, supported repositories that have not used a fixed uid mapping scheme before to use one is probably not going to be feasible.
Why not? They'd just be going from some-random-id to some-random-id-which- happens-to-be-the-same-every-time-thank-goodness.
On Tue, 2005-07-05 at 14:59 -0400, Matthew Miller wrote:
On Tue, Jul 05, 2005 at 09:33:45PM +0300, Ville Skyttä wrote:
One semi-related point: migrating existing packages in public, supported repositories that have not used a fixed uid mapping scheme before to use one is probably not going to be feasible.
Why not? They'd just be going from some-random-id to some-random-id-which- happens-to-be-the-same-every-time-thank-goodness.
Would you change the uid of a user in a %pre scriptlet on package upgrade if it existed already? And if that succeeds, what about files that are not owned by the package, but are already on the disk elsewhere?
Or would you rather let the existing username have the uid it had before the package upgrade, effectively nullifying the original goal of being able to trust that the uid will always be the same?
The above are the approaches I can come up with now to deal with the migration without declaring valid existing setups broken. Even if possible in theory, the first certainly does not sound practically feasible to me, and the second one does not meet the initial goal. Did I miss something?
On Tue, Jul 05, 2005 at 10:58:45PM +0300, Ville Skyttä wrote:
Or would you rather let the existing username have the uid it had before the package upgrade, effectively nullifying the original goal of being able to trust that the uid will always be the same?
I'd be happy enough with being able to trust that it'll always be the same on new installs. The older systems can be migrated as time/energy/inclination permits. I don't see any reason to block improving the situation just because there's currently a mess.
ville.skytta@iki.fi (Ville Skyttä) writes:
In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package.
Agreed on all counts. And in addition to the above, NFS4 should help in some specific cases too.
Sharing does not happen only over NFS. It can happen with '--bind' mounts between chroot environments, and Xen allows (limited) block device sharing also.
Enrico
On Tue, 2005-07-05 at 21:32 +0200, Enrico Scholz wrote:
ville.skytta@iki.fi (Ville Skyttä) writes:
In that case, there's NIS/NIS+/LDAP/whatever, and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package.
Agreed on all counts. And in addition to the above, NFS4 should help in some specific cases too.
Sharing does not happen only over NFS.
...which is why I said "some specific cases".
steve@silug.org (Steven Pritchard) writes:
I agree it can get a bit hairy when several machines share things by NFS, but having a central global UID registry also seems hairy.
In that case, there's NIS/NIS+/LDAP/whatever,
System users should be in /etc/passwd because the requirements for NIS/LDAP/whatever might not be fulfilled for early services; e.g. openvpn will be executed before the ldap service so the 'openvpn' user might not be resolveable at this time.
LDAP/NIS might be unwanted in certain environments also (e.g. on firewalls, portable machines).
and it is up to the sysadmin to do any extra work necessary to integrate the package into their environment. In the case of my openvpn package, if "useradd -r" does the right thing, then the problem is solved. If not, the sysadmin can just add an openvpn user before installing the package.
rpm does not offer a way to determine whether a package creates an user or not. So the 'just add an ... user before installing' requires lot of manual work, and automatic updates can not be applied.
Enrico
On Tue, Jul 05, 2005 at 07:34:16PM +0200, Enrico Scholz wrote:
System users should be in /etc/passwd because the requirements for NIS/LDAP/whatever might not be fulfilled for early services; e.g. openvpn will be executed before the ldap service so the 'openvpn' user might not be resolveable at this time.
LDAP/NIS might be unwanted in certain environments also (e.g. on firewalls, portable machines).
And those systems don't need to share files owned by system users, so it is a non-issue.
rpm does not offer a way to determine whether a package creates an user or not. So the 'just add an ... user before installing' requires lot of manual work,
$ rpm -qp --requires openvpn-2.0-2.x86_64.rpm | grep useradd /usr/sbin/useradd $ rpm -qp --scripts openvpn-2.0-2.x86_64.rpm preinstall scriptlet (using /bin/sh): if ! id openvpn > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c OpenVPN -d /etc/openvpn openvpn fi [...]
In the (likely far) less than 1% of cases where that's not good enough, I can't imagine why letting the sysadmin fix any issues that we can't possibly anticipate is a problem.
and automatic updates can not be applied.
Uh, I've been auto-updating every system I have openvpn, clamav, etc. on for, what, a year and a half? I must not understand you.
Steve
steve@silug.org (Steven Pritchard) writes:
rpm does not offer a way to determine whether a package creates an user or not. So the 'just add an ... user before installing' requires lot of manual work,
$ rpm -qp --requires openvpn-2.0-2.x86_64.rpm | grep useradd /usr/sbin/useradd $ rpm -qp --scripts openvpn-2.0-2.x86_64.rpm preinstall scriptlet (using /bin/sh): if ! id openvpn > /dev/null 2>&1 ; then /usr/sbin/useradd -r -s /sbin/nologin -c OpenVPN -d /etc/openvpn openvpn fi [...]
And now: do this for a 'yum install ...' transaction which lists 100 new packages and tell me all new users inclusive information like homedir, shell and gecos...
Or for a nightly 'yum upgrade' operation which adds new packages because of changed dependencies.
Enrico
On Mar 5 juillet 2005 20:32, Steven Pritchard wrote:
On Tue, Jul 05, 2005 at 07:34:16PM +0200, Enrico Scholz wrote:
System users should be in /etc/passwd because the requirements for NIS/LDAP/whatever might not be fulfilled for early services; e.g. openvpn will be executed before the ldap service so the 'openvpn' user might not be resolveable at this time.
LDAP/NIS might be unwanted in certain environments also (e.g. on firewalls, portable machines).
And those systems don't need to share files owned by system users, so it is a non-issue.
Those systems can share files owned by system users via backups, which may or may not require fixed UIDs to work, so they need it like everyone else.
The root mistake IMHO was exposing UIDs and GIDs to userspace, had they been hidden from the start like inodes we would not have all those problems today. But since they are exposed they need to be kept consistent like other stuff.
Regards,
I vote we stay below 500. My FC4 box seems to start at 500 for new UIDs. Starting at 300 seems sensible, to give FC some room.
~spot
I think this is the most sane.
Jack
mattdm@mattdm.org (Matthew Miller) writes:
for Fedora Extras packages. We could make it start at 300 to be less likely to conflict with random "useradd -r" done earlier.
Assigning fixed IDs in this range would violate LSB which states
| The system User IDs from 100 to 499 should be reserved for dynamic | allocation by system administrators and post install scripts using | useradd. [http://www.linuxbase.org/spec//book/LSB-generic/LSB-generic/uidrange.html]
Well, that leaves us with stuffing Extras system UIDs into 0-99, or violating the above-500 space,
... or using the fedora-usermgmt approach where every system administrator can decide whether he wants semi-fixed uids and where he can configure a free uid-range which is used for it.
which is worse. Note that the LSB doesn't say "must" -- it says "should", so it's a recommendation, not a requirement.
Yes, it is only a recommendation. But should we violate it when alternative solutions are existing?
The count of 200 free UIDs seems to be a little bit low for me; almost every package with a daemon will require an own user so we will fill the claimed 300-499 space in a few years.
Or -- why do not we take the 500-999 area and let normal users begin at 1000 (latter is already the case e.g. in Debian)? There the same situation will arise: there might be conflicts with existing installations (like with the 300-499 or any other fixed range), but as Seth says: "Change your uid and chown all your files. This is the nature of legacy."
Enrico
On Mon, Jul 04, 2005 at 07:57:55AM +0200, Enrico Scholz wrote:
The count of 200 free UIDs seems to be a little bit low for me; almost every package with a daemon will require an own user so we will fill the claimed 300-499 space in a few years.
Or -- why do not we take the 500-999 area and let normal users begin at 1000 (latter is already the case e.g. in Debian)? There the same situation will arise: there might be conflicts with existing installations (like with the 300-499 or any other fixed range), but as Seth says: "Change your uid and chown all your files. This is the nature of legacy."
We can start with 300-499 now, and then move the default minuid to 1000 in Fedora Core sometime later, with a warning that ids < 500 will become system ids in some future release, and then finally at some point in the future, make that change.
We can start with 300-499 now, and then move the default minuid to 1000 in Fedora Core sometime later, with a warning that ids < 500 will become system ids in some future release, and then finally at some point in the future, make that change.
I'm all about being able to configure where these IDs fall. But lets definitely make the default 300-499 for now. That's the most consistent with the way Red Hat / Fedora Core does things and is least likely to cause an existing installation to blow up. If the user wants to they can set there system to use another range if needed.
Jack
packaging@lists.fedoraproject.org
-
Alexandre Oliva -
Bill Nottingham -
Christian Iseli -
Dominik 'Rathann' Mierzejewski -
Enrico Scholz -
Jack Neely -
Jef Spaleta -
Matthew Miller -
Matthias Saou -
Michael A. Peters -
Nicolas Mailhot -
Nicolas Mailhot
-
Ralf Corsepius -
seth vidal -
Steven Pritchard -
Tom Callaway -
Ville Skyttä