Problems creating a Samba4 LDAP Backend

[Andrew Bartlett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080320/b8d474bd/attachment.bin