Atomic RID allocation in LDAP

[Steve Langasek]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20021012/113bc90e/attachment.bin