On Sun, Nov 6, 2011 at 3:56 PM, Yasha Karant <ykar...@csusb.edu> 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.