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.
Description: This is a digitally signed message part