[SAMBA4] LDB modules for LDAP or TDB backends

[Andrew Bartlett]

On Mon, 2006-08-14 at 03:24 -0400, simo wrote:
> On Mon, 2006-08-14 at 16:57 +1000, Andrew Bartlett wrote:
> > On Mon, 2006-08-14 at 02:02 -0400, simo wrote:
> > > Andrew,
> > > I do not think this is the right way to do what you aim for.
> > > 
> > > I'd like you to revert the change and instead build a module, to be used
> > > with the ldap backend, that will remove or change these attributes. This
> > > will make it work even if someone sets them by hands with an explicit
> > > add/modify operation and will leave the rest of code simpler (as it is
> > > now).
> > 
> > Any add/modify attempting to set these should fail.  We have a special
> > case in the provision at the moment, where we want to be able to set a
> > deterministic domain and host GUID, but strictly speaking, it should
> > fail.
> > 
> > > I may integrate the operational/objectguid functionality in the schema
> > > module later on, so you would need to change this code anyway.
> > 
> > As I explained on IRC, I'm just trying to get this as close to the
> > database as possible, so that these backends can choose how to implement
> > it.  The LDAP mapping module chooses to implement this onto the
> > entryUUID field (and standard ldap timestamps), while the objectGUID
> > module sets values into the database.
> > 
> > I could write a filter, using ldb_map, then let the backend handle it,
> > but I fear creating objectGUID values, then filtering them out.  Other
> > modules might read a value that will never hit the disk.  (The
> > local_password module currently needs reworking to avoid just this
> > issue.  But at least now it will clearly fail, not silently fail).
> 
> Given that finally we have per partition modules, I'd say that partition
> specific module shave to be segregated into the single partitions.

That's where this now is, sort of.

> I'd move objectGUID and operational (as they were before the change)
> into the tdb partitions, and use entryUUID and another custom module to
> deal with operational attributes over ldap for the ldap partitions.

I've been thinking about this, and this process will no doubt continue,
as I move more features into modified LDAP backends.

As such, perhaps the correct approach is to break the problem into
*smaller* modules.  The 'openLDAP hacks' then becomes just configuration
items.  I list the modules that I need, removing them one by one from
the per-partition modules configuration as any particular backend
supports the function. 

I think the timestamps and GUIDs are a good fit together, but as we find
features that do vary between LDAP servers (such as the rdn name
support, for example), we can simply remove such a module from the LDAP
partitions module list.

In that fashion, I propose creating a new module 'usn' to handle the
sequence numbers, as operational modules.  This module can then be
disabled when we find a backend that knows how to produce/handle them.
Once this functionality is removed, I hope you can review the
operational module, and agree that it best belongs as is, where is.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com
-------------- 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 : http://lists.samba.org/archive/samba-technical/attachments/20060814/df5bb90f/attachment.bin