Hi folks,
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html - flame, but possible pros and cons can be find there My opinion is not to use fedora-usermgmt.
Note there is possible problem we can reach. We can ran out of static UID(0-100), can't we. ---------- # (repoquery --whatrequires shadow-utils; repoquery --whatrequires /usr/sbin/useradd --whatrequires fedora-usermgmt) | sed 's/-[[:digit:]].*//' | sort -u | wc -l 100 ---------- I think most packages should use dynamic UID (range 100 - 499) and there should be some policy for which packages are allowed to have static UID. I have a patch for useradd and groupadd that they start assigning dynamic UID from 499 way down to 0. What is it good for? Maybe for nothing. :-) But if we run out of static UID one day, it would be good to have gap between static and dynamic UID. We will have to change the range of static ones for example to 0-200 and there is a problem(100-200) during upgrade. Less systems affected with this is better, even thou the solution need to be find. And maybe I'm wrong, anyway.
Peter Vrabec (pvrabec@redhat.com) said:
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
- flame, but possible pros and cons can be find there
My opinion is not to use fedora-usermgmt.
My proposal is to use 100-499 for static as well, and just do static registrations for everything - it's simpler. It can be combined with making dynamic system IDs go from 499 down as well.
Bill
On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote:
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
- flame, but possible pros and cons can be find there
My opinion is not to use fedora-usermgmt.
My proposal is to use 100-499 for static as well, and just do static registrations for everything - it's simpler. It can be combined with making dynamic system IDs go from 499 down as well.
Yes.
Further, I think we should exercise a little caution with the < 100 assignments and only fill that space with things that have a proven track record and are likely to be around and useful for a while. Not, say, random games.
Matthew Miller wrote:
On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote:
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
- flame, but possible pros and cons can be find there
My opinion is not to use fedora-usermgmt.
My proposal is to use 100-499 for static as well, and just do static registrations for everything - it's simpler. It can be combined with making dynamic system IDs go from 499 down as well.
Yes.
Further, I think we should exercise a little caution with the < 100 assignments and only fill that space with things that have a proven track record and are likely to be around and useful for a while. Not, say, random games.
+1.
Bill Nottingham wrote:
Peter Vrabec (pvrabec@redhat.com) said:
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
- flame, but possible pros and cons can be find there
My opinion is not to use fedora-usermgmt.
My proposal is to use 100-499 for static as well,
And what do you plan to do during upgrade if there are some slots already occupied?
I suggest to avoid using static UID as much as possible.
and just do static registrations for everything - it's simpler. It can be combined with making dynamic system IDs go from 499 down as well.
Bill
On Thu, Mar 15, 2007 at 04:34:07PM +0100, Peter Vrabec wrote:
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
- flame, but possible pros and cons can be find there
My opinion is not to use fedora-usermgmt.
My proposal is to use 100-499 for static as well,
And what do you plan to do during upgrade if there are some slots already occupied?
The suggestion of falling back to a dynamic UID is probably best -- then those systems are no worse than before.
On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote:
Peter Vrabec (pvrabec@redhat.com) said:
Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html
- flame, but possible pros and cons can be find there
My opinion is not to use fedora-usermgmt.
My proposal is to use 100-499 for static as well, and just do static registrations for everything - it's simpler. It can be combined with making dynamic system IDs go from 499 down as well.
I don't think that most packages need static uids. And if there are really some that would benefit we still have 40% of the static uid space *empty*.
So there really is no problem that had to be `fixed' in the first place.
Extending the static uid range *now* would be wrong, because we would have to introduce "would-like-to have-static-uid-at-101-but-I-still- have-to-deal-with-getting-a-dynamical-random-uid-if-101-has-been-taken" giving us the worst combination: uid ranges labeled as fixed that the application(s) still cannot assume to be really fixed, so there is no gain today in doing so.
Instead the patch that Peter wrote to make dynamic uid/gid allocation top-down, e.g. from 499 backwards, will allow us to revisit the issue in a couple of years when the static uids really get scarce (we managed a decade with occupying only 60%), and when the probability of having dynamic uids/gids at the lower end (100 upwards) will be much lower than today. In the meantime we can open a discussion with the LSB about rearranging the uid/gid space in future specs.
If that ain't strategic planning ;)