Endi's Bug 7530 patches (LDAP backend)
Endi Sukma Dewata
edewata at redhat.com
Mon Jun 28 18:41:50 MDT 2010
----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> > s4/dsdb: Fixed partition_search() not to pass special DN's to
> LDAP backend.
> > s4/auth: Fixed authsam_expand_nested_groups() to find entry SID
> if not available in the DN.
> I'm sorry, but both these patches are totally wrong. Endi's patches are
> usually very good, but these are based on incorrect starting assumptions.
These were meant to be a conversation starter. ;) I didn't expect it to be
accepted as is.
> The partitions patch will, as I read it, totally break replication, as
> it will remove the search for @REPLCHANGED from being propagated down to
> each backend database. (so we know if a particular database needs
Is this currently working with OpenLDAP? So far I found that this is only
used by the repl_meta_data module which is only used with the default LDB
backend. Should repl_meta_data be used with other LDAP backends as well, or
should Samba rely on the replication feature of each LDAP server?
If the @REPLCHANGED entry is supposed to be written into LDAP backend, does
it mean each backend has to map it to a regular LDAP entry (with a regular
LDAP DN)? Why not just use a regular LDAP entry in the first place and
define the schema for it?
> The expand_nested_groups patch will work, but I do not wish us to take
> this approach. The LDAP backend needs to provide, one way or another,
> this information - if we start to have fallbacks in the code, we will
> duplicate the whole extended DN infrastructure in each caller. The
> OpenLDAP backend provides this by a server-side module, and either
> Fedora DS must do the same, or fake it up in a Samba module at the
> bottom of the stack.
Could you point me to the OpenLDAP module that handles this? Thanks!
Endi S. Dewata
More information about the samba-technical