Description of problem: Content in /etc/openldap/slapd.d does not belong under /etc because: * it is neither configurable nor readable by human * it is modified by the slapd daemon At least the last point conflicts with the FHS: "The /etc hierarchy contains configuration files. A "configuration file" ... must be static" http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION Please relocate this directory to /var where it belongs to.
(In reply to comment #0) > Description of problem: > > Content in /etc/openldap/slapd.d does not belong under /etc because: > > * it is neither configurable nor readable by human it is readable by human, if humans can read LDIF define "configurable" e.g. "configurable" means "I can edit it with vi" > * it is modified by the slapd daemon This is the most salient point. But how is slapd any different than some daemon process like cfengine or puppet that dynamically updates files in /etc? > > At least the last point conflicts with the FHS: > > "The /etc hierarchy contains configuration files. A "configuration file" > ... must be static" Please define "static", and explain how other files under /etc that are editable on the fly do not fit this definition of "static". > > http://www.pathname.com/fhs/pub/fhs-2.3. > html#ETCHOSTSPECIFICSYSTEMCONFIGURATION > > > Please relocate this directory to /var where it belongs to.
is cfengine really modifying files below /etc? When it is so, it is broken. Ditto for puppet. > Please define "static" FHS defines "static" as "Static" files include binaries, libraries, documentation files and other files that do not change without system administrator intervention. "Variable" files are files that are not static. and says Static and variable files should be segregated because static files, unlike variable files, can be stored on read-only media and do not need to be backed up on the same schedule as variable files.
>> But how is slapd any different than ... cfengine > is cfengine really modifying files below /etc answering myself after understanding the original question: cfengine modifies its *own* files below /var/cfengine only (the cfinput + database files). Further editing of *foreign* system files is explicitly requested by the administrator and cfengine acts a some kind of 'vi <configuration-file>'. openldap modifies its own "configuration" files as part of its normal operation which requires to move them to /var. > "configurable" means "I can edit it with vi" Correctly. These files are not intended to be edited by 'vi' or any other text editor. E.g. the equivalent of the "configurable" | include my.schema is to compile 'my.schema' either with slaptest or to feed a corresponding ldif file into 'slapadd'/'ldapadd'. afaik, there is nowhere documented how to do this by modifying slapd.d directly.
> >> But how is slapd any different than ... cfengine > > is cfengine really modifying files below /etc > > answering myself after understanding the original question: cfengine > modifies its *own* files below /var/cfengine only (the cfinput + database > files). Further editing of *foreign* system files is explicitly requested > by the administrator and cfengine acts a some kind of 'vi > <configuration-file>'. > > openldap modifies its own "configuration" files as part of its normal > operation which requires to move them to /var. What do you understand by "normal operation"? slapd does not change anything inside /etc/openldap/slapd.d without explicitly requested by system administrator. > > "configurable" means "I can edit it with vi" As you said, cfengine acts a some kind of vi. slapd does the same. > is to compile 'my.schema' either with slaptest or to feed a corresponding > ldif file into 'slapadd'/'ldapadd'. afaik, there is nowhere documented how > to do this by modifying slapd.d directly. man slapd-config http://www.openldap.org/doc/admin24/slapdconf2.html ldapadd -H ldapi:/// -Y EXTERNAL -l my-schema.ldif
>> openldap modifies its own "configuration" files as part of its normal >> operation which requires to move them to /var. >What do you understand by "normal operation"? afaik, hot switching of master/replicant roles was one of the reasons which caused the static slapd.conf -> dynamic slapd.d/ transition. This operation requires modification of slapd.d data. When slapd does not need to modify its own configuration data, why is it writable by the 'ldap' user? Will it operate correctly when /etc is mounted read-only? > As you said, cfengine acts a some kind of vi. slapd does the same. cfengine can act as vi for *foreign* files; out-of-the-box, cfengine does not touch the static configuration data in /etc. When administrator decides to violate FHS by making /etc dynamic, adjusts the backup strategy and ensures that /etc is not mounted ro, he *can* write rules to modify /etc. Current slapd packaging violates FHS by having dynamic data in /etc, requires to adjust backup strategy and makes it impossible to have /etc read-only. > man slapd-config > http://www.openldap.org/doc/admin24/slapdconf2.html this shows that it is very difficultly to edit configuration manually. E.g. inserting a new line might require to renumber dozens of {X} indices. The 80-column lines break readability, manual structuring (comments, empty lines) will be removed by 'ldapmodify' operations. Files are containing a | # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. | # CRC32 69b0b152 like header, which violates /etc semantics (configurable by human) and the CRC32 makes it effectively a binary file. > ldapadd -H ldapi:/// -Y EXTERNAL -l my-schema.ldif This is the problem: 'my-schema.ldif' is the real, human configurable configuration data (although .scheme files where much better readable). Feeding them into ldapadd creates dynamic data which belongs to /var.
> afaik, hot switching of master/replicant roles was one of the reasons which > caused the static slapd.conf -> dynamic slapd.d/ transition. This operation > requires modification of slapd.d data. I don't understand what do you mean. The main reason to switch from slapd.conf to slapd.d is to be able to persist the configuration changes which are performed on-the-fly. > When slapd does not need to modify its own configuration data, why is it > writable by the 'ldap' user? Because this is the way how the system administrator should change the slapd configuration. Using ldapmodify via the slapd daemon. The content of slapd.d is NOT changed unless the administrator requests it. > Will it operate correctly when /etc is mounted read-only? Yes it will. If you try to modify the configuration, you will get error 80 with "Permission denied" diagnostic message. > > As you said, cfengine acts a some kind of vi. slapd does the same. > > cfengine can act as vi for *foreign* files; out-of-the-box, cfengine does > not touch the static configuration data in /etc. When administrator decides > to violate FHS by making /etc dynamic, adjusts the backup strategy and > ensures that /etc is not mounted ro, he *can* write rules to modify /etc. OK. But you still need to remount /etc rw when you want to change the configuration of any service. And it works the same with slapd. > Current slapd packaging violates FHS by having dynamic data in /etc, > requires to adjust backup strategy and makes it impossible to have /etc > read-only. I think you are not right, because the data are not dynamic. And no, it is possible to have /etc read-only with slapd.d. > > man slapd-config > > http://www.openldap.org/doc/admin24/slapdconf2.html > > this shows that it is very difficultly to edit configuration manually. E.g. > inserting a new line might require to renumber dozens of {X} indices. The > 80-column lines break readability, manual structuring (comments, empty > lines) will be removed by 'ldapmodify' operations. > > Files are containing a > > | # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > | # CRC32 69b0b152 > > like header, which violates /etc semantics (configurable by human) and the > CRC32 makes it effectively a binary file. I can read it. And I have no problem with using ldapmodify to edit the configuration. If you as a system administrator do, please, talk to upstream about it and you can suggest some improvements. The current way is their preferred way. There is nothing I can do with it, I'm just a maintainer. > > ldapadd -H ldapi:/// -Y EXTERNAL -l my-schema.ldif > > This is the problem: 'my-schema.ldif' is the real, human configurable > configuration data (although .scheme files where much better readable). > Feeding them into ldapadd creates dynamic data which belongs to /var. No. I do not understand your reasoning for having /etc read-only. Is that security in your case? So why do you want to have slapd.d outside? And what does it change about the backup strategy you mentioned several times? Why don't you use SLAPD_OPTIONS in /etc/sysconfig/slapd to relocate your slapd.d if you need it?
> The main reason to switch from slapd.conf to slapd.d is to be able to persist > the configuration changes which are performed on-the-fly. You are missing the previous part | >> openldap modifies its own "configuration" files as part of its normal | >> operation which requires to move them to /var. | >What do you understand by "normal operation"? Storing the dynamic, on-the-fly changes of the configuration is a new feature of slapd.d. It is documented and advertised upstream and to be considered as "normal operation" hence. Although there might be scenario where slapd.d is never be modified, a similar case might be constructed where the normal LDAP database is never be modified and could be placed in /etc. But both the normal and configuration database are dynamic content now and must not be placed in /etc. > So why do you want to have slapd.d outside slapd.d contains dynamic content (--> modified by the program at runtime) and FHS allows only static data in /etc. > And what does it change about the backup strategy Complete /etc is managed by cfengine here and there is no need to back it up. Adding dynamic content like slapd.d requires to change this.
I will not argue with you. My opinion is clear. Upstream places the slapd.d configuration into /etc. Fedora will do the same. If you do not agree, talk to upstream: http://www.openldap.org/lists/ Sorry, closing as NOTABUG.