With CentOS 5.3 due out shortly, many users will be performing the update. For those without physical access to their servers, updates are something that must be performed remotely, normally over an ssh login. However, for an update as large as a point release, where upwards of a couple hundred packages may need updating, this presents some potential dangers. What if your ssh session fails mid update? The exact answer to this will depend at which point in the update process the session failed, but the general gist is that you'll most likely end up with a pretty broken system that needs some major repair work to complete the update.
So here's some tips to ease the potential pain:
- Read the release notes before updating
- Use a screen session so you can reattach the session if a remote ssh login should fail
- Split the update into smaller chunks to minimize damage (and repair time) should anything unforeseen go wrong
First up, read the release notes. There are a few highlighted gotchas that may or may not apply to you.
If you're updating remotely, perform the update from within a screen session so that if the remote ssh session fails you can log back in and reattach the session without losing anything. For those not familiar with screen, simply start 'screen' after logging in, su to root and 'yum update' as normal. Should the ssh connection fail, just log back in again and reattach the screen session with 'screen -d -r'.
[phil@Quad ~]# ssh host.example.com
[phil ~]# screen
[phil ~]# su -
password:
[root ~]# yum update
#### connection lost! ####
[phil@Quad ~]# ssh host.example.com
[phil ~]# screen -r -d
#### phew - she's still alive ####
[root ~]# exit
[phil ~]# exit
If you read the release notes in the first part, you will have noticed an issue with glibc that requires this package to be updated first. The release notes suggest:
[root@Quad ~]# yum update glibc
[root@Quad ~]# yum update
However, you can take this concept a stage further and split updates into smaller chunks thus minimizing the potential for damage (and repair time) should anything unforeseen go wrong. For example, we may like to split updates into logical groups such as the kernel, package management components, compiler tools, etc. How you split your updates will depend on what you have installed, but it may look something like this:
[root@Quad ~]# yum update glibc
[root@Quad ~]# yum update kernel\*
[root@Quad ~]# yum update yum\* rpm\* python\*
[root@Quad ~]# yum update gcc\* make\* automake\*
[root@Quad ~]# yum update open\*
[root@Quad ~]# yum update xorg\* gnome\* kde\* arts\*
[root@Quad ~]# yum update lib\*
[root@Quad ~]# yum update
and finally finishing with a 'yum update' to pull in the remaining updates.