Problems creating a Samba4 LDAP Backend
abartlet at samba.org
Wed Mar 19 23:23:02 GMT 2008
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
> > 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.
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080320/b8d474bd/attachment.bin
More information about the samba-technical