safest way to upgrade glibc?

[samengr]

Hi,

I am using RHEL3 and RHEL4 in my production environment. Well, one of application need glibc-2.4 and later to run on it and I need to upgrade glibc-2.3 to glibc-2.4 or above.

Http (apache), vsftp, mysql, php, nfs, and some other 3rd party servers like tomcat are installed/configured on these machines. To be honest I dont have any down time but I will manage some downtime if it would be very necessary.

Can someone guide me the best and safest way to upgrade the glibc?

RHEL3 -------

$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 3 (Taroon Update 9)

$ uname -r
2.4.21-32.ELsmp

$ rpm -qa | grep glibc
glibc-2.3.2-95.50
glibc-headers-2.3.2-95.50
glibc-kernheaders-2.4-8.34.5
glibc-common-2.3.2-95.50
glibc-devel-2.3.2-95.50

RHEL4 ------

# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)

# uname -r
2.6.9-5.ELsmp

# rpm -qa | grep glibc
glibc-common-2.3.4-2.25
glibc-devel-2.3.4-2.25
glibc-2.3.4-2.25
glibc-kernheaders-2.4-9.1.98.EL
glibc-headers-2.3.4-2.25


waiting for any help.

Many thanks.

[druidmatrix]

So you are going to try this out on live production systems without trying out on a staging server first? *shudder*

If you can get a duplicate of your production server (hardware-wise) I'd suggest you take a dd of your production server first - you can just pipe it to ssh and dd it out to a disk on a different box, thus creating a replica of the disk, without bringing the production box down. Then just use this new disk on the secondary hardware - you now have a replica of the production server to try out whatever tests you want.

If you do decide to live dangerously and upgrade the RPM's anyway, I dont see how even in the worst case you would have a problem. At worst you would have to reinstall the apache, and mysql, and vsftpd, etc - your data should not be affected (or conf files) for the applications you mentioned - so you could just rebuild them, right? So in the worst case there would be a few hours downtime?