On Thu, 22 Nov 2012, Brian May <brian@microcomaustralia.com.au> wrote:
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@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).
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/