[ale] Red Hat upgrades?

[Jeff Hubbs]

On 7/5/11 6:45 PM, James Sumners wrote:
> On Tue, Jul 5, 2011 at 6:12 PM, Michael H. Warfield<mhw at wittsend.com>  wrote:
>> Now mind you, I work with (not for) an IT department for a major
>> international company that have taken that attitude at times that left
>> them sitting on Solaris 8, in some cases, for ages because the upgrades
>> are so painful (switching from Solaris to RHEL was less painful than
>> Solaris 8 to Solaris 10).  RHEL 5 to RHEL 6 takes hours of downtime and
>> adapting.  I did it in my VM's from CentOS 4 to CentOS 5.  You know what
>> the "upgrade" path is?  You provision an entirely new VM and build it
>> and migrate your data.  And it takes hours of work for one machine...
>> Man!  Virtualization makes that work sooo much easier, and yet...  Net
>> time, an upgrade from RHEL 4 to RHEL 5 for a major data center can take
>> weeks and involve a lot of people depending on the number of servers.
>> Slowlaris -- forget it.  Solaris 11 and ZFS has the right idea.  They
>> can do live backup snapshots and upgrades and they can roll forward and
>> backward.  We're not quite there yet.  Getting closer...  I don't say
>> these things because I have not experienced them.  I have been there and
>> done that.  I'm sorry.  I'm just too bloody lazy to work that hard.
>>
>> Now, lets see...  Every six to 12 months upgrading...  Oh, interesting,
>> I can type (cut-n-paste) 6 commands into 30 or 40 windows one right
>> after the other remotely turning them loose in maybe 15 minutes if I'm
>> really slow.  Oh, wow.  I use a package cacher (pkg-cacher) so it only
>> downloads the big stuff once.  Oh wow...  30 servers are done in under
>> an hour (after the first one) and not a single error and the down time
>> for them is less that 5 minutes each?
>>
>> Really?
>>
>> Really.
>>
>> Yes there can be gotcha's, particularly if you are a Postgresql fanatic
>> like I am.  If I do a version upgrade I do need to backup and dump the
>> databases and restore.  Oh well...  You learn and you do and you SCRIPT.
>> Yes, it helps if you keep your servers in coherence and they have the
>> same set of rpms (I try - Fedora is easier there too).  Yes, you
>> sometimes have to resolve some conflicts but then you have this dump of
>> your databases and you can cut-n-paste the uninstalls between all the
>> machines just as fast.  I can do 30 machines using yum and have them all
>> up in running in less than the down time of a RHEL single server upgrade
>> when they go to to a "major upgrade".
>>
>> I can live with that every 6 to 12 months.  And I laugh my ass off at my
>> IT people that complain that the server is going to be down for 12 hours
>> for an upgrade (just because they can not predict what's going to break
>> or how long it will take to fix it)...
>>
>> You guys work too hard and I'm a lazy bastard with better things to do.
>> Fedora works for me.
>>
>>> -L
>> Regards,
>> Mike
> I'm glad someone with a bigger resume than me gets it. All of this "no
> upgrades between major versions means stability" garbage is merely a
> justification for accepting a broken system (in my opinion). Like you,
> I don't enjoy wasting hours of my time rebuilding ONE system and then
> doing the same for the other X number of systems.
>
> I just wish companies that say they "support Linux" didn't really mean
> they "support Red Hat."
I very much agree and I feel similarly about jobs advertised as "Linux 
jobs" actually turning out to be "Red Hat jobs."  I feel like closed 
software that is being "supported" only on X distro or Y distro has bad 
effects on Open Source as a whole.  That's why I'm of the mind that if 
you want to run an ORDBMS on Linux, you'd better have absolutely 
disqualified PostgreSQL, MySQL, or any other Open Source app before 
turning to Oracle, DB2, etc. because the ropes start getting lashed 
around your hands as soon as you do that.
> You mentioned that Fedora has gained the equivalent of `apt-get
> dist-upgrade`. Does it also have the equivalent of `echo "postgresql
> hold" | dpkg --set-selections` [1]? That would certainly help in your
> upgrades when you know a package is going to require extra work.
Gentoo has a mechanism within Portage, its package management system, 
for both getting "ahead" of versions of packages that are marked stable 
and also for limiting any packages' ability to be upgraded.  It's often 
useful, for instance, as a way to nail the extant version of proprietary 
nVidia driver to the floor once you've found one that works with your 
adapter.  I've found that if you're building up a server, it's usually a 
small number of packages and its dependencies that you really care about 
- rest of the machine be damned.  So, on a Gentoo Tomcat server, for 
instance, I can be a stickler for my Tomcat and JDK and let the other 
packages ossify (although I might be careful to keep up with OpenSSH and 
kernel versions, but that area of interest and something like Tomcat/JDK 
generally aren't going to scrape against each other).

Now, at times, there will be step changes in how things get done and 
with what...Portage generally handles that or you'll at least get 
informed how to handle it by the messages that Portage sends you or 
other means.  One package may "block" another and you'll have to handle 
the block by hand (you can usually handle it by unmerging the blocking 
package) but more recently Portage has been able to do that for you in 
the course of emerging something.
> [1] -- http://www.debianadmin.com/how-to-prevent-a-package-from-being-updated-in-debian.html
>
>