Red Hat Bugzilla – Bug 452342
Fedora Directory Server does not like read only root filesystem
Last modified: 2015-12-07 12:09:54 EST
Description of problem:
I have installed FDS on Fedora 9 and configured it using ipa-server-install. When I configured my
system to boot with a read only root filesystem, FDS would no longer start. The server stated that
/etc/dirsrv/slapd-XXX-XXX/dse.ldif was not writable.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install and configure FDS.
2. Set READONLY=yes in /etc/sysconfig/readonly-root
FDS will not start:
[20/Jun/2008:21:41:10 -0400] dse - The DSE database stored in "/etc/dirsrv/slapd-XXX-XXX/dse.ldif"
is not writeable
[20/Jun/2008:21:41:10 -0400] dse - Unable to write "/etc/dirsrv/slapd-XXX-XXX/dse.ldif": Netscape
Portable Runtime error -5948 (Cannot write to a read-only file system.)
[20/Jun/2008:21:41:10 -0400] - SSL alert: Security Initialization: NSS initialization failed (Netscape
Portable Runtime error -8174 - security library: bad database.): certdir: /etc/dirsrv/slapd-XXX-XXX
[20/Jun/2008:21:41:10 -0400] - ERROR: NSS Initialization Failed.
FDS should run when /etc and / are read only. Shouldn't /var be used if a file needs write capability?
I have mounted /var and /tmp read/write.
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
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:
Base directory for instance specific writable
configuration directories (default
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 firstname.lastname@example.org
(/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
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.
*** 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.