On 11/06/2011 03:17 PM, Nico Kadel-Garcia wrote:
> On Sun, Nov 6, 2011 at 3:56 PM, Yasha Karant<[log in to unmask]>  wrote:
>> Rather than hijacking the thread on vlc, I am posing this as a new set of
>> questions.
>>
>> My understanding of the EL upgrade process, when moving from EL N to EL N+1
>> (e.g. EL 5.7 to EL 6.1), there are only two ways to protect the information
>> on the hard drives that have "systems" directories (e.g., / , /boot , /usr ,
>> ... ).
>
> Definen "protect data". A complete backup is usually the safest before
> doing *any* such upgrade.
>
>> 1.  Make backups of everything and restore after the EL N+1 installer runs,
>> hopefully forgetting nothing of importance.
>
> Common, especially if you plan to be stripping out unnecessary
> services and configurations. You get a cleaner installation,
> especially of "config" files with RPM updates leave untouched.
>
>> 2.  Keep /home , /opt , /usr/local , and all other non-distribution given
>> applications, configurations, and data, on separate partitions that are not
>> touched during the EL N+1 installation process by using a manual override
>> selection during the EL N+1 installation process.
>
> Yasha, you keep making these strange and incomplete dichotomies. Our
> favorite upstream vendor does a good job of following the File System
> Hierarchy, and keeps system configurations in well-defined locations
> of /usr, *not* /usr/local, and keeping system materials out of /home/
>
> The fun and games occurs when someone's been adding out-of-band
> packages, such as customized Apache layouts /home/httpd, or anything
> written by Dan Bernstein that insists on its own "special" loations in
> /qmail/, /djbdns, or various other inappropriately located base
> directories. (It's an old sorepoint for folks who've maintained such
> packages.) It also occurs when people decide to install multiple local
> versions of core utilities in /usr/local/, such as keeping 4 or 5
> different manually installed Java versions in /usr/local/java.
>
>> 2.1  If these are not real partitions but are handled via the Linux LVM
>> method, will these be respected or will these be overwritten?
>
> Partition membership is irrelevant. It's a filesystem, and if the
> partitions are mounted at installation or update time, they will
> potentially be overwritten or even rebuilt from scratch. And if your
> setup is complex or clever, mistakes become easy. This is why
> separating bulky development areas to separate partitions or disk and
> separate backup strategies are so helpful.
>
>> 2.2  Is there any mechanism to force the EL N+1 installer to ignore certain
>> directory trees that are not real partitions (e.g., do not touch /usr/local
>> if /usr/local actually is on the same partition as /usr -- given that /usr
>> in general must be overwritten to install EL N+1)?
>
> Unmount them, and do not let the update procedures mount or
> re-partition them. Be aware that if the update of software does seek
> to make changes, for example by putting files in /usr/local/ with
> software from a File System Hierarchy violating 3rd party repository,
> and the partitions are not yet mounted, the changes will be concealed
> by the mounting.
>
>> As an aside, when I do this, I keep many things from the EL N installation,
>> including many configuration files in /etc so that these can be quickly
>> reinstalled.  I personally accomplish this by copying these to a
>> subdirectory of a directory for a mount point for a filesystem that will not
>> be touched (e.g., /home/prevsys/etc with /home on, say, /dev/sda10), using
>> cp -pr to save the required permissions.
>
> I do an rsync based backup of /etc and /home to another host, plus any
> relevant config directories from /opt or /usr/local as needed.
>
>> These days, I make certain that each physical partition that will be
>> reformatted/overwritten by the EL N+1 installer is large enough to
>> accommodate the typical growth (bloat?) of the new major release.
>
> Well, yes. This is where it's helpful to simply have a complete backup
> to restore from. In particular, the new SL 6 structure for naming
> logical volumes with the hostname included is very helpful in virtual
> environments, allowing the mounting of partitions on the hypervisor or
> with the disks transferred to a new host to be much simpler and avoid
> conflict with existing logical volume names. But if you're upgrading
> from SL 5.x to SL 6.x, you won't inherit this. You'll need to
> repartition or play serious games to get that kind of feature.
>
> Mind you, it's often much simpler and quite effective to simply use
> the "upgrade" features built into the DVD's or kicstart setups. You'll
> miss out on a few features like the volume naming, but our favorite
> upstream vendor has done a very effective job of preserving
> configurations across upgrades without having to do a complete
> rebuild, by carefully managing config file updates and providing
> update tools for databases.

I have been informed that "update" will not work from EL N to EL N+1 for 
major releases, only for minor sub-releases (EL 6.0 to EL 6.1, etc.). 
Major releases require a full install, as though one were using a 
completely new hardware system.  My personal backup technique these days 
is simply to buy a new disk, clone it from a working one using dd, and 
then if I must install to overwrite, bring up the backup disk on an 
unused disk controller interface connection, and copy (cp -pr, cpio, 
tar, etc.) files and/or hierarchies from the archived backup to the 
production disk.  This is feasible today because of the relatively low 
price of the bare harddrives, and necessary in my case from my 
workstation or laptop because I do not have access to a high throughput 
channel to a disk farm server (e.g., a NAS).  At low throughput, the 
task simply takes too much real time -- what will work for a few Gbytes 
in terms of real time is not feasible for a Tbyte or more.

The sorepoints you mention are unfortunate, but also real, and not only 
for the sort of applications you mention, but also for applications that 
are commercial, without source, and licensed for fee.

Moreover, during the major release upgrades, my understanding is that / 
, /usr, and other systems directories that are the mount points for the 
underlying partitions containing file systems are automatically 
reformatted (erased) or the upgrade will fail.  I believe that I have 
email from Connie Sieh on this very point.

Do I understand you correctly that LVM works the same as physical 
partitions, and that particular logical entities (e.g., the LVM analogue 
of physical partitions) can be exempted during the full install of a new 
major release?