Last week I upgraded the cvmfs on all the WN to cvmfs-2.0.3. The upgrade for us required two steps.
1) change of repository: since Manchester was the first to use the new atlas setup we were pointing to CERN repository. The new setup has now become standard so I just had to remove the override variable CVMFS_SERVER_URL from atlas.cern.ch.local. The file is distributed by cfengine so I just changed it in cvs.
2) rpms upgrade: I had some initial difficulties because I was following the instructions for atlas T3 - which normally work also for T2 - that suggested to install cvmfs-auto-setup rpm. This rpm runs service cvmfs restartautofs and in the instructions it was suggested also to rerun it manually. This on busy machines causes the repositories to disappear and requires a service cvmfs restartclean which wipes the cache off and is not really recommended in production. In reality none of this is really necessary and a simple
yum -y update cvmfs cvmfs-init-scripts
is sufficient. I could add the rpms version in cfengine and that was enough. The change from one version to another happens at the first unmount. Forcing this with a restartautofs is counterproductive (thanks to Ian for pointing this out).
Next week there should be a bug fix version that will take care of slow mount and some slow client tools routines on busy machines.
http://savannah.cern.ch/bugs/?86349
But since the upgrade procedure is so easy and the corrupted files problem
http://savannah.cern.ch/support/?122564
is fixed in cvmfs >2.0.2 I decided to upgrade anyway on Wednesday to avoid further errors in atlas and possibly lhcb.
NOTE: Of course I tested each step on few nodes to check everything worked before rolling out with cfengine on all nodes. Always a good practice not to follow recipes blindly!
2 comments:
I should say that I deliberately don't run the auto scripts when upgrading cvmfs after looking at what they do.
Another thing people should watch out for, if upgrading from pre-2.0 versions, is that some of the cvmfs environment variables have been made read-only, so if your custom .local files try to set (for example) CVMFS_USER, they will now fail.
(This shouldn't hit many people, however.)
Indeed the auto-setup rpm should be avoided. And I did avoid it when I installed cvmfs few months ago but somehow thought this time it would be harmless. My bad.
With CVMFS_USER they probably want to avoid permission problems.
Post a Comment