On Wed, 2008-03-19 at 04:26 -0700, Howard Chu wrote: > Andrew Bartlett wrote: > > Over the past few weeks, I have been testing OpenLDAP as a backend for > > Samba4. > > > > I've been working with the OpenLDAP team on my requirements, and there > > has been some really good outcomes - the memberOf module has been > > improved, as has the refint module. > > > > However, I seem to have hit a brick wall, in the form of (internal) > > transaction support. I need an LDAP backend to support internal > > transactions - that is, when for example a 'member' modification is > > made, all the memberOf attributes must be updated before the call > > returns. Similarly, if a user or group moves, all the member/memberOf > > attributes that link the user to their groups must also move, before the > > modrdn returns. > > > > The Samba4 test ldap.js tests this behaviour extensively, because I want > > to be sure it works. > > > > As understand the discussion I've had with the OpenLDAP team, OpenLDAP > > does not support this, and will not support it for perhaps some time. > > I may have overstated the problem in the previous discussion of our refint > module. In fact, RE24 was already changed to work around any potential > deadlock issues a long time ago. But to give some context: the refint module > was originally written to operate synchronously (back in 2004). Some time > later it was changed (2006) to asynchronous mode because users didn't want > their clients to be stuck waiting for all the cascaded updates to complete. > Most clients don't know or care that a particular change has side-effects. We > could introduce a config keyword to select synch vs asynch behavior here, but > I have a feeling that will still leave some group of users unhappy no matter > how you set it. Great. If run sync, will it error out correctly if I make an invalid modification (say target not present etc). > > Similarly, from discussions with the Fedora DS team at the CIFS > > developer days, I understand that it is similarly very unlikely that > > Fedora DS will support internal transactions. (It also does not support > > subtree renames, which we also need). > > > > The fact that LDAP does not expose a transaction API > > You mean draft-zeilenga-ldap-txn ? I suppose I should have said 'The free LDAP implemetnations I'm looking at don't expose a transaction API'. What did end up happening with that draft? > > was always going to > > be a difficult part of having Samba4 use an LDAP backend, but I always > > assumed that if we pushed the really hard bit - updating linked > > attributes - into the LDAP server that we could at least always have a > > consistent DB. (It turns out this is one of the primary uses of > > transactions anyway.) > > > But without that consistency, and without knowing as a caller if all the > > updates succeed, I'm worried about how we can safely move forward. > > > This is especially disappointing because I was hoping that these free, > > replicating LDAP servers might solve the backed replication problem for > > me, without needing to use AD replication. > > > > Does anybody have any ideas or suggestions on how I could get around > > this? > > There are other ways to guarantee consistency. The simplest approach is to > just not store one end of the linked attributes, and always generate them > dynamically when they're referenced. > > In the old Symas Connexitor EMS product we used (the equivalent of) a > UUIDAndOptionalName syntax for all references. In that case the DN was > essentially just window-dressing; we always used the ID to actually reference > entries and we updated the DNs whenever we found that they didn't match. As > such, referential integrity was pretty simple - you never had anything > pointing to the wrong entry; the worst that would happen is that you > occasionally had dangling references to deleted entries stored in the DB but > no one ever saw them because they were cleaned out whenever the entry > containing the reference was read. Do you think the LDAP backend could/should handle this, or will Samba4 have to do the GUID -> DN and DN -> GUID translations before passing things to the backend? > > Should we drop the LDAP backend as a nice idea, but not going to work, > > and focus on DRS or some other form of replication? > > > > Can someone imagine a sane way to reconstruct the DN links, including > > subtree renames, without the help of the LDAP backend? Could we ban > > subtree renames (as Fedora DS does), and try to handle this ourselves > > (with pre/post checks and a good deal of prayer)? > > Banning subtree renames seems like a non-starter, and it only eliminates one > case; the overall problem still remains. Indeed. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
Attachment:
signature.asc
Description: This is a digitally signed message part