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

Andrew Bartlett abartlet at
Sun Aug 6 00:09:38 GMT 2006

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.

> > 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

> 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.

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
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 :

More information about the samba-technical mailing list