Bug 452342

For a temporary workaround, I have moved /etc/dirsrv/slapd-XXX-XXX/ to /var/lib/dirsrv/etc-slapd-
XXX-XXX. I then made a symbolic link back to /etc/dirsrv/slapd-XXX-XXX. This allows FDS to start.

The symlink workaround is your best bet.

Fedora DS allows you to update the config dynamically, over LDAP.  So when you
change cn=config, those changes are immediately flushed out to dse.ldif.  And
it's not just user-initiated changes, especially if you are running replication,
because we save state information here too.

When we moved from the old style of a single prefix to the FHS layout, there was
a big debate about this issue - config files should go in /etc, writable files
in /var/lib.  But what about writable config files?  There was no clear answer
at the time, so we decided to go with /etc, and group all of the config files
together, read-only (e.g. key/cert db files) with the writable ones for
simplicity.  We figured savvy admins would use a symlink if they wanted to mount
/etc read-only.

If you build from source, you can specify a different directory to be used for
instance configuration files - see configure --help for details.

One problem with the symlink solution is that it has the potential to break SELinux. If I run restorecon, then the context of the files in directory pointed to by /etc/dirsrv/slapd-XXX-XXX will be given the context associated with /var/..., not /etc/... . This could cause problems down the road if the SELinux policy becomes more restrictive. Stuff in /etc/dirsrv/slapd-XXX-XXX will not be labeled as the SELinux policy developer intends.

The FHS 2.3 says (emphasis mine):

The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; *** it must be static *** and cannot be an executable binary.

Later, it admits:

mtab does not fit the static nature of /etc: it is excepted for historical reasons.

Yes, this will cause problems for selinux.  But note that there are many tools such as puppet and cobbler that attempt to modify files in /etc at run time, in order to push out configuration changes to manage multiple systems.  There are also other files in /etc/sysconfig/* that are meant to be modified.  How do admins reconcile this with the need to mount /etc read-only?

OTOH, I've heard that debian and possibly other distros enforce a strict read-only file system mount of /etc.  I guess you have to get your configuration correct, then change the mount to read-only.  I can certainly see where this helps with security.

(In reply to comment #4)
> OTOH, I've heard that debian and possibly other distros enforce a strict
> read-only file system mount of /etc.  I guess you have to get your
> configuration correct, then change the mount to read-only.  I can certainly see
> where this helps with security.

Yes. That is my intent. In my mind, /etc should support an optional read-only mount. I suspect this is why the FHS folks define /etc as they do. It's also more than security. It's sometimes necessary for someone to validate a configuration and then deploy it in such a way that possibly well-meaning subordinates won't accidentally sudo a change. Or, at least, a read-only mount reinforces this policy even if it can be circumvented with some work.

The way Fedora DS works, dse.ldif must be writable.  dse.ldif cannot live on a read-only file system.

The alternative is that fedora ds can be built with a different instance configuration directory at configure time:
  --with-instconfigdir=/path
                          Base directory for instance specific writable
                          configuration directories (default
                          $sysconfdir/$PACKAGE_NAME)

The default is /etc/dirsrv (that's what $sysconfdir/$PACKAGE_NAME expands to if doing an rpmbuild).  So you could build fedora ds and specify /var/lib/dirsrv or something like that.  Then you would have /var/lib/dirsrv/slapd-instance/dse.ldif, schema/, cert8.db, etc. etc.

Why can't dse.ldif be placed in /var/lib... by default? This seems to be what the FHS whould expect. Other files, such as schemas, that don't typically change once a system goes live could remain in /etc.

(In reply to comment #7)
> Why can't dse.ldif be placed in /var/lib... by default? This seems to be what
> the FHS whould expect. Other files, such as schemas, that don't typically
> change once a system goes live could remain in /etc.    

by using configure with the --instconfigdir=path argument, you can place dse.ldif wherever you want.  As far as why /etc was chosen as the default location - we debated this long and hard, and the FHS was just not crystal clear about this.  We finally decided that, since dse.ldif is a config file, most people would expect it to be somewhere under /etc.

[root@testvm ~]# vim /etc/sysconfig/readonly-root
[root@testvm ~]# reboot

Broadcast message from root.redhat.com
	(/dev/pts/0) at 16:25 ...

The system is going down for reboot NOW!
[root@testvm ~]# Connection to 10.65.201.178 closed by remote host.
Connection to 10.65.201.178 closed.

[root@testvm ~]# service dirsrv start
Starting dirsrv: 
    testvm1...[19/Jul/2011:16:27:51 +051800] dse - The DSE database stored in "/etc/dirsrv/slapd-testvm1/dse.ldif" is not writeable
[19/Jul/2011:16:27:51 +051800] dse - Unable to write "/etc/dirsrv/slapd-testvm1/dse.ldif": Netscape Portable Runtime error -5948 (Cannot write to a read-only file system.)
[19/Jul/2011:16:27:51 +051800] - SSL alert: Security Initialization: NSS initialization failed (Netscape Portable Runtime error -8187 - security library: invalid arguments.): certdir: /etc/dirsrv/slapd-testvm1
[19/Jul/2011:16:27:51 +051800] - ERROR: NSS Initialization Failed.
                                                           [FAILED]
  *** Warning: 1 instance(s) failed to start

:( If it was not fixed? then what I need to test?
I saw no patch here after when I executed above commands...
now I want my root as normal?? How should I do that :(

Ok, I fixed my problem using single user mode..
But testing is pending for the bug.

Fixed/verified upstream.  The directory server can be built with an alternate location for distros other than RHEL or Fedora.

Based on comment#11 marking the bug as VERIFIED.