22 Nov
2012
22 Nov
'12
1:03 a.m.
On Thu, 22 Nov 2012, Brian May <brian(a)microcomaustralia.com.au> wrote:
UIDs are 32bit nowadays. So there will still be a lot of spare space.
The problem you are likely to encounter if you use large UIDs is the way some
programs handle them. Last time I tried that (which was some time ago) I had
problems with database files for things like last login which were flat files
with the UID as an index. When a user with a large UID logged in the files
became large sparse files which cause problems with backup programs.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
In my rewrite come across a sticky problem: how do I
reliably and
efficiently allocate unique uidNumber for new users and gidNumber of
new groups?
The current solution, as used by my predecessor, is to list every user
or group in the system, sort or scan though the list looking for the
highest id, add 1, and use that.
Unfortunately, this seems to be lacking in efficiency (specially if
there are a lot of users) and relying on the hope that two users will
never be created at the same time. Race conditions could occur.
It seems to me that there are two ways of avoiding race conditions, one is to
create the object and then search for other objects with the same UID. The
other is to include the UID but not the user-name in the dn, as the dn MUST be
unique an attempt to add a second object with the same UID will fail at the
LDAP protocol level.
On Thu, 22 Nov 2012, "Trent W. Buck" <trentbuck(a)gmail.com> wrote:
The current
solution, as used by my predecessor, is to list every
user or group in the system, sort or scan though the list looking
for the highest id, add 1, and use that.
That strategy renders a lot of UIDs unreachable when some enterprising
fellow manually creates an account with a high UID. I start at the
bottom and and count up until I find an unused one. Both strategies
should be linear with the number of existing users (I think).