Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote:
> Of course the problem is that if you update on the NFS server, then
> related /etc and /var files [1] will not get updated on the NFS client
> machines and you need to propagate changes there.
One thing to remember is when you export /usr (or "/") over NFS, then
you usually do not expect to install new software often (maybe once or
twice a year), and security updates rarely bring big changes under /etc
or /var.
/etc can be managed with a couple of scripts; if you have a non-trivial
amount of machines you already have the scripts to populate and
customize it for a new machine. After an update, you just re-run that
script for all the clients and you're done.
/var is not an issue either. You can mount it read-only just like /usr
and then you can mount some tmpfs instances over the locations where
write access is really needed. /etc/fstab fragment:
tmpfs /tmp tmpfs size=100m,mode=1777 0 0
/tmp /var/tmp bind bind 0 0
tmpfs /var/log tmpfs size=10m 0 0
tmpfs /var/lib/gdm tmpfs size=10m 0 0
tmpfs /var/lib/xkb tmpfs size=10m 0 0
tmpfs /var/lib/nfs tmpfs size=10m 0 0
tmpfs /var/cache/hald tmpfs size=10m 0 0
tmpfs /media tmpfs size=128k 0 0
You of course need a couple of mkdir/chown commands in an init script to
create some required subdirectories.
If you need persistence, then you mount a writable FS somewhere else,
and you do something like
mount --bind /home/terem/boinc-client/$HOSTNAME /var/lib/boinc-client
(that's from a running cluster setup).
If I take a look of what is actually under /var on that cluster, then I
get:
nfs-server# du -s .
147300 .
nfs-server# du -s cache lib/apt lib/aptitude lib/dpkg log
[...]
135616 total
So even if you want a local /var on every machine, you can ignore over
92% of the data when you synchronize with say rsync (you can actually
ignore even more, but then the above "du -s" line would have been too
long).
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Reply to: