On Sat, Oct 12, 2002 at 07:17:10PM +1000, Andrew Bartlett wrote: > I've been thinking about the problem of allocating RIDs in LDAP.
> We need a race-proof scheme to allocate RIDs, and I would prefer not to > need to use a local TDB - I would like it all 'in ldap', if at all > possible. > While the real solution is an LDAP server that imposes restrictions on > attributes (like uniqueness constraints), we will have to settle for > what we have... > Could we use LDAP DNs for this purpose? An LDAP distinguished name must > be unique - so why don't we have a separate 'allocation suffix' > so cn=rids,dc=example,dc=com would contain: > nextRid,cn=rids,dc=example,dc=com > rid=1000,cn=rids,dc=example,dc=com > rid=1001,cn=rids,dc=example,dc=com > rid=1002,cn=rids,dc=example,dc=com > A program wanting to allocate a RID would first read nextRid, and > attempt to add that RID. If it succeeds, it updates nextRID. If it > fails, it re-reads nextRid, and if unchanged adds 1 to the RID, and > tries again. > While this generates a lot of DNs, I think it gives us a unique way to > allocate these... (Which is much better than the racy stuff we have > now). > It's also a relitivly simple scheme, so we have a fighting chance that > external LDAP admin tools might use this too, when adding Samba > attributes. What I've come to use locally for UID and GID allocation is a lock DN, of the form type=uid,ou=Locks,dc=example,dc=com. The object contains attributes identifying the host and process holding the lock, which has unfortunately been necessary, because we do get deadlock from time to time. Here are the required schema definitions: attributetype ( 1.3.6.1.4.1.13280.2.1.2.1 NAME 'pid' DESC 'numeric, host-specific ID of process holding lock' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) objectclass ( 1.3.6.1.4.1.13280.2.1.1.1 NAME 'recordSearchLock' DESC 'Record for locking a section of the directory for writing' SUP top AUXILIARY MUST ( pid $ host ) ) Though it seems wasteful to me to have to create another object for every allocated RID, the one interesting advantage your method has is that it makes it possible to keep track of RIDs that have been allocated in the past, even after the associated user has been deleted -- which IIRC is how Windows treats RIDs. Steve Langasek postmodern programmer
msg03665/pgp00000.pgp
Description: PGP signature