Bug 845642 - move /etc/openldap/slapd.d to /var
move /etc/openldap/slapd.d to /var
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Vcelak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-03 13:10 EDT by Enrico Scholz
Modified: 2013-03-03 20:30 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-06 15:18:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2012-08-03 13:10:18 EDT
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.
Comment 1 Rich Megginson 2012-08-03 13:22:55 EDT
(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.
Comment 2 Enrico Scholz 2012-08-03 13:34:52 EDT
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.
Comment 3 Enrico Scholz 2012-08-03 14:20:53 EDT
>> 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.
Comment 4 Jan Vcelak 2012-08-06 03:36:36 EDT
> >> 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
Comment 5 Enrico Scholz 2012-08-06 09:01:45 EDT
>> 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.
Comment 6 Jan Vcelak 2012-08-06 12:18:07 EDT
> 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?
Comment 7 Enrico Scholz 2012-08-06 13:09:37 EDT
> 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.
Comment 8 Jan Vcelak 2012-08-06 15:18:40 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.