Problems creating a Samba4 LDAP Backend

[Andrew Bartlett]

On Wed, 2008-03-19 at 17:09 -0700, Howard Chu wrote:
> Andrew Bartlett wrote:
> > On Wed, 2008-03-19 at 04:26 -0700, Howard Chu wrote:
> >> 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).
> 
> No. We specifically don't validate the original modification here - the 
> server's number one job is always to try to do exactly what the client 
> specified. Also, you can't reliably detect an "invalid" name - it may simply 
> be the name of a non-local entry.

This is going to get painful then...

> >>> 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?
> 
> It's stalled, like a lot of other things... It is partially implemented in 
> OpenLDAP. Eventually we'll have to complete the implementation, it's too 
> important to leave dangling.

OK.

> >>> 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?
> 
> That would only be practical if you had LDAP transaction support....
> 
> It strikes me that the best approach is to just dynamically generate the 
> memberOf values instead of storing them statically. But that also depends on 
> your usage patterns.

Well, searches on member and memberOf are common, so it seems we would
quickly find ourselves downloading the whole backend DB and filtering
locally...

I would hate to give up on this area of work - if only because I've put
a lot of time into it, and it seems like a really useful way to use
Samba4, but it also seems that I've found a rat-hole, with far more to
it than I ever imagined.

Any further thoughts on how we can resurrect this would be most
appreciated. 

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/76aa8328/attachment.bin