Brian May 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.
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). http://www.cyber.com.au/~twb/snarf/ldapadduser
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.
I address that by wishful thinking (well, we do not get new staff very often). Since mine is a simple shell script, and it only works on the LDAP server itself (-Hldapi:/// -YEXTERNAL -- the LDAP server is deliberately has no superuser dn), I could probably bolt in lockfile-progs.
Only solution I can think of is to create a special server that atomically allocates ids. Seems a lot of work for something so simple.
Any ideas for other solutions?
Solve it at the policy level? E.g. tell everyone to create new users by telling Fred to do it, and telling Fred not to compulsively hit refresh when the page is slow to load. IME trying to avoid such a race condition is VERY likely to introduce bugs that crop up FAR MORE OFTEN than the original hypothetical race condition. Has the race actually happened yet? Maybe a quick kludge would be something like @hourly nobody getent passwd | cut -d: -f2 | sort | uniq -c | grep -v '^1 ' | sed 's/^/ERROR: duplicate UID detected!/' @hourly nobody getent group | cut -d: -f2 | sort | uniq -c | grep -v '^1 ' | sed 's/^/ERROR: duplicate GID detected!/' so the race can still happen, but at least you'll get an email about it before too much damage can occur.