Software Access

From the Login Node

Just like LXPLUS CERN machines (CERN Public Login Linux system) , the CMS Connect login node machine (login.uscms.org) environment has access to CVMFS (CERN-VM File System), which holds the CMS Software Releases. The default unix shell in the system is BASH.  If you are not familiar with using Linux, see this list of basic Linux Commands.

 

Here is an example of how to access a certain release of the framework via CVMFS:

$ export SCRAM_ARCH=slc6_amd64_gcc491
$ cmsrel CMSSW_7_4_15
$ cd CMSSW_7_4_15/src
$ cmsenv

Please, refer to this Twiki link for a list of all CMSSW Releases available via CVMFS.

From the Worker Nodes

It is important to nice that the User Home Area and Environment is not inherited from the login node machine to each worker node (the actual machines where jobs will run). Tier-2 and Tier-3 resources do have access to CVMFS though. So, while submitting a job that requires the CMSSW framework, you will need to source the CMS source script first.

 

Here is an example of how to setup your CMSSW framework on your job environment, considering your worker node has CVMFS access:

In bash, sh:
#! /bin/bash

#First, setup the CMS environment 
source /cvmfs/cms.cern.ch/cmsset_default.sh

#Then, get a release
export SCRAM_ARCH="slc6_amd64_gcc491"
CMS_VERSION="CMSSW_7_4_15"
scramv1 project CMSSW ${CMS_VERSION}
cd ${CMS_VERSION}
eval `scram runtime -sh`

Creating and unpacking a Sandbox

If you need to add packages to your local CMSSW and don’t want every worker node to pull data and build every time, you can create a sandbox and unpack it on the worker node. 

To create the sandbox, simply pack it with tar

In bash, sh:
$ tar -jcf sandbox.tar.bz2 CMSSW_7_4_15

To use it, you might want to create a new release though, to be sure CMSSW_BASE and other variables are not hardcoded in the configuration setting paths. Here is an example: 

In bash, sh:
#########################
#Setup CMSSW framework
#########################

#Extract sandbox
tar xjf sandbox.tar.bz

#Keep track of release sandbox version 
basedir=$PWD
rel=$(echo CMSSW_*)
arch=$(ls $rel/.SCRAM/|grep slc) || echo "Failed to determine SL release!"
old_release_top=$(awk -F= '/RELEASETOP/ {print $2}' $rel/.SCRAM/slc*/Environment) || echo "Failed to determine old releasetop!"

# Creating new release
# This is done so e.g CMSSW_BASE and other variables are not hardcoded to the sandbox setting paths
# which will not exist here

echo ">>> creating new release $rel"
mkdir tmp
cd tmp
scramv1 project -f CMSSW $rel
new_release_top=$(awk -F= '/RELEASETOP/ {print $2}' $rel/.SCRAM/slc*/Environment)
cd $rel
echo ">>> preparing sandbox release $rel"

for i in bin cfipython config lib module python src; do
    rm -rf "$i"
    mv "$basedir/$rel/$i" .
done


echo ">>> fixing python paths"
for f in $(find -iname __init__.py); do
    sed -i -e "s@$old_release_top@$new_release_top@" "$f"
done

eval $(scramv1 runtime -sh) || echo "The command 'cmsenv' failed!"
cd "$basedir"
echo "[$(date '+%F %T')] wrapper ready"