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.
>> 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
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.
>>> Does anybody have any ideas or suggestions on how I
could get around
>> 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
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
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.