Since 1) the behavior is different 2) the slapd.conf to cn=config conversion sucks in the relevant information anyway and 3) use of includes is inappropriate under cn=config is it maybe time for the slap* tools stop creating cn=Includes?
On Tue, 23 Jan 2007, Howard Chu wrote:
Eric Irrgang wrote:
Are olcInclude attributes in cn=config honored as per the Admin Guide section 5.2.2 or is that documentation misleading?
Good question. The short answer is - the use of include files is not recommended for cn=config. They really only work correctly when slapd is using slapd.conf.
Keep in mind - in slapd.conf, you can insert include statements anywhere at all in the config file, you can order them completely arbitrarily, interleaving them with any other config statements. Under cn=config, all of the cn=Includes are grouped under one place, they can't have anything else inserted between them, so if they needed to have other intervening directives processed first, they would fail.
Also, the point of using cn=config is to make every part of the configuration accessible/modifiable using LDAP. slapd.conf-formatted files (e.g. include files) are not accessible or modifiable using LDAP. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
Eric Irrgang wrote:
Since
- the behavior is different
- the slapd.conf to cn=config conversion sucks in the relevant
information anyway and 3) use of includes is inappropriate under cn=config is it maybe time for the slap* tools stop creating cn=Includes?
The conversion creates them to document their existence. In fact after a conversion, when slapd starts up from a slapd.d, the cn=Include records are ignored. This is documented in the slapd-config(5) manpage (which is currently only in CVS HEAD):
The cn=Include entries will only appear in configurations that were converted from slapd.conf format. There can be multiple entries, one for each included file. These entries only serve as placeholders to document the fact that files were previously included. After those files have been read and parsed, their content is merged into the main configuration and then the include files are ignored thereafter. These entries may form an arbitrarily deep subtree, reflecting any nesting of the original include files. <<<
Currently it appears that back-config still allows you to ldapadd Include entries into a running configuration. Probably we should disable that feature.
On Tue, 23 Jan 2007, Howard Chu wrote:
Eric Irrgang wrote:
Are olcInclude attributes in cn=config honored as per the Admin Guide section 5.2.2 or is that documentation misleading?
Good question. The short answer is - the use of include files is not recommended for cn=config. They really only work correctly when slapd is using slapd.conf.
Keep in mind - in slapd.conf, you can insert include statements anywhere at all in the config file, you can order them completely arbitrarily, interleaving them with any other config statements. Under cn=config, all of the cn=Includes are grouped under one place, they can't have anything else inserted between them, so if they needed to have other intervening directives processed first, they would fail.
Also, the point of using cn=config is to make every part of the configuration accessible/modifiable using LDAP. slapd.conf-formatted files (e.g. include files) are not accessible or modifiable using LDAP. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
Howard Chu wrote:
Eric Irrgang wrote:
Since
- the behavior is different
- the slapd.conf to cn=config conversion sucks in the relevant
information anyway and 3) use of includes is inappropriate under cn=config is it maybe time for the slap* tools stop creating cn=Includes?
The conversion creates them to document their existence. In fact after a conversion, when slapd starts up from a slapd.d, the cn=Include records are ignored.
Howard, I also think this is confusing. I'd propose to drop cn=Includes completely. There is no point to document their existence since, as you explained, the order is not preserved.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Eric Irrgang wrote:
Since
- the behavior is different
- the slapd.conf to cn=config conversion sucks in the relevant
information anyway and 3) use of includes is inappropriate under cn=config is it maybe time for the slap* tools stop creating cn=Includes?
The conversion creates them to document their existence. In fact after a conversion, when slapd starts up from a slapd.d, the cn=Include records are ignored.
Howard, I also think this is confusing. I'd propose to drop cn=Includes completely. There is no point to document their existence since, as you explained, the order is not preserved.
I'll look at it. It would be nice to get everything in HEAD to settle down so we can kick out another 2.4 alpha.