That still does not seem to address the configuration / binary mismatch
that may occur between /usr and /etc. Each guest clearly has to have its
own /etc and /var so it is entirely possible to have a binary mismatch
with the configuration files that reside in /etc. In addition, having
thought about this further, the package database resides in /var. This
also is unique to each system.
>From reading the red paper on the topic and given this email it almost
sounds like I will have to, basically, re-clone each guest as an upgrade
or patch cluster is made available. This seems like the only way to
ensure your RPM (Package) database, and /etc and binaries are all in sync.
I would have to say I personally would not want to "re-install" or
re-clone each guest as an upgrade or patch is made available. With the
potential of having several 100 guests this seems a bit unrealistic. And
then if you were to re-clone at each upgrade the issue of ensuring that
your configurations, tweaks, filesystems, etc. . . are backed up and
brought into your new upgraded / re-cloned guest seems like a big pain.
The more I think about this the more I believe that DASD is cheap and my
time is not nor is the potential for a serious outage as direct result of
cloning. It may be a good idea for a couple of guests but to have several
100 all doing their own thing with their own configuration (Web Server v.
WebSphere v. Database) just seems like a bad strategy and I can not,
unless I am told that I am wrong, suggest such a configuration to my
management.
And finally, going back to the response below, /usr sharing is not the
issue it is the fact that /usr/sbin and /usr/bin contain the binaries that
depend directly on the configuration files found in /etc and /var both of
which are not shared. Thus to perform an upgrade on the system that is
"the master copy" would only ensure that that master is completely up to
date. The other guests that share the /usr filesystem would not be, there
would be, for example, SLES7 information in /etc and /var while there
would be SLES8 binaries. And to resolve this issue it seems one would,
again as stated above, go through the cloning process again.
Am I wrong here?
Eric Sammons
Arnd Bergmann <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
01/24/2004 12:54 PM
Please respond to Linux on 390 Port
To: [EMAIL PROTECTED]
cc:
Subject: Re: Pros and Cons to sharing /usr
Eric Sammons <[EMAIL PROTECTED]> schrieb am 24.01.2004,
15:27:56:
> Thoughts? Is anyone cloning? Yes, how are you addressing the /etc
> issues?
One possible approach to this problem goes as follows:
- Have one shared ro /usr fs on many guest with the other file systems
cloned from a common source.
- When an update happens, create a replacement /usr by installing the
new .rpm/.deb packages on a guest with an rw mounted copy of the old
/usr.
- On every other guest, do the same with a throwaway copy of the old
shared /usr, then mount the new shared /usr on top of it.
Advantage is that you need only three DASD containing /usr for an
unlimited number of guests and that you can do updates without reboot
(although not necessarily both of these combined - unmounting the
throwaway fs is tricky, unmounting the original ro fs is close to
impossible without service interruption).
Disadvantage is that the effort for an update scales almost linearly
with the number of guests, because it is rather hard to automate (though
surely not impossible).
Arnd <><
