How to access, set up, and test your account
Preliminary steps
All the documentation is maintained in the T3 twiki pages:
https://wiki.chipp.ch/twiki/bin/view/CmsTier3/WebHome . Please take a look at it to explore T3's capabilities.
Information about T3 mailing-lists:
- Subscribe to the cms-tier3-users list using this web interface (list archives):
cms-tier3-users@lists.psi.ch
. This mailing-list is used to communicate information on Tier-3 matters (downtimes, outages, news, etc.) or for discussions among users and admins.
- To privately contact the CMS Tier-3 administrators, write to:
cms-tier3@lists.psi.ch
- NOTE: Both lists are read by the administrators and are archived. You can submit support requests to either of them. Mails to the user list have the added advantage that they can be read by everyone.
Please also take a look at our policies about usages, quotas, etc..
Tier3Policies.
T3 Linux Groups
All the T3 users are partitioned in several primary groups and the users also belong to the secondary group
cms that's used for common files like the CMS files uploaded at T3 by
PhEDEx:
ETHZ |
UniZ |
PSI |
ethz-bphys |
uniz-pixel |
psi-pixel |
ethz-ecal |
uniz-higgs |
psi-bphys |
ethz-ewk |
uniz-bphys |
|
ethz-higgs |
|
|
ethz-susy |
|
|
The T3 Linux Groups:
- allow a faster and simpler understanding of the
/pnfs
space usage by leveraging on the gid
setting.
- allow to make accounting in the Sun Grid Engine batch system also according to the
gid
setting.
- made possible the creation of the "group dirs"
/pnfs/psi.ch/cms/trivcat/store/t3groups/
where just the group members can write or delete.
- simplify the
/shome
, /pnfs
, /scratch
and /tmp
space usage accounting.
Following an ETHZ user with his
primary and his
secondary group:
$ id auser
uid=571(auser) gid=532(ethz-higgs) groups=532(ethz-higgs),500(cms)
Following the users dirs
/pnfs/psi.ch/cms/trivcat/store/user/
:
$ ls -l /pnfs/psi.ch/cms/trivcat/store/user | grep -v cms
total 56
drwxr-xr-x 2 alschmid uniz-bphys 512 Feb 21 2013 alschmid
drwxr-xr-x 5 amarini ethz-ewk 512 Nov 7 15:37 amarini
drwxr-xr-x 2 arizzi ethz-bphys 512 Sep 16 17:49 arizzi
drwxr-xr-x 5 bean psi-bphys 512 Aug 24 2010 bean
drwxr-xr-x 5 bianchi ethz-higgs 512 Sep 9 09:40 bianchi
drwxr-xr-x 98 buchmann ethz-susy 512 Nov 5 20:36 buchmann
...
Following the "group dirs"
/pnfs/psi.ch/cms/trivcat/store/t3groups/
; since they're "group dirs" there is not a real owner so they belong to the
root
user and the group has the
w
permission:
$ ls -l /pnfs/psi.ch/cms/trivcat/store/t3groups/
total 5
drwxrwxr-x 2 root ethz-bphys 512 Nov 8 15:18 ethz-bphys
drwxrwxr-x 2 root ethz-ecal 512 Nov 8 15:18 ethz-ecal
drwxrwxr-x 2 root ethz-ewk 512 Nov 8 15:18 ethz-ewk
drwxrwxr-x 2 root ethz-higgs 512 Nov 8 15:18 ethz-higgs
drwxrwxr-x 2 root ethz-susy 512 Nov 8 15:18 ethz-susy
drwxrwxr-x 2 root psi-bphys 512 Nov 8 15:18 psi-bphys
drwxrwxr-x 2 root psi-pixel 512 Nov 8 15:18 psi-pixel
drwxrwxr-x 2 root uniz-bphys 512 Nov 8 15:18 uniz-bphys
drwxrwxr-x 2 root uniz-higgs 512 Nov 8 15:18 uniz-higgs
drwxrwxr-x 2 root uniz-pixel 512 Nov 8 15:18 uniz-pixel
Basic setup
We offer the following SL6 user interfaces ( UIs ) and SL5 UIs ( legacy ) assigned according to the following rules; possibly avoid the SL5 UIs because they're going to be decommissioned during 2015 and anyhow there are not anymore SL5 worker nodes ( WNs ) in the Sun Grid Engine batch system, only SL6 WNs ; the SL5 UIs aren't exposed on Internet so to reach them you'll have to connect to a SL6 UI first and then to the SL5 UI ( e.g. Internet --> ssh --> SL6 t3ui12 --> ssh --> SL5 t3ui02 )
Access to Login nodes is based on the institution
The access is not restricted to allow for some freedom, but you are requested to use the UI dedicated to your institution.
UI Login node |
for institution |
HW specs |
t3ui01.psi.ch |
ETHZ, PSI |
132GB RAM , 72 CPUs core (HT), 5TB /scratch |
t3ui02.psi.ch |
All |
132GB RAM , 72 CPUs core (HT), 5TB /scratch |
t3ui03.psi.ch |
UNIZ |
132GB RAM , 72 CPUs core (HT), 5TB /scratch |
- Login into a
t3ui1*
machine by ssh
; use -Y
or -X
flag for working with X applications; you might also try to connect by NX client, which allows to work efficiently with graphical applications
ssh -Y username@t3ui12.psi.ch
- If you are an external user and you don't have a standard PSI account, you'll have to change your initial password the first time you log in; use the standard
passwd
utility.
- Copy your grid credentials to the standard places, i.e. to
~/.globus/userkey.pem
and ~/.globus/usercert.pem
and make sure that their files permissions are set correctly:
-rw-r--r-- 1 feichtinger cms 2961 Mar 17 2008 usercert.pem
-r-------- 1 feichtinger cms 1917 Mar 17 2008 userkey.pem
For details about how to extract those files from your CERN User Grid-Certificate please read https://gridca.cern.ch/gridca/Help/?kbid=024010.
- source the grid environment associated to your login shell:
source /swshare/psit3/etc/profile.d/cms_ui_env.sh # for bash
source /swshare/psit3/etc/profile.d/cms_ui_env.csh # for tcsh
- You have to complete the CMS "Virtual Organization" subscription or the following command
voms-proxy-init -voms cms
won't work. CERN details about that, e.g. who is your representative.
- Create a proxy certificate for CMS by:
voms-proxy-init -voms cms
If that fails, run the command with an additional -debug
flag, and the error message will usually be sufficient for the T3 Admins to point out the problem.
- Test your access to the PSI Storage element with the
test-dCacheProtocols
command. You should see an output like this (without any failed test):
$ test-dCacheProtocols
Test directory: /tmp/dcachetest-20150115-1328-23031
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]
- Be aware of the external CSCS CMS User Page
- The
test-dCacheProtocols
tool can also be used to test a remote storage element (use the -h
flag to get more info about it): e.g. to test the CSCS storage element:
$ test-dCacheProtocols -n storage01.lcg.cscs.ch -p /pnfs/lcg.cscs.ch/cms/trivcat/store/user/YOUR_CMS_ACCOUNT -i "DCAP-read"
Test directory: /tmp/dcachetest-20150115-1333-23178
TEST: GFTP-write ...... [OK]
TEST: GFTP-ls ...... [OK]
TEST: GFTP-read ...... [OK]
TEST: DCAP-read ...... [IGNORE]
TEST: SRMv2-write ...... [OK]
TEST: SRMv2-ls ...... [OK]
TEST: SRMv2-read ...... [OK]
TEST: SRMv2-rm ...... [OK]
Changing your account details
It's possible to get changed your login shell, e.g. from
bash
to
tcsh
, your group, also your account name ; often users requested to change their
Grid cert subject:
, e.g. because they were moving from a country to an other where they got a new certificate.
AFS CERN Ticket
You should use the following sequence of commands at T3:
kinit ${Your_CERN_Username}@CERN.CH
aklog cern.ch
The first command gets you a kerberos ticket, the second command uses that ticket to obtain an authentication token from CERN's AFS service
t3ui1* SSH pub keys
Hackers on Internet are constantly waiting for a user mistake, even just a misspelled
letter like in this example:
$ ssh t3ui02.psi.sh
The authenticity of host 't3ui02.psi.sh (62.210.217.195)' can't be established.
RSA key fingerprint is c0:c5:af:36:4b:2d:1f:88:0d:f3:9c:08:cc:87:df:42.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 't3ui02.psi.sh,62.210.217.195' (RSA) to the list of known hosts.
at3user@t3ui02.psi.sh's password:
The T3 Admins can't prevent a T3 user from confusing .ch
with a .sh
so pay attention to these cases ! you might define these aliases instead :
More... Close
$ grep alias ~/.bash_profile | grep t3ui
alias ui12='ssh -X at3user@t3ui12.psi.ch'
alias ui15='ssh -X at3user@t3ui15.psi.ch'
alias ui16='ssh -X at3user@t3ui16.psi.ch'
alias ui17='ssh -X at3user@t3ui17.psi.ch'
alias ui18='ssh -X at3user@t3ui18.psi.ch'
alias ui19='ssh -X at3user@t3ui19.psi.ch'
More subdole attacks are the
SSH man in the middle attacks ; to detect them you have to register in
/$HOME/.ssh/known_hosts
each
t3ui1*
SSH RSA public key by running these steps on each laptop/desktop/server ( also
lxplus
! ) that you're going use to login at T3:
cp -p /$HOME/.ssh/known_hosts /$HOME/.ssh/known_hosts.`date +"%d-%m-%Y"`
mkdir /tmp/t3ssh/
for X in 19 18 17 16 15 12 ; do TMPFILE=`mktemp /tmp/t3ssh/XXXXXX` && ssh-keyscan -t rsa t3ui$X.psi.ch,t3ui$X,`host t3ui$X.psi.ch| awk '{ print $4}'` | cat - /$HOME/.ssh/known_hosts | grep -v 'psi\.sh' > $TMPFILE && mv $TMPFILE /$HOME/.ssh/known_hosts ; done
rm -rf /tmp/t3ssh
for X in 12 15 16 17 18 19 ; do echo -n "# entries for t3ui$X = " ; grep -c t3ui$X /$HOME/.ssh/known_hosts ; grep -Hn --color t3ui$X /$HOME/.ssh/known_hosts ; echo ; done
echo done
last
for
reports if there are duplicated rows in
/$HOME/.ssh/known_hosts
for a
t3ui1*
server ; if there are you're suppose to preserve the correct occurrence and delete the others ; to delete you can use
sed -i
or by hands by
vim
or
emacs
; once you'll get just one row per
t3ui1*
server run this command and carefully compare your output with this output:
More... Close
$ ssh-keygen -l -f /$HOME/.ssh/known_hosts | grep t3ui
2048 |
d0:9c:a0:e9:8f:9c:3f:b2:f1:88:6c:15:32:07:fc:a0 |
t3ui12.psi.ch,t3ui12,192.33.123.132 (RSA) |
2048 |
77:1b:27:5e:c8:74:64:86:f8:50:f6:58:e6:6f:41:65 |
t3ui15.psi.ch,t3ui15,192.33.123.135 (RSA) |
2048 |
35:bb:d6:be:64:86:8d:db:1d:57:43:ef:05:39:72:c8 |
t3ui16.psi.ch,t3ui16,192.33.123.136 (RSA) |
2048 |
27:d1:57:f0:ac:da:1d:db:54:11:5c:46:4d:93:63:59 |
t3ui17.psi.ch,t3ui17,192.33.123.137 (RSA) |
2048 |
b1:56:06:5b:d3:da:1a:79:60:e9:02:16:be:82:fe:f7 |
t3ui18.psi.ch,t3ui18,192.33.123.138 (RSA) |
2048 |
73:fe:97:b2:e7:54:df:99:50:dc:19:3d:6f:cd:01:11 |
t3ui19.psi.ch,t3ui19,192.33.123.139 (RSA) |
force your ssh client to always check if the server you're connecting to is already mentioned in the
/$HOME/.ssh/known_hosts
file and to request your consensus for servers that are absent by adding this line in
/$HOME/.ssh/config
:
StrictHostKeychecking ask
your
/$HOME/.ssh/config
can be more complex than just that line, study the
ssh_config man page or contact the T3 Admins; ideally you should put
StrictHostKeychecking yes
but in real life that's impractical.
now your ssh client will be able to detect the
SSH man in the middle attacks and if so it will report :
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The
t3ui1*
SSH RSA public and private keys will be
never changed, so the case
It is also possible that the RSA host key has just been changed
will be
never true.