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
     ---------------------------------------------------------


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to