Access

Hartree Centre Logo

Back to Contents Page

Accessing the Systems

Last modified: 27/6/2018

The names of the login nodes are shown below, and these should be used unless otherwise advised.

Resource Namelogin viaLogin NodeIP
AceArm 64-bit clusterlogin.ace.hartree.stfc.ac.uk193.62.123.234
Calcott (Iden and Napier)login node Phase-2phase2.wonder.hartree.stfc.ac.uk193.62.123.11 to 14
DawsonBig Data cluster  
DeLoreanMaxeler Data Flow Enginefpga.eecr.hartree.stfc.ac.uk193.62.123.17
Fairthorpe (Panther and Paragon)P8 clusterhcplogin[1-2].hartree.stfc.ac.uk193.62.123.227
JADEJoint Academic Date Science Endeavorjade.hartree.stfc.ac.uk193.62.124.26 or 193.62.124.27
NealeNovel Cooling Demonstratorlogin.neale.hartree.stfc.ac.uk193.62.123.16
Scafell PikeAtos Sequana systemhcxlogin.hartree.stfc.ac.uk or hcxlogin[1-8].hartree.stfc.ac.uk193.62.122.6[1-8]
Viceroylogin node 9gfxlogin9.wonder.hartree.stfc.ac.uk193.62.123.9
Viceroylogin node 10gfxlogin10.wonder.hartree.stfc.ac.uk193.62.123.10

You will have been allocated a user id for the project you are working on, and the login procedure is described below. It is the same for all the Hartree production systems.

Quick Links

Command line (shell)

Primary access to the HPC resources is provided via SSH running in a command line shell run on a front end node. Most POSIX like operating systems (including Mac OS X) provide command line ssh clients. A popular implementation for the Windows operating system is PuTTY.

Please note that we do not now require a SSH Public Key as a form of authentication (see below for details) but if you do not add one a password will be required to log on. However, using SSH Keys is a more secure and easier way to log on.

Passwords

The system will issue a temporary password which has to be changed on first login. To view your password, log on to SAFE and click the "View" button under "Your User Accounts". Click "View Password" and enter your web (SAFE login) password then click on "View".

SSH keys

To be absolutely clear - the purpose of these keys is for authentication purposes only and serves to confirm that you really are who you say you are when you login. SSH itself then goes on to encrypt the data flowing over the connection which then gets established, but this has nothing to do with the SSH keys directly.

SSH keys come in pairs - a "private" key and a "public" key. We provide instructions below on how to generate a pair of SSH keys on different computer platforms and you need to do this before accessing our systems.

The private key is something you should keep to yourself and guard safely. If you create the key on a Unix/Linux/Mac system it must not be "world readable" in fact, so that no user on the same system can see it. (Use "chmod 600 ~/.ssh/id_rsa" to correct the file permissions if you get a warning about this.)

However you can safely distribute your public key to anyone with whom you want to communicate. Anyone who has your public key can use it to decrypt messages you encrypt with your private key. This is the 'magic' of public-key cryptography, or asymmetric key cryptography - the purpose of this is to verify that it's really you who is logging on to our systems and only the holder of the private key can do this.

So what we ask for is your public key, which you provide using the SAFE sytem. We then upload this into your new home directory when we create a userid for you (technically - we put it into ~/.ssh/authorized_keys).

When you log on to our systems, your computer's SSH implementation encrypts some data using your private key and sends it to us, which we can decrypt and validate using the public key you provided us with.

Having verified that it's really you, the next thing that happens is that SSH negotiates a further encryption protocol for the actual transport of data between us, and this will use a more standard shared, symmetric key in which both ends of the connection use the same key. The reason for this is that symmetric encryption protocols are much less CPU-intensive, so the CPU-intensive bit is reserved for the authentication and initial negotiation only. But nobody else gets to see this symmetric key exchange, so the encrypted communication remains secure.

You may further protect your SSH private key on your machine when you create it by creating a "passphrase". This means that every time you use SSH you will be prompted to enter this passphrase, and so that anyone else who manages to copy your private key will be unable to use it unless they also know the passphrase.

Further, if you have created a passphrase, you can use the "ssh-add" command on your computer in conjunction with an implementation of ssh-agent so that your passphrase only needs to be entered once and is saved in your computer's memory. This may be convenient if you need to log on and off repeatedly. However we leave this step to you to implement on your own computer if you are adventurous!

One advantage of using SSH keys for logging on to the Hartree Centre systems is that you may have multiple userids on the systems, but we will set them up with the same SSH public key, so that you don't need to remember and maintain multiple passwords.

If you wish to log in to our systems from multiple systems, for example a home and work PC, then you have two options to make this easy:

  1. Copy your private key (probably called id_rsa) between your different systems, remembering to ensure that it is not world-readable
  2. Add more public keys to the file ~/.ssh/authorized_keys in your accounts on the Hartree Centre systems, and more information on doing this is given below

Finally, since we are using SSH to know that it's really you who is logging on to the Hartree Centre systems, how do you know that it's really the Hartree Centre that you're logging on to? Well, the first time you connect you get a prompt which displays the "RSA key fingerprint" and if you want to be certain you can check that this matches the fingerprint of the appropriate system documented on this Web page. If it doesn't match, it's possible although unlikely that you are connecting to someone "pretending" to be us - it's more likely that we've forgotten to update our documentation correctly! However please feel free to contact us at hartree@stfc.ac.uk if you are concerned. Once you agree that it's OK, the details are stored in your ~/.ssh/known_hosts file and you don't get prompted again.

Logging in

You should already have password access to the SAFE system, and you should upload your SSH public key there as described in the SAFE User Guide section before you can login. Once the registration process is complete you should receive an email providing you with your userid.

From a Windows system

This example shows how to use PuTTY (external link: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html) to login. If you're using Cygwin then the process will be very similar to the Linux example below. MobaXterm (external link: https://mobaxterm.mobatek.net/) can also be used as a Windows client to SSH to the server.

A small Flash movie about configuring PuTTY can be seen external link: here

First, start PuTTY. Type phase2.wonder.hartree.stfc.ac.uk into the "Host" box. In order to save your session for future use, give it a name in the "Saved Sessions" box. In this example, we used "Phase 2 Wonder". Now click the Save button.

Creating a new session in PuTTY

You can also enter your login ID in the 'Data' window (under Connections) in the box called Auto-login username.

PuTTy does not yet know that you want to use an SSH key. To add the key, in the navigation tree on the left, expand the + next to SSH, and then click on Auth. Click the Browse button and select the filename of the private key you created previously. For example:

Setting the SSH key in PuTTY

You can also add your UserID so that you don't have to enter it everytime you logon (if you are the sole user of the desktop machine

Go to the Connection > Data screen and type in your userID in the Auto-login username box.

Be sure to click on Session in the navigation tree (you may need to scroll up) to return to the first page, and click Save again.

Now you are ready to login, and you have a ready-made PuTTY session for next time. Click Open to proceed or double-click the session name.

The first time you login, you will be asked to accept the server's host key. Click yes. The RSA key fingerprint should be 52:af:69:42:15:64:9d:91:e2:e9:69:58:41:bf:38:0e. The PuTTY window will now ask "Login as:". Type the userid you have been given if you haven't included it in the Data section.

From a Linux system, or from a Mac system using X11.

ssh to the login node, providing the userid you have been given, which will be in the form axb92-gxh02. For example:

or you could do:

The first time you connect, you will be asked to accept the server's host key. Type Yes to accept it. The RSA key fingerprint should be 52:af:69:42:15:64:9d:91:e2:e9:69:58:41:bf:38:0e.

Maintaining SSH keys

We take the SSH public key you provided to us, and when we set up a new userid we create the file

~/.ssh/authorized_keys

and put the public key in this file.

You may want to modify this file, for example you may want to log on from different places using different SSH private keys, in which case you would add the relevant public keys to the authorized_keys file. Add keys on a separate line in your ~/.ssh/authorized_keys file.

If you have lost your SSH Key or are unable to log on with it, you can change it yourself by logging on using a password. All accounts have a password and you can view your password by:

  • Log on to SAFE (external link: https://um.hartree.stfc.ac.uk/hartree) and click the "View" button on the right of your username under "Your User Accounts".
  • Click "View Password" and enter your web (SAFE login) password then click on "View".

If you plan on modifying this file, we suggest that first of all you create a backup copy, something like:

cp ~/.ssh/authorized_keys ~/.ssh/copy_of_authorized_keys

If you make an error when modifying the authorized_keys file, you may find that you are unable to login again. If this happens, send an email to hartree@stfc.ac.uk telling us what has happened, and we will be able to copy back your backup copy for you and you will be able to log on again. Otherwise, if you have not created a backup copy, we will revert to the single public SSH key you have provided to the SAFE system.

If you update your SSH key in the SAFE system, this update will be reflected when new userids are created for you, but no change will be made to your existing SSH key file for existing userids.

Extracting a public key from a private key (Linux or Mac)

If you're unsure about your public key, you can use:

ssh-keygen -y

This will ask you for the name of your private key file (eg. /home/dcable/.ssh/id_rsa) and will print the public key to stdout, which can be useful for validation purposes.

SSH key conversions (Linux or Mac)

We have seen some instances where the SAFE system complains about invalid characters in ssh keys. This may be because your keys are in 'SSH2 public key format', rather than openssh format. Fortunately, you can use ssh-keygen to do the translation with -i. The following notes are from the man page for ssh-keygen (note that you may need to use -m in conjunction with -i).

-i      This option will read an unencrypted private (or public) key file
             in the format specified by the -m option and print an OpenSSH
             compatible private (or public) key to stdout.  This option allows
             importing keys from other software, including several commercial
             SSH implementations.  The default import format is ``RFC4716''.

     -m key_format
             Specify a key format for the -i (import) or -e (export) conver-
             sion options.  The supported key formats are: ``RFC4716'' (RFC
             4716/SSH2 public or private key), ``PKCS8'' (PEM PKCS8 public
             key) or ``PEM'' (PEM public key).  The default conversion format
             is ``RFC4716''.

File systems

Your home file system will be of the form:

/gpfs/stfc/local/<ProjectName>/<Projectsuffix>/<userid-projectid> on Wonder Phase 2

or /gpfs/bgas/local/<ProjectName>;/<Projectsuffix>/ on Bantam

Other file system areas of interest are listed in the table below (use module avail).

For Wonder Phase 2 Modules

/gpfs/stfc/local/apps/Modules/MODULE_VERSION/modulefiles
/gpfs/stfc/local/apps/Modules/modulefiles/production
/gpfs/stfc/local/apps/Modules/modulefiles/other
/gpfs/stfc/local/apps/Modules/modulefiles/packages
/gpfs/stfc/local/apps/Modules/modulefiles/tools
For Bantam Modules

/gpfs/bgas/local/packages/Modules/modulefiles/packages
/gpfs/bgas/local/packages/Modules/modulefiles/other
/gpfs/bgas/local/packages/Modules/modulefiles/production

System specific environment settings

Most users will have their login shell set to bash. It can be useful to set different environment variables, aliases etc. according to whether you're logged into Bantam or Wonder Phase 2. You can do this in your .bash_profile file, with something like this:

OS=`uname -m`
if [ "${OS}" = "ppc64" ]
        then
        # Put Bantam-specific settings here
elif [ "${OS}" = "x86_64" ]
        then
        # Put iDataplex-specific settings here
fi

Copying Files

To copy files to and from the systems, and also between different accounts on the systems you will need to use scp or rsync. For reasons of confidentiality we do not allow users to copy data directly between project spaces. Some examples are as follows.

# copy from my workstation to the Phase 2 login node
rsync -uav --delete directory-name <userid-projectid>@phase2.wonder.hartree.stfc.ac.uk:<MyDirectory>/.

# another example to follow
scp my_big_file <userid-projectid>@phase2.wonder.hartree.stfc.ac.uk:<MyDirectory>/filestore/.

Using Subversion and GIT and with the Web Proxy

To make a subversion client work with the STFC web proxy, edit the subversion configuration file ~/.subversion/servers, and make sure it has the following lines near the end:

[global]
http-proxy-host = wwwcache.dl.ac.uk
http-proxy-port = 8080

Note: If you have added "export https_proxy=$http_proxy" to your .bashrc file you should remove it as the proxy has been removed.

Then use svn as normal for http:// style URLs. For svn:// style URLs the following incantaction may work:

module load perl5
connect-tunnel -P wwwcache.dl.ac.uk:8080 -T 10234:<server name>:3690 &
svn checkout svn://localhost:10234<path to code> <clone name>
killall connect-tunnel

Note that the port number 10234 is arbitrary and should be one that is not already being used.

For GIT, you can use the proxy server for http or https access, but the native GIT protocol (which is faster) will not work. It is possible to use a git URL by converting to http or https by adding the following lines to your ~/.gitconfig file:

[http]
        proxy = external link: http://wwwcache.dl.ac.uk:8080
[https]
        proxy = external link: http://wwwcache.dl.ac.uk:8080
[url "http://"]
        insteadOf = git://

Maintenance and MoTD

When you log into each system you will see a Message of The Day which will provide current information, e.g. about scheduled maintenance or planned changes. This information will also be available on the status page on this website.

An 'At Risk' day is normally scheduled for 08:00 - 18:00 hrs (UK time) on the first Wednesday of the month, and a full maintenance day is scheduled for the third Wednesday of the month. Access will not be available during the full maintenance period. For up to date information see the Status page here: external link: http://community.hartree.stfc.ac.uk/wiki/site/admin/status.html .

Back to Contents Page