:: Re: [Dng] [dng] vdev status updates
Góra strony
Delete this message
Reply to this message
Autor: Didier Kryn
Data:  
Dla: dng
Temat: Re: [Dng] [dng] vdev status updates
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