[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Determining the next uniqe attribute value to use with an account entry

--Le lundi 10 septembre 2001 23:22 -0400 Kevin.Serikstad@cox.com écrivait:

Hi All,

	 Let's try this again with a different heading. Sorry.

I was wondering if anyone sees any practical problem with having an
entry store the next available values for attributes such as uidNumber
and gidNumber. In my case, I intend to use the values more as a hint
on where to start looking rather than to act as a definitive answer.

For example, I have an entry which looks like the following

dn: cn=LDAPkeys,cn=config,cn=dbdata
objectClass: top
objectClass: LDAPkeyObject
nextuidNumber: 300200

A script to add user accounts consults the nexuidNumber attribute,
increments it by one and then checks to make sure it's not alreay in
use. If it is, it looks for the highest nextuidNumber and updates the
nexuidNumber value.  This just seems faster than pulling all the
uidNumber attributes from all my account records to determine what the
next available id is. I intend to use the cn=LDAPkeys entry for any
attributes requiring lookups for unique values (gidNumber, etc).

Again, I was wondering if anyone has any practical advice on the
handling of unique attribute value lookups.

Thanks.

Kevin Serikstad 

I'm not sure I quite understand your proposed method.

I myself have had the same problem and have tried several methods.

The one I currently use is to generate a random value within the range you have assigned for your uidNumbers; and then to test if it is already in use (with a search for uidNumber=value; uidNumber has index "eq"). If it is, generate another value, and so on until you find a free one.

This method works rather well as long as the assigned range is not close to saturation. If you use, for instance, 90% of the values in the assigned range, you will have an average of ten attempts for each new user.

This method also implies setting up some locking mechanism if more than one agent is to add accounts.

An alternative method I have mused with was to maintain in some part of the hierarchy a collection of entries, one for each free uidNumber value. You delete the corresponding entry each time you add a user, and recreate when you delete that user. You don't need an external locking mechanism here if you check the return value of the delete and add LDAP operations.

You might also maintain an incomplete collection of such entries. A background process would add to this collection each time the number of entries became less than, for instance, 100 entries. This background process could use the random method I described above to locate free values.

----
David Olivier

First Veggie Pride, Paris, 13 October 2001 !!
 <http://www.veggiepride.online.fr/>