Centos Continuous Release with caution

Centos Continuous release is very easy to install. Download and install 1 rpm and you are all set.

i386:
http://mirror.centos.org/centos/6/extras/i386/RPMS/centos-release-cr-6-0.el6.centos.i686.rpm
( sha256: 9fc78d2d79abeb1513f0851d075a2860f5039fc8db3fb0db4c660252fffda894 )

x86_64:
http://mirror.centos.org/centos/6/extras/x86_64/RPMS/centos-release-cr-6-0.el6.centos.x86_64.rpm
( sha256: bd55e1505caae2f78c306290d235b7f54833fcad5a9f1942b3cb54e28f7bfe73 )

But I urge caution.

In my lab, I downloaded the 64 bit version and installed it. Then I ran the following command:

yum -y update

A lot of stuff got updated and a major problem was introduced, a bad release of apache was spun out, probably by Red Hat. I don’t know if Centos approves the content before it is released, I’m guessing probably not. I will contact them and let you know.

The problem:

[Sun Nov 06 05:25:27 2011] [notice] child pid 17890 exit signal Segmentation fault (11)

My research traced this back to a problem with the apache application. I needed to back out the httpd/apache release, install the previous release

To even have roll back, you must:

Add tsflags=repackage to /etc/yum.conf.
Add %_repackage_all_erasures 1 to /etc/rpm/macros. If /etc/rpm/macros does not exist, just create it.

You can now install, erase and update packages with yum and/or rpm, and they will save roll back information.

When you want to roll back, use rpm to do so.
You do this by specifying the --rollback switch and a date/time, like the examples below:

rpm -Uhv --rollback '19:00'
rpm -Uhv --rollback '8 hours ago'
rpm -Uhv --rollback 'december 31'
rpm -Uhv --rollback 'yesterday'

I was in a hurry, I merely removed httpd, temporarily disabled the CR repo and installed httpd and the dependencies that were removed at the same time.

To update production and exclude the bad httpd release:

yum -y update –exclude httpd

Done

Turns out this problem was caused by a php plugin eaccellerate which is part of the ISPCONFIG3 setup I use to manage sites. The above technique did allow me to avoid the problem temporarily, and is good practice for when Red Hat does roll out bad rpm updates (which sadly happens all to often).