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

Re: back-config, includes

Hallvard B Furuseth wrote:

Howard Chu writes:

(...) 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.

Our site has two schema directories: The directory which OpenLDAP installs with its own schema files, and a directory outside LDAP_SYSCONFDIR with our other schema files. LDAP_SYSCONFDIR contains the OpenLDAP version name, so we have to copy the configuration (*.conf) from the last installation to the current one and edit it a bit.

It's not the biggest problem in the world to create symlinks between the
two, but if others have the same setup, remember that there are
filesystemes that do not support symlinks. And _copying_ schema files
from the private schema directory to the installation directory could
easily lead to mismatches - one would edit a file in one directory but
forgot to copy it to the others.

OK. Well, the include functionality is still present, but I still believe it should be deprecated.

We could copy schema files into there as something like:
(...) 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.

These "strange" characters "={}" in file names worry me.  They are
simple to use on Unix, but there may be filesystems where they mean
something special, or operating systems where they are difficult to
quote or mean something special unless one takes great care.

You're welcome to suggest something else. There's no reason that the character used in the filesystem needs to be the same as the one in the DIT, but it would be a bad idea to make the DIT representation vary.

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