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

back-config, includes

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:

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