Le 02/05/2015 14:40, Hendrik Boom a écrit :
> On Thu, Apr 30, 2015 at 11:42:24PM +0200, Didier Kryn wrote:
>> Le 30/04/2015 20:16, John Morris a écrit :
>>> The FHS was carefully designed to accomodate things like NFS root,
>>> readonly NFS mounting of parts of the system, mandating things like
>>> */share/ to only contain arch neutral data, etc.
>> The whole FH can be shared by NFS root, except /var, which
>> cannot be shared entirely and /run (formerly /var/run) which cannot
>> be shared at all - talking about Debian's FH.
>>
>> The problem is /var/lib which must be carefully separated in two
>> parts to distinguish applications which keep common data (eg apt)
>> and applications which keep hardware-related data (eg ntpd). Then a
>> few dirty tricks are necessary to make the two categories look like
>> they are all in /var/lib.
>>
>> I don't know if the question of sharing the FH through NFS is
>> seriously addressed by the FHS; but, if it is, it fails.
>>
>> Didier
> Years ago I heard that /usr could be mounted read-only, and even shared
> between different running copies of Linux by an NFS mount.
>
> But I've never seen a distro that took this seriously enough that a
> routine upgrade (with something like aptitude upgrade) would work.
>
> -- hendrik
>
Debian, like most distros isn't targetting diskless machines,
although the initscripts are clever enough to detect the nfs-root and
not reinitialize the associated network interface :-) Beyond that, you
need to hack the system a little bit anyway.
If you install a distro, say Debian, on diskless hosts, you cannot
have the system directories mounted read-only because you want to
periodically upgrade your system or add new packages. It is possible to
achieve a working configuration in which you can run apt - even synaptic
- from any host, updating the common OS. Everything is mounted
read-write but you need one /var/lib-xxx subdirectory named after the
host id, eg the MAC address of eth0, and a double symlink going through
/run for each non-shareable subdir of /var/lib. /run is mounted on
tmpfs of course and therefore is not shared. The logs must all be resent
to a central server by a simple config of rsyslog. There are still a few
files remaining in /var/log which must also be on tmpfs.
So the most delicate issue is to guess which subdir of /var/lib
must be shared and which must not - I don't know if there are some for
which it doesn't matter. I think there should be something like a
/var/lib/nonshare and/or a /var/lib/share or something like that, so
that applications use one of them depending on their nature, instead of
all using /var/lib. This is a place where a convention is necessary.
I've been using Debian like this for years, with setups made of an
nfs-server on amd64, six diskless powerpcs and a log server. But I still
feel unsafe about the dispatching of /var/lib subdirs. It's a setup on
which we needed to develop and maintain a big multi-host data aquisition
system, written in Ada; therefore a full-featured distro was necessary,
which included the gnat compiler - not something you can get with the
typical embedded distro.
Didier