21 Nov
2012
21 Nov
'12
11:54 p.m.
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.