Brian May wrote:
In my rewrite come across a sticky problem: how do I
efficiently allocate unique uidNumber for new users and gidNumber of
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).
Unfortunately, this seems to be lacking in efficiency
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
Only solution I can think of is to create a special
atomically allocates ids. Seems a lot of work for something so
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
getent passwd | cut -d: -f2 | sort | uniq -c | grep -v '^1 ' |
sed 's/^/ERROR: duplicate UID detected!/'
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.