I wrote: > A read-only /usr sounds like more trouble than it's worth: it *will* > break yum updates. So you'll have to regularly remount it read-write > (while the system's on-line) to update the machine. Tim replied: > Yes, that had been on my mind. I don't know if anything else writes to > it. If it does, it's not compliant with the FHS (Filesystem Hierarchy Standard) to which most Linux distributions aim: http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY says: /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Except for stuff like yum, apt, rpm and make install, if it writes to /usr, it's a bug (or possibly an installation error if it isn't installed through RPM). > Well, I've found my first problem: Mounting /var with "noexec" means > that CGI scripts won't run for the web server. Took me a few minutes of > headscratching to realise what had gone wrong, as is the way when the > problem happens some time after a change. I've temporarily removed > "noexec" while I consider if I should move the /var/www/cgi-bin/ > directory out of /var. Well, that explains why I haven't found the problem... FHS suggests /srv instead of /var: http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM says /srv contains site-specific data which is served by this system. ... so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. I don't know if SELinux has rules for it yet. Hope this helps, James. -- E-mail address: james | My friend, you would not tell with such high zest @westexe.demon.co.uk | To children ardent for some desperate glory, | The old Lie: Dulce et decorum est | Pro patria mori. -- Wilfred Owen
