22 Nov
2012
22 Nov
'12
5:34 a.m.
Jason White wrote:
Brian May <brian(a)microcomaustralia.com.au>
wrote:
This breaks as soon as anything else edits the LDAP objects, because
your variable that remembers max-curr-uid will be out of sync.
Are your LDAP queries so slow that it matters? I don't think mine are...
$ time ldapsearch -xLLL objectClass=person uidNumber >/dev/null
real 0m0.006s
user 0m0.010s
sys 0m0.000s
This is LDAP, the order the server gives the
results is undefined.
Can you look up a user/group by ID? If so, one idea would be:
1. Perform an initial scan of the users/groups.
2. Cache (i.e., memoize) the greatest uid/gid.
3. To add a new user/group, retrieve the highest uid/gid from the
database/file/whatever, then probe consecutive uids/gids until an unused one
is found, then (locking if necessary) allocate a new user/group and update the
stored value accordingly.
This way you only perform the expensive scan once.