This is the e-mail where Catalin requests sites update cvmfs-keys and
change the VO software directory environment variable.
In the ops meeting Steve noted that at:
https://www.gridpp.ac.uk/wiki/Main_Page there is a link in the section:
Getting up and running on the grid - users
to
RAL non-LHC CVMFS, i.e. the Gridpp Repository
<https://www.gridpp.ac.uk/wiki/RALnonLHCCVMFS>
Which I've just checked - and isn't up to date.
I've filed
https://ggus.eu/index.php?mode=ticket_info&ticket_id=109845
against RAL to request that this be updated - but if someone wants to
beat Catalin to it...
Chris
On 23/10/14 12:00, Catalin Condurache wrote:
> Hi,
>
> You may be aware or not that a new cvmfs-keys-1.5 package has been made available recently. More details at http://cernvm.cern.ch/portal/filesystem/cvmfs-keys-1.5 but mainly it adds the public keys and Stratum-1 server addresses for the egi.eu and opensciencegrid.org domains (no changes for the *.cern.ch repositories).
>
> Now about the new 'egi.eu' CVMFS domain. It is the result of the work done by the EGI CVMFS Task Force and it is going to replace the existing 'gridpp.ac.uk' domain which accommodates the small VO repositories.
> At the moment at Stratum-0 level (RAL), for each repository that exists under /cvmfs/<repo>.gridpp.ac.uk there is a valid copy as /cvmfs/<repo>.egi.eu. And similarly the Stratum-1 services (RAL, NIKHEF, ASCG) are replicating both gridpp.ac.uk and egi.eu domains.
>
> Once cvmfs-keys-1.5 is installed at sites, the 'egi.eu' configuration comes in place without need to remove the old gridpp.ac.uk domain (if already configured), and automatically CVMFS clients can access the /cvmfs/<repo_name>.egi.eu space.
> Hence for a specific VO, the environment variable VO_<vo_name>_SW_DIR could be defined either as "/cvmfs/<repo_name>.gridpp.ac.uk" or "/cvmfs/<repo_name.egi.eu" without impacting VO activities. However the plan is, once cvmfs-keys-1.5 has been installed, to stop using the CVMFS gridpp.ac.uk space by properly redefining the VO_<vo_name>_SW_DIR variables. Problems might appear if VOs rely on accessing their CVMFS repo by hardcoding the path in their applications (and not making use of the environment variable), but I believe this is not the case in general.
>
> Therefore I encourage system administrators at sites to install cvmfs-keys-1.5 rpm (https://cvmrepo.web.cern.ch/cvmrepo/yum/cvmfs/EL/5/x86_64/cvmfs-keys-1.5-1.noarch.rpm), and then to redefine the VO_<vo_name>_SW_DIR variable for the VOs they are supporting on CVMFS.
>
> Please let me know of any problems you come across and I'll be happy to help.
>
> Best regards,
> Catalin Condurache
> RAL Tier-1 Grid Services
>
>
|