Recent Changes - Search:


edit SideBar


On this page... (hide)

  1. 1. gLite
  2. 2. OSG

Updates to the Grid/Cluster systems, particularly the CEs and UIs, must be done carefully.

Please do a snapshot of the VM before doing any non-trivial update. If you don't know how to do it, you should not even try to make an update.

1.  gLite

The gLite systems tend to have package dependency conflict on updates, especially if updates are not done regularly.

In such cases, it's often better to try to do the base updates separately from those of the middleware. One way is to use check-update to generate a full list of packages, filter the slc4 ones, exclude some critical package (the Java RE/SDK being typical cases) and update what remains:

yum check-update > uplist
grep slc4- uplist | cut -d. -f1 | grep -v j2re | xargs yum update

2.  OSG

On the OSG systems, the situation is easier and worse at the same time. Pacman installs alternative software outside of RPM control, including its own versions of Java, Apache etc. So obviously there are no conflicts with the updates of RPM packages of the base systems. On the other side, there is no guarantee that some RPM will not overwrite a file installed by pacman, or that some OSG code will not actually stop working with the updated libraries or kernel...

If you update to a new point release (like from 4.6 to 4.7) you may want to check that pacman -version lists your future platform amongst the same "satisfies" group.

In general, pacman problems are not easy to recover from, so it's important to make a backup of the /opt/osg directory before running pacman -update, like

cd /opt/
rsync -avP osg/ osg.bak/

(be careful with the / or it will create a subdirectory) even if you have done a snapshot: the snapshot is best for disaster recovery, but you completely lose the new changes; the directory backup allows you to check the differences from the previous status.

Edit - History - Print - Recent Changes - Search
Page last modified on April 26, 2009, at 12:08 PM