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

RE: SASL Authentication, DNs and supported SASLMechanisms

>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.  

This is how we handle assigning uids and gids.  An object contains the next
number to be used,  when that gets used the app updates the value to x+1.  We
added  a lock attribute that can be set to Y to tell application to wait until
it goes to N.  Not perfect probably but it works,  since only two people add
account object locking simply isn't that big a deal for us (two accounts
created/removed a week).

Systems and Network Administrator
Morrison Industries
1825 Monroe Ave NW.
Grand Rapids, MI. 49505