[SAMBA4] LDB modules for LDAP or TDB backends
abartlet at samba.org
Mon Aug 14 12:25:27 GMT 2006
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 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
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20060814/df5bb90f/attachment.bin
More information about the samba-technical