Need to split this into another thread.
See followup posts with the subject "about sharing filesystems".
Here's a little work-in-progress to articulate "how to do it properly" ...
http://docs.google.com/View?id=dc6n97p5_10gtjp5rzq
To some of your points ...
> /var contains per-system data that cannot be shared. Some of it (rpm
> databases, yum/yast/you/whatever files) that reflect the contents of the
> (shared) /usr and the (per-system) /etc.
The RPM database is just one case. Where sharing of other filesystems
is in play, one can readily recreate the RPM database. Or you can
copy it from some master disk. Or you can redirected it away from
/var (like to a master copy), but my recommendation would be simply to
maintain it (or rebuild it) using multiple references as needed.
Strictly speaking, the RPM DB is not needed for the operation of your
system but only for the maintenance of your system, so the only RPM DB
copy which really needs to be correct is the one on the maint system.
> For example
> glibc - contains files in /usr, /etc and /. /var contains the rpm
> database, so all have to be kept in step, unless you don't want to know
> what is installed.
See above for discussion about /var. The GLIBC pieces under /etc are
few. In fact /etc/ld.so.conf and /etc/nsswitch.conf are candidates
for change. (/etc is the "personality" directory - it must go along
with each system and must be unique unless you want to get even
trickier) The root and /usr can be kept in synch as part of "the op
sys". If you choose to have a shared /usr and a writable root, and
you then upgrade or change the master, you have the burden of
reconciling things in the root. This can be done (but lately I'm in
the shared root camp).
Don't be caught up in what the packaging throws at you. Know it, yes,
and consider the requirements, but then let your decision be based on
your needs. If you want to share filesystems, you can! And you can
still use RPM, but yes, you have to know what RPM is doing.
I'll post a short followup with the subject "about sharing filesystems".
-- R; <><
On Wed, Jun 17, 2009 at 00:29, John
Summerfield<deb...@herakles.homelinux.org> wrote:
> Rick Troth wrote:
>
>> Virtualization of systems is about sharing of resources.
>> So think hard about sharing disks and not just memory and CPU.
>> On this point, cloning has a little edge. But both cloning and
>> jumpstarting (as usually implemented) suffer from difficulty
>> ferreting out the shared and sharable stuff from the per-system stuff.
>> But it can be done. Put the sharable stuff onto shared disks.
>>
>>
>> Got maint?
>> Apply your maint to the R/W copy, stamp out a new shared disk
>> from that copy, point the "client" systems to it, instant upgrade
>> of 500 servers without running 500 instances of RPM (or whatever).
>>
>>
>> There is always some per-system content
>> which must be either copied (clone) or deployed (kick).
>> The personalization of that per-system part is where jumpstart
>> has a little edge. Ideally, the personality would be retained
>> even if the rest of the op sys were blown away (er, uh, upgraded).
>> This is a little harder to do than sharing the op sys, but it can
>> be done. Start with the easy stuff, like user home directories.
>
> There has been some discussion here before on sharing operating system
> files/volumes.
>
> A problem I see, have raised before, and not seen (or have forgotten) is
> how to do it properly.
>
>
> / (root filesystem) can be shared, with some care.
> /boot ditto
> /usr can be shared without restriction
> /etc contains per-host data, but it can be recreated by non-standard
> means at IPL time. Care needs to be taken when changing its content, to
> ensure the next IPL doesn't lose the changes.
>
> /var contains per-system data that cannot be shared. Some of it (rpm
> databases, yum/yast/you/whatever files) that reflect the contents of the
> (shared) /usr and the (per-system) /etc.
>
> For example
> glibc - contains files in /usr, /etc and /. /var contains the rpm
> database, so all have to be kept in step, unless you don't want to know
> what is installed.
>
> If I were your support supplier, I would not be keen on supporting this
> in my standard contract.
>
>
>
>
> --
>
> Cheers
> John
>
> -- spambait
> 1aaaa...@coco.merseine.nu z1aaaa...@coco.merseine.nu
> -- Advice
> http://webfoot.com/advice/email.top.php
> http://www.catb.org/~esr/faqs/smart-questions.html
> http://support.microsoft.com/kb/555375
>
> You cannot reply off-list:-)
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
