Ignacio Coupeau wrote: > > 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.
OK, that make much more sense. But what to do in between the delete and the add? Spin, and hope the entry 'comes back'? Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net