[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-config

Ralf Haferkamp wrote:

On Wednesday 02 March 2005 06:10, Howard Chu wrote:


Now that I've got all of the frontend and back-bdb config keywords
implemented (read-only) I'd appreciate some feedback on the schema
etc. before moving ahead to doing the write operations.


It's great to see this feature getting implemented. One thing I was missing during a quick test is the "index" directive for back-bdb. But maybe that just not implemented right now.

Heh, yes, my announcement was premature, that's not implemented yet but of course will be.

One thing I currently don't quite understand in the purpose of the olcIncludeFiles Objects. Is it planned to have the contents of include file available in the future as well? Or is it just to have the possibility to add/delete the includes? As long as one has only schema definitions in includes files this might be enough, but some people like to have other stuff there (e.g. to have the access rules in a separate file).


I guess for now the only purpose is add/delete. I have a couple other items stashed in there (modload/modpath, rootdse) simply because they had no other storage location yet, but overall I'd rather not have the (physical) include file hierarchy affect the (logical) configuration hierarchy. It's especially problematic since there's no structure enforced in include files, so clauses that constitute a single config object can be scattered across many files. A direct representation of that layout would result in a lot of incomplete object slices scattered across the include tree, too incoherent for manageability.

On the other hand, I also envisioned Include directives being of labeledURI type, and allowing the config tree to be shadowed from a remote server. In general it would only be a bootstrapping step; all the information would be stored locally and would then allow further updating locally. When/how to handle refreshing from the remote is a big question -
do you refresh it at all?
what if remote updates overlap local changes?
Some policy needs to exist for conflict resolution (just as in any multimaster replication). It is unlikely that any of this will get implemented very soon.

On the topic of schema, I'm considering extending the local schema management to allow working with multiple AVL trees. Then I would associate one per include file, to allow managing schema where they are declared (in addition to adding them to the global tables). I also thought about creating another cn=config - specific subschema subentry, to show only the schema that are part of the config mechanisms. As such, loaded user schema will always appear in two places - the global subschema subentry and the config file entry that declared them, and config schema will appear in the global subschema subentry and in the config schema entry.

Having gone thru all of this config stuff, a lot of other ideas came
to mind:

slurpd replica configuration should probably have both an included
and excluded attrs list, like syncrepl does. It would greatly
simplify the exclusion processing in repl.c. Also, deleting the
an_oc_exclude flag from the AttributeName structure would simplify
things too.

I wonder if replication (syncrepl and slurpd) directives should be in
their own objects, subordinate to the database object.


Yes, and IMO the same applies for the access control directives. I think that would make it more clearly laid out.
E.g. having "cn=access,olcDatabase={1}bdb,cn=config" for database specific ACLs and either "cn=access,olcDatabase={0}frontend,cn=config"
or "cn=access,cn=config" for global ACLs.


Just using cn=access,olcdatabase={0}frontend for the global ACLs would make things easier, yes.

My first prototype of this framework worked this way, but converting it from OpenLDAP 2.0 to HEAD proved to be rather difficult, so this code is starting over from scratch. But that's a useful concept that I need to carry over. Thus the framework needs to support nesting of arbitrary objects, with some (ditStructure) rules to dictate some simple limitations (e.g., Access objects can only be children of Database objects.)

Hmm, I just recognized that at the moment global ACLs show up in both Objects (cn=config, and olcDatabase={0}frontend,cn=config). I guess this isn't wanted?


Nope. I'll remove the access attribute from the cn=config objectclass.

I find writing schemas unbearable without using OID macros. It would
be nice to use them more overtly, using unqualified names (e.g.,
DirectoryString instead of my current OMsDirectoryString).

Some of the back-config retrieval functions will no-op if they're in
their default values, but many of them just return a value, default
or not. The goal was to to return only as much text as would have
been in the slapd.conf file originally, but more consistency would
probably be better here.


--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support