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): fedora-ds-base-1.1.1-1.fc9.i386 How reproducible: Every time Steps to Reproduce: 1. Install and configure FDS. 2. Set READONLY=yes in /etc/sysconfig/readonly-root 3. Reboot Actual results: 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. Expected results: FDS should run when /etc and / are read only. Shouldn't /var be used if a file needs write capability? Additional info: 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 /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.