[lug] Backing out yum upgrades

[Davide Del Vento]

This is what I am doing too for production machines (actually I am
doing *both* options at the same time):
a1) barebone operating system installation,
a2) from-source installation of multiple versions of mission-critical
packages (possibly compiled with rpath to have the advantage of both
shared and static libraries)
b) using modules to make the switch among different versions easy

By the way we are using
http://www.tacc.utexas.edu/tacc-projects/mclay/lmod which is a "module
on steroids". Another option (if you like the concept but don't like
the module implementation) would be to use dotkit instead
https://computing.llnl.gov/?set=jobs&page=dotkit

As Matt says, this approach requires some additional work, both
upfront and for maintenance (you are back to the ole days when
"security" meant "reading daily the mailing list and recompiling from
source when a security update was announced"). It's up to you to
decide if you have the resources for this additional work (e.g. do you
have a backup person able to do it when you are sick or on vacation?),
and if the "price" of this additional work is right for your case. It
could become really a lot of work if you do it for many many packages,
so you may want to select just the "mission critical" ones, if you
have a small set.

For a desktop system I (personally) would not do this, but rely on the
distribution instead.

Cheers,
Davide

On Wed, Sep 26, 2012 at 9:34 AM, Matt Bidwell <mbidwell at gmail.com> wrote:
> I might suggest two alternative methods, both are a little more work
> up front, but can be switched to previous versions immediately. Both
> require mucking with source.
> Option one: Environment Modules http://modules.sourceforge.net/
> Great when you require multiple versions of the same package. You can
> have certain packages load by default on login, or let users load the
> packages and versions they need.
> Option two: I put a lot of my applications, compiled from source, in
> /opt. Part of this is my paranoia that something like HTTP from
> distros have things compiled into it that I don't want. The other part
> of this is I can go and upgrade the OS without breaking vital
> applications.  The plus to this is I can compile and run a new
> version. For Apache, I'll have a system link for /opt/httpd pointing
> at /opt/httpd-2.4.3. When I have a new version I just point the system
> link to that. If there's some unintended consequence of the new
> version, I just point back to the old. I still put the start script in
> /etc/init.d, but I will usually name it something like
> `companyname`-httpd.  That's all part of being able to upgrade the OS
> without clobbering my applications.
>
> Matt
>
> On Tue, Sep 25, 2012 at 7:02 PM, David L. Anselmi <anselmi at anselmi.us> wrote:
>> Jeffrey S. Haemer wrote:
>>> I'd like to do regular package updates on my CentOS 6.2 boxes.  I'd also
>>> like to be able to back out selected updates if users say, "*Noooo ...*"
>>>
>>> *[root at ba-vm-cie-01]#* yum history undo 36
>>
>> I'm kind of surprised that yum tracks transactions like that and provides an undo (which might even
>> work if you had a repository with the old package).
>>
>> I'm not surprised at all that Kevin knew how to get what you wanted.
>>
>> Dave
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety