Re: back-config

[Ralf Haferkamp <rhafer@suse.de>]

On Wednesday 02 March 2005 13:36, Howard Chu wrote:
> Ralf Haferkamp wrote:
[..]
> >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.
Ok, after this statement and playing around at with back-config and 
include files I now have a better clue how include file are handled. I 
saw that the contents for the included files are merged directly into 
the tree where they belong (e.g. the content of an include file with 
access directive included from a database definition is merged into 
e.g. the cn=access,olcDatabase={1}bdb,cn=config object). IMHO a good 
approach. I guess I missunderstood the concept of the olcIncludeFiles 
Objects before.

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

-- 
Ralf Haferkamp
SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg
T: +49-911-74053-0
F: +49-911-74053575 - Ralf.Haferkamp@suse.com