svn commit: samba r17372 - in branches/SOC/mkhl/ldb-map/modules: .

Martin Kühl mkhl at
Thu Aug 10 09:54:15 GMT 2006

On 8/6/06, Andrew Bartlett <abartlet at> wrote:
> On Sat, 2006-08-05 at 23:26 +0200, Martin Kühl wrote:
> > On 8/4/06, Andrew Bartlett <abartlet at> wrote:
> > > On Fri, 2006-08-04 at 07:25 +1000, Andrew Bartlett wrote:
> > >
> > > The correct approach is (if we need to look in the local db at all) is
> > > to add the attributes you need to search on in the the remote search
> > > tree to the list of attributes (then remove them before passing them to
> > > the caller).
> >
> > I got started with this in r17422, does that work well enough for you?
> I've not looked yet, but will do.

Any news on this?  It works well enough for my own tests.

> > > While the local DB is key to making this work, I really want it to be a
> > > last-resort thing, with partitions and other games used to put most of
> > > the complex problems out of the way.
> >
> > I'm not quite sure what you mean here.
> > The local DB should only be in use currently if the mapping encouters
> > attributes that are unknown to it, or that we are explicitly told to
> > ignore.
> I think we should have an option to 'ignore writes' of an attribute, but
> not put it into any backend.
> We could also allow it to be read, if it happens to be in the remote
> backend.

We could have another type of map that discards attributes in both
parts of `map_attrs_partition' but is treated like MAP_KEEP in parse
Another map type seems most sensible for this.

> > How it is actually used and how we use partitions for the two
> > DBs should maybe be a little less exposed though.
> >
> > > As regards your recent shake up, I think I only need one change (not yet
> > > tested).  This ensures that on 'keep' attributes, we don't change the
> > > name.  (Otherwise, attributes caught by the "*" wildcard record get
> > > renamed to "*").
> >
> > That should be in, thanks for the patch.  And sorry about the stir...
> The new code looks cleaner, so I'm not worried.
> > > I also need an extra feature.  I want a way to add exensibleObject to
> > > the end of every objectClass list (and remove it again on the search).
> > > This will ensure I can get around the painful OpenLDAP schema
> > > restrictions.
> >
> > I took a stab at that in r17427, but I don't really like the
> > brute-force way of simply adding that objectClass to all records.
> > Maybe we could put the infrastructure for objectClasses to use here
> > and add "extensibleObject" if a records data doesn't quite match the
> > mapped objectClasses?  (Not that that would do anything to simplify
> > your small test, but still...)
> We could do schema checks, based on downloaded schema data, once the
> schema module is in place.  For the moment, it should be optional but
> easy for the caller module to enable.

We could let the caller module fetch schema data and create its
`ldb_map_objectclass' structures (the musts and mays, at least) from
Or the ldb_map_init function could accept an optional DN parameter and
fetch schema data from there if set...

I'm not sure how to approach this yet; do you want it in before I
submit my patch?


More information about the samba-technical mailing list