CentOS - Jul 2013 - problems with apache downgrade

There was an upgrade on a couple of our servers yesterday, mid-afternoon
our time, of httpd and httpd-devel, and suddenly SiteMinder (bleah)
stopped working correctly, and is now pegging a cpu, according to top. So,
as a last resort, I tried downgrading both of them. When I did so, the
server that uses ssl *erased* mod-ssl, not downgrading it, and I'll have
to find where I can get the previous version tomorrow... but that
shouldn't happen, I should think. Downgrade *should* get everything,
unless it's brand new, and this isn't.

       mark

On Thu, 11 Jul 2013 17:56:52 -0400
m.roth at 5-cent.us wrote:
> There was an upgrade on a couple of our servers yesterday,
> mid-afternoon our time, of httpd and httpd-devel, and suddenly
> SiteMinder (bleah) stopped working correctly, and is now pegging a
> cpu, according to top. So, as a last resort, I tried downgrading both
> of them. When I did so, the server that uses ssl *erased* mod-ssl,
> not downgrading it, and I'll have to find where I can get the
> previous version tomorrow... but that shouldn't happen, I should
> think. Downgrade *should* get everything, unless it's brand new, and
> this isn't.
> 
>        mark
> 
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
Hmm. 

If you are refering to the standard ones in C6 you should be able to
just yum-downgrade it.

A quick test on my desktop:
[root at main-linux-box ~]# yum downgrade *mod_ssl*
Loaded plugins: changelog, downloadonly, fastestmirror, priorities,
security, : verify
Setting up Downgrade Process
Loading mirror speeds from cached hostfile
 * base: mirror.bytemark.co.uk
 * clnrepo: 192.168.1.74
 * clnrepo-extras: 192.168.1.74
 * clnrepo-extras-noarch: 192.168.1.74
 * clnrepo-noarch: 192.168.1.74
 * elrepo: mirror.solvention.de
 * elrepo-kernel: mirror.solvention.de
 * epel: www.mirrorservice.org
 * extras: mirror.ox.ac.uk
 * fasttrack: mirror.ox.ac.uk
 * nux-dextop: mirror.li.nux.ro
 * updates: mirror.ox.ac.uk
89 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package mod_ssl.x86_64 1:2.2.15-26.el6.centos will be a downgrade
--> Processing Dependency: httpd = 2.2.15-26.el6.centos for package:
1:mod_ssl-2.2.15-26.el6.centos.x86_64 ---> Package mod_ssl.x86_64
1:2.2.15-28.el6.centos will be erased --> Finished Dependency Resolution
Error: Package: 1:mod_ssl-2.2.15-26.el6.centos.x86_64 (base)
           Requires: httpd = 2.2.15-26.el6.centos
           Installed: httpd-2.2.15-28.el6.centos.x86_64 (@updates)
               httpd = 2.2.15-28.el6.centos
           Available: httpd-2.2.15-26.el6.centos.x86_64 (base)
               httpd = 2.2.15-26.el6.centos
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Ignoring the Dep errors, it seems to be all there :-).

You can get v2.2.15-28 (current) here:
http://mirror.ovh.net/ftp.centos.org/6.4/updates/x86_64/Packages/mod_ssl-2.2.15-28.el6.centos.x86_64.rpm

and v2.2.15-26 (previous) here:
http://mirror.ovh.net/ftp.centos.org/6.4/os/x86_64/Packages/mod_ssl-2.2.15-26.el6.centos.x86_64.rpm

Hope this helps :-).

-- 
Jake Shipton (JakeMS)
GPG Key: 0xE3C31D8F
GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20130711/5d394c7e/attachment-0002.sig>

On 7/11/13 4:56 PM, m.roth at 5-cent.us wrote:
> There was an upgrade on a couple of our servers yesterday, mid-afternoon
> our time, of httpd and httpd-devel, and suddenly SiteMinder (bleah)
> stopped working correctly, and is now pegging a cpu, according to top. So,
> as a last resort, I tried downgrading both of them. When I did so, the
> server that uses ssl *erased* mod-ssl, not downgrading it, and I'll
have
> to find where I can get the previous version tomorrow... but that
> shouldn't happen, I should think. Downgrade *should* get everything,
> unless it's brand new, and this isn't.
In a previous life we had to use SiteMinder as well. It pegs top because
it's trying to dump a log file but it doesn't deal with the permissions
properly. If I recall correctly it tries to dump to /var/log/httpd, but
as the apache user, not as root. Once the apache user has access to
write the log to where it's configured, it'll spool out the memory
it's
using and the load will drop after a while.