How to access, set up, and test your account¶

Mailing lists and communication with admins and other users¶

cms-tier3-users@lists.psi.ch: list through which we broadcast information (e.g about downtimes). It can also be used for discussions among users (e.g. getting help from other users). You must subscribe to this list using its web interface (list archives).
cms-tier3@lists.psi.ch: Use this list to reach the Tier-3 admins, typically if you have a problem and you need help. What you write to this list is only seen by the administrators

Both lists are read by the administrators and are archived.

Test access to the T3 User Interfaces (UI)¶

User Interface servers ( UIs ) are available as login nodes for the Tier-3 cluster. You can test your programs there, submit batch jobs and do some interactive work. But production runs that inflict a heavy load on the system are not permitted, since they willl impact the work of other users. Please run such jobs in the batch queues (one can also run interactively in an allocated batch slot).

Use ssh to connect to the bastion host (you must have set up MFA authentication as lined out here). Leave the bastion host session open to allow other ssh connections into the Tier-3 using the bastion as a jump host.
Use ssh in a separate session to log in to a UI node (all named following a t3ui* pattern). You can use -Y or -X flags if you want to work with graphical X applications, but be aware that simple X redirection is slow if you're connecting from outside of PSI. (When we write ${USER} in this documentation, you should substitute it by your Tier-3 username).

ssh -Y ${USER}@t3ui06.psi.ch

Check that you have write access to the SE's area for your user, by just creating and deleting a test file in your user area

touch /pnfs/psi.ch/cms/trivcat/store/user/${USER}/my-first-test
rm /pnfs/psi.ch/cms/trivcat/store/user/${USER}/my-first-test

Check that you have write access to your /work area

touch /work/${USER}/my-first-test
rm /work/${USER}/my-first-test

Test whether you can set up a CMS environment by sourcing the default settings from the standard location.

source ${VO_CMS_SW_DIR}/cmsset_default.sh

Test access to the SE (Storage Element)¶

The following tests only apply if you own a Grid certificate for authentication on the LHC Grid, and if you registered that certificate with us in your account application. Also, you should register in the chcms VOMS group (see section below) in order to get access to certain services of the Swiss Tier-2 center (see below).

In order to work with resources on the WLCG grid you need to have a grid x509 certificate and a matching private key. Copy these credentials to the standard locations of ~/.globus/userkey.pem and ~/.globus/usercert.pem on one of the T3 user interface (UI) hosts and make sure that their permissions are properly set. The user key must NEVER be readable by any other user!
```
chmod 600 userkey.pem
chmod 644 usercert.pem
```
For details about how to extract those .pem files from your CERN User Grid-Certificate (usually a password protected .p12 file ) please follow https://twiki.cern.ch/twiki/bin/view/CMSPublic/PersonalCertificate.
Make sure that your credentials are registered with the CMS Virtual Organization see CERN wiki for instructions. Otherwise you will not get access rights to CMS storage paths.
Create your short term credentials in the form of a proxy certificate with CMS extensions listing your membership in the chcms (Swiss CMS) group, valid for 168 hours:
```
voms-proxy-init -voms cms:/cms/chcms --valid 168:00
```
If you are not yet a member of the chcms organisation, you can do a simple
```
voms-proxy-init -voms cms --valid 168:00
```
but your proxy cert will not contain the information necessary to work with the Swiss Tier-2 at CSCS, If the command fails you can run it again adding a -debug flag to troubleshoot the problem.

Test your access to the PSI Storage element using our t3test-dCacheProtocols testing suite. By default it tests access to the /store/temp/user area where all CMS users are allowed to write

[feichtinger@t3ui05 ~]$ t3test-dCacheProtocols
Running tests for site PSI and directory /store/temp/user
TEST: NFS4-write ......  [OK]
TEST: NFS4-rm ......  [OK]
TEST: davs-ls ......  [OK]
TEST: davs-write ......  [OK]
TEST: davs-rm ......  [OK]
TEST: XROOTD-LAN-write ......  [OK]
TEST: XROOTD-LAN-stat ......  [OK]
TEST: XROOTD-LAN-read ......  [OK]
TEST: XROOTD-LAN-rm ......  [OK]
TEST: XROOTD-WAN-write ......  [OK]
TEST: XROOTD-WAN-read ......  [OK]
TEST: XROOTD-FED-read ......  [OK]
TEST: XROOTD-WAN-rm ......  [OK]
TEST: GFTP-write ......  [OK]
TEST: GFTP-ls ......  [OK]
TEST: GFTP-read ......  [OK]
TEST: DCAP-read ......  [OK]
TEST: SRMv2-write ......  [OK]
TEST: SRMv2-ls ......  [OK]
TEST: SRMv2-read ......  [OK]
TEST: SRMv2-rm ......  [OK]

If a test fails, an error message will be written to the screen, and it will point you to a file containing the details of the error. Please send this together with all the information to cms-tier3@lists.psi.ch.

Tip

You can use the -v (verbose) flag to see the command line commands that the script executes. This is a good way to learn about the slightly esoteric syntax for interacting with grid storage. If you supply a -d flag as well, the tests will not be run, but you will be able to look at all the commands that the script would execute.

Test write access to your user area on the storage element. Your user area is located below /pnfs/psi.ch/cms/trivcat/store/user/${CERN-USER}. If your Tier-3 username is the same as the CERN username, then you can run the command just like in the following using the --home flag. If your CERN username differs, you have to use -l /store/user/${CERN-USER}.

[feichtinger@t3ui05 ~]$ t3test-dCacheProtocols --home
Running tests for site PSI and directory /store/user/feichtinger
TEST: NFS4-write ......  [OK]
TEST: NFS4-rm ......  [OK]
TEST: davs-ls ......  [OK]
TEST: davs-write ......  [OK]
TEST: davs-rm ......  [OK]
TEST: XROOTD-LAN-write ......  [OK]
TEST: XROOTD-LAN-stat ......  [OK]
TEST: XROOTD-LAN-read ......  [OK]
TEST: XROOTD-LAN-rm ......  [OK]
TEST: XROOTD-WAN-write ......  [OK]
TEST: XROOTD-WAN-read ......  [OK]
TEST: XROOTD-FED-read ......  [OK]
TEST: XROOTD-WAN-rm ......  [OK]
TEST: GFTP-write ......  [OK]
TEST: GFTP-ls ......  [OK]
TEST: GFTP-read ......  [OK]
TEST: DCAP-read ......  [OK]
TEST: SRMv2-write ......  [OK]
TEST: SRMv2-ls ......  [OK]
TEST: SRMv2-read ......  [OK]
TEST: SRMv2-rm ......  [OK]

We advise that you read the following page: Understanding Tier-3 storage

Applying for the Swiss CMS VOMS Group `/cms/chcms`¶

VOMS, the Virtual Organisation Managent System, is used to manage authorization to CMS services. It uses the concept of groups and roles. You need a grid certificate in order to apply for a VOMS group membership.

We manage the Swiss VOMS Group /cms/chcms. If you run with the added credentials from this membership, you get write access to certain areas of our national Tier-2 T2_CH_CSCS

write access to directories under /store/user and /store/group. This area is reserved for associated users. All others need to place files in /store/temp/user where they get cleaned regularly.
currently not active, but we can activate in need
- higher priority on the T2_CH_CSCS batch queues
- additional Jobs slots on the T2_CH_CSCS batch queues

To request membership in our VOMS group

visit the CMS authorization service site: https://cms-auth.cern.ch/login,
- You must have your grid certificate loaded in your browser, otherwise VOMS cannot recognize you!
If you do not see /cms/chcms in your groups, you can request membership in /cms/chcms on that page.

Creating a valid proxy certificate with the correct chcms attributes¶

Once you get the confirmation for your chcms membership, you can progress to creating chcms proxy certificates. In order to get correctly mapped to a Swiss user account at our Tier-2, you need to create your proxy certificate using a -voms flag similar to this

voms-proxy-init -voms cms:/cms/chcms

You can confirm your VOMS attributes by running

[feichtinger@t3ui05 ~]$ voms-proxy-info -all
subject   : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=dfeich/CN=613756/CN=Derek Feichtinger/CN=1404297260
issuer    : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=dfeich/CN=613756/CN=Derek Feichtinger
identity  : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=dfeich/CN=613756/CN=Derek Feichtinger
type      : RFC3820 compliant impersonation proxy
strength  : 2048
path      : /t3home/feichtinger/.x509up_u3896
timeleft  : 191:59:42
key usage : Digital Signature, Key Encipherment
=== VO cms extension information ===
VO        : cms
subject   : /DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=dfeich/CN=613756/CN=Derek Feichtinger
issuer    : /DC=ch/DC=cern/OU=computers/CN=cms-auth.web.cern.ch
attribute : /cms/chcms/Role=NULL/Capability=NULL   # <== CHCMS group attribute
attribute : /cms/Role=NULL/Capability=NULL # <== generic CMS VO attribute 
timeleft  : 24:59:41
uri       : voms-cms-auth.app.cern.ch:15000

Make sure that the chcms attribute /cms/chcms/Role=NULL/Capability=NULL appears before the attribute for the standard CMS membership /cms/Role=NULL/Capability=NULL in that listing!

Your chcms prioritzed proxy certificate will be accepted as a normal CMS proxy certificate when accessing other sites (since it also includes the normal /cms group).

Note that it is possible to ask for multiple attributes and roles with a single voms-proxy-init command! The order of resulting attributes will reflect the order you gave on the command line, and our grid site will map you with the first attribute that matches on of our rules. So, e.g. if you had created your proxy by

voms-proxy-init -voms cms:/cms -voms cms:/cms/chcms

then the mapping to a normal CMS user without special rights would take precedence.

Testing write access to T2_CH_CSCS as a Swiss user¶

Having created your grid proxy with the correct chcms attribute, as described above, execute the following line from one of our Tier-3 login nodes. ${USER} should be your CMS name (usually the CERN login name also used on lxplus)!

gfal-copy -f file:///t3home/T3-INFO/USER-SPACE-ACCOUNTING \\
    root://storage01.lcg.cscs.ch:1096/pnfs/lcg.cscs.ch/cms/trivcat/store/chcms-user-test/test-chcms-${USER}

If the write to this test area succeeds, you then are also fine to write to the /store/user/${YOUR-USER} area of the Tier-2.

If you get a permission denied error, try to test whether you are allowed to write to the space open to all CMS users for writing temporary files: /store/temp/user

gfal-copy -f file:///t3home/T3-INFO/USER-SPACE-ACCOUNTING \
        root://storage01.lcg.cscs.ch:1096/pnfs/lcg.cscs.ch/cms/trivcat/store/temp/user/test-chcms-${USER}

If only this latter test succeeds, it means you are only getting mapped to a normal CMS user. There is still a problem with your chcms membership, and the way you created your proxy certificate. Please contact us on the admin mailing list.

Optional Initial Setups (partially obsolete)¶

Installing the CERN CA files into your Web Browser¶

In dealing with grid sites, or for having your own certificate accepted inside of your browser, you may need to add the CERN CA (certificate agency) records to the default ones present in your browser. You can obtain them from CERN CA file.