back-config, includes

[Howard Chu <hyc@symas.com>]

There are still some decisions to be made re: how to handle include 
files. Since the goal is to have all configuration information stored in 
a single fully modifiable backend database, keeping bits of 
configuration info in separate include files doesn't make a lot of 
sense. There have been a variety of reasons to use include files in the 
past, but ultimately I think they'll have to be phased out.

For the primary use - loading schema, the best solution that comes to 
mind is to create a cn=schema,cn=config subtree where individual entries 
under this subtree comprise what used to be an individual schema config 
file. Since back-ldif stores individual entries in individual files 
anyway, we can still ship individual schema files. They'll just need to 
be copied from the install directory into the proper subdirectory of the 
config directory. (Or I suppose we can set a symlink at install time.)

e.g., given a LDAP_SYSCONFDIR of /etc/openldap the default config 
directory is /etc/openldap/slapd.d. The entry for "cn=config" is stored 
in /etc/openldap/slapd.d/cn=config.ldif. Children of cn=config appear 
under /etc/openldap/slapd.d/cn=config/ and cn=schema would appear as 
/etc/openldap/slapd.d/cn=config/cn=schema/ and .../cn=schema.ldif. We 
could copy schema files into there as something like:
   cn=config/cn=schema/schema={0}core.ldif
   cn=config/cn=schema/schema={1}cosine.ldif
   cn=config/cn=schema/schema={2}inetorgperson.ldif
...

Their presence in the tree would cause them to be loaded at server start 
time, along with everything else. One inconvenience is that when you 
manually copy these files into place, you need to manually assign the 
ordering index ( '{xx}' ) to assure that they're loaded in the desired 
order. (You can't rely on their creation order; filesystems like 
reiserfs don't manage their directories as linear structures so 
opendir/readdir doesn't return directory entries in their creation order.)

I think this type of organization will make schema editing a bit easier 
as well; since you can retrieve a single entry you don't have to sift 
through the entire defined schema (as you do when querying the DSA's 
subschema subentry) to find the parts you're interested in. As for 
schema editing in general, my plan was to only allow adding of new 
schema, not modifying of existing schema...

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