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.
yes, and is better because several PDC may share the same ldap samba accounts... an several sources of rids may be a bit dangerous.

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.
I read in the OpenLdap list (Kurt, Chu) that the solution is modify *after* delete with previous value required, this ensures the atomicity:
----
dn: cn=rids, o=smb, dc=example,dc=com
changetype: modify
delete: nextRid
nextRid: 15000
-
add: nextRid
nextRid: 15001
-----
also runs with ldap_mod and so.

Ignacio

--
____________________________________________________
Ignacio Coupeau, Ph.D. e-mail: [EMAIL PROTECTED]
CTI, Director fax: 948 425619
University of Navarra voice: 948 425600
Pamplona, SPAIN http://www.unav.es/cti/

Reply via email to