12 December 2005

Bohrg/Dominion User Documentation

1. What are Bohrg and Dominion?

The Bohrg cluster belongs to the Theoretical Chemistry group in the School of Chemistry^{1}. It consists of 115 dual-processor machines. Bohrg was recently (winter 2004/5) re-installed and split into two clusters, Bohrg and Dominion.

The majority of the 115 machines make up Bohrg, a �Beowulf� Linux cluster, based on the NPACI Rocks^{2}/Redhat^{3} distributions. A smaller number make up Dominion, a second Beowulf Linux cluster, based on Debian^{4}.

1.1. Applications

Bohrg

The following applications are installed and available for use on Bohrg:

• Gaussian^{5}

• Portland Group^{6} Fortran compilers.

• NAG Fortran libraries^{7} (for Fortran 77, Mark 20, double-precision).

• Intel Fortran compiler^{8}, v8.1.

• MPI…

• Amber…

• Atlas…

• GopenMol…

• Molden…

• Mopac98…

• Namd…

Dominion

At the time of writing (2005 Apr 18) only Gaussian is available on Dominion, but this will situation will change (improve) in the near future.

                                              src : bohrg_dominion_user_doc.tex, from the sgml.

1 http://www.chemistry.manchester.ac.uk/ 2 http://www.rocksclusters.org/ 3 http://www.redhat.com 4 http://www.debian.org 5 http://www.gaussian.com 6 http://www.pgroup.com 7 http://www.nag.co.uk/ 8 http://www.intel.com/software/products/compilers/flin/

Bohrg and Dominion: User Documentation

1.2. Hardware The hardware comprises:

• 115 IBM X330 dual-processor 1133MHz Intel Pentium 3;

• a SCSI array of 9*35Gb disks;

Each node contains:

• 1Gb, 2Gb or 4Gb RAM;

• 1 or 2 20 Gb internal IDE disks.

2. How do I get an account on Bohrg/Dominion?

Accounts on Bohrg and Dominion are available only to staff and students in the Theoretical Chemistry group^{9}.

To obtain an account, contact Mark Vincent.

You will need to provide Mark with an SSH key. Access to Bohrg and Dominion is by SSH with DSA keys, with passphrase, only � see the sections below on for details.

3. Help!

If you need help relating for Bohrg or Dominion, please:

1. �rst read this documentation;

2. if that does not resolve your problem, speak to Mark Vincent (or perhaps others who have been using the clusters);

3. �nally, contact the Specialist Unix Team based at Manchester Computing (details from Mark).

If you have a problem that is not resolved by reading this documentation, please email us so that we can add appropriate information or examples, or improve what is already here.

4. Accessing Bohrg and Dominion � Overview

This page is intended to give an overview of accessing the Bohrg and Dominion clusters. More details are given in the sections below ( , , …); are also given together with some notes on .

4.1. SSH Bohrg and Dominion can be accessed only by SSH and related utilities (SCP and SFTP). Furthermore, to increase security SSH on your desktop machine needs to be con�gured to use a DSA key with a passphrase.

9 http://www.chemistry.manchester.ac.uk/research/theoreticalchemistry/

4.2. Using X-Windows

The X Window System^{10} can be used to display windows which are �launched� from Bohrg on your local desktop, but such connections must be .

At the time of writing (2005 Apr 14) tunnelling has not been set up on Dominion.

4.3. Gateway Machines

The Bohrg and Dominion clusters are protected by gateway machines, called bohrg1.man.ac.uk and bohrg3.man.ac.uk, respectively. In practice this means that:

• you must login to either bohrg1 (for Bohrg) or bohrg3 (for Dominion) and from there login to the (head/submit) node of the cluster itself, rather than accessing the clusters directly;

• setup a SSH DSA key-pair with passphrase before you can use either cluster.

4.4. Head/Submit Nodes Behind the gateway machines, each cluster consists of a �head� or �submit� node and a number of �compute� nodes. Jobs are submitted to the batch-queueing system (SGE) from the head/submit nodes; jobs run on the compute nodes. (There is no reason for users to login to the compute nodes.)

Bohrg

The head node for this cluster is called storage. (This node doubles as the machine on which the SCSI disk array resides.) Dominion

The head node for this cluster is called dominion1.

5. Gateways: bohrg1 and bohrg3

5.1. Network Topology

Both the Bohrg and Dominion clusters exist on private networks for security reasons. In order to access either cluster, users must �rst login to a gateway machine: for the Bohrg cluster, this is bohrg1.man.ac.uk, and for the Dominion cluster, this is bohrg3.man.ac.uk.

Each gateway machine has two network connections � one facing the public Internet, the other facing the private network on which the cluster sits.

5.2. Home Directories Users’ home directories on bohrg1 and bohrg3 are local and unconnected to home directories on the Bohrg and Dominion clusters.

10 http://www.x.org/X11.html

5.3. Firewalling

Both gateway machines have default-deny �rewalls con�gured, i.e., most connections, inward and outward, whether originating from the outside world, the Bohrg or Dominion cluster, or from the machines themselves, are blocked.

Almost the only permitted connection is into bohrg1/bohrg3 via SSH.

5.4. Restricted User Environment on bohrg3

Users will �nd that once authenticated to bohrg3 their environment is severely restricted: almost the only action available to users is to ssh into the Dominion cluster. This has been done for security reasons.

5.5. Copying Files to/from Bohrg and Dominion (NAT/Forwarding)

Occasionally it is desirable to launch a connection from, say, the Bohrg cluster, to the outside world. For example, you may want to copy (via SCP) a �le to your desktop machine. This is handled by network address translation and connection forwarding on the gateway; it is completely transparent to users and makes it possible to scp a �le from the head/submit nodes to the outside world in one step, rather than by �rst copying it to the gateway � for details, see the FAQ.

6. OpenSSH Access to The Gateways � Keys and Passphrase

This page describes how to set up a DSA key/passphrase to securely connect from your desktop machine (client) to bohrg1 and/or bohrg3 using OpenSSH (with SSH protocol 2).

To be absolutely clear, we are using:

• OpenSSH^{11}, not the version from �XLNK=���SSH Communications Security^{12}, on both client and server;

• we use DSA keys, not RSA keys, and

• SSH Protocol 2 (not 1 or 1.5).

(If you wish to use an SSH client from SSH Comms on your desktop machine, you are on your own!)

11 http://www.openssh.org

12 http://www.openssh.org

6.1. Prerequisites

1. Ensure you have an up-to-date version of OpenSSH installed on your desktop machine. Furthermore, ensure that no other implementation of SSH, e.g., that from SSH Communications Security (www.ssh.com) is around to confuse the issue.

2. Ensure that on your desktop machine, within your home directory, a sub-directory called .ssh exists and that the permissions are correct, e.g.,

        drwx------   2 simonh users     136 2005-01-05 12:17 .ssh

i.e., the directory is private to the owner.

6.2. Generating, Installing and Testing the Key

1. First we make the key. On your local/client desktop machine type

ssh-keygen -t dsa

You will be prompted for the name of a �le in which to keep the key (the default is �ne). You will also be prompted for a passphrase � don’t use a blank or easily-guessed passphrase. You will see something like this:

prompt> ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/mc/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mc/.ssh/id_dsa.
Your public key has been saved in /home/mc/.ssh/id_dsa.pub.
The key fingerprint is:
e0:............................................:xy user@clienthost
prompt>

Two �les are created: ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub. The �rst is your private key; the second is your public key.

2. Copy your public key to your .ssh directory on bohrg1 and/or bohrg3 � ask Mark Vincent to do this.

3. Test that the key-pair is working � make use of your SSH client’s verbose mode to do this:

ssh -v bohrg1.man.ac.uk -l simonh -v
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to bohrg1.man.ac.uk [130.88.200.111] port 22.
debug1: Connection established.
.
.
debug1: identity file /home/simonh/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1 Debian 1:3.4p1-
1.woody.3
.
.
debug1: Host 'bohrg1.man.ac.uk' is known and matches the RSA host key.
debug1: Found key in /home/simonh/.ssh/known_hosts:1
.
.
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey

Notice the available methods of authentication and their order: publickey, password and keyboard-interactive. The �rst is our key-with-passphrase-based method; the others are password-only-based methods (used above to copy id_dsa.pub to the remote machine).

            .
            .
            debug1: Offering public key: /home/simonh/.ssh/id_dsa
            .
            .
            Enter passphrase for key '/home/simonh/.ssh/id_dsa':

Enter your passphrase and hit return, and you will be authenticated and logged in as usual.

7. PuTTY Access to The Gateways � Keys and Passphrase

8. Submit Nodes: storage and dominion1

8.1. Network Topology

To access the Bohrg or Dominion Cluster users should login to the appropriate head or submit node, storage for Bohrg and dominion1 for Dominion, via the appropriate .

8.2. Home Directories On login to both storage and dominion1 users will �nd themselves in their home-directory mounted from the SCSI array attached to storage as

    /home/bohrg/<username>

(/home/dominion/<username> is not used on Dominion). This home-directory is shared across the two clusters, i.e., users’ will see the same �les on both machines.

8.3. Scratch Space

On login to both storage and dominion1 users will be able to access their scratch space mounted from the SCSI array attached to storage as

    /scratch/bohrg/<username>

(/scratch/dominion/<username> is not used on Dominion). This scratch space is shared across the two machines.

8.4. Submitting and Monitoring Jobs: SGE

Users must never run jobs on storage or dominion1; all jobs should be submitted to the . SGE can also be used to monitor the progress of jobs.

8.5. Access to the Outside World For information on access from the Bohrg and Dominion clusters to the outside world, especially copying �les, see the FAQ.

8.6. Access to Compute Nodes

There is usually no reason for users to access the compute nodes on either cluster (except via the SGE). (When code and scripts are being developed, such access can be justi�ed.)

At the time of writing (2005 April 18) users can login to the compute nodes on the Bohrg cluster, but cannot login to the compute nodes on the Dominion cluster. In the near future user access to the compute nodes on Bohrg will be blocked.

9. Example Login Sessions

9.1. Accessing the Bohrg Cluster

Following is a simple example session in which I begin at my desktop machine as user simonh, ssh into bohrg1 and from there into storage, the head/submit node for the Bohrg cluster.

First, login to bohrg1 � note that a passphrase for a key is prompted for:

simonh@mctalby: $ ssh mpciish2@bohrg1.man.ac.uk
Enter passphrase for key '/home/simonh/.ssh/id_dsa':
*****************************************************************************
    This is the Bohrg gateway, bohrg1.man.ac.uk (aka bohrg.man.ac.uk).
    Any questions or problems to Mark Vincent in the first instance.
*****************************************************************************
Last login: Fri Apr 15 13:27:41 2005 from mctalby.mc.man.ac.uk
mpciish2@bohrg1: $ ls -al
total 20
drwxr-xr-x    3 mpciish2 users        4096 Apr  6 13:56 .
drwxr-xr-x    3 root     root         4096 Feb 27 17:43 ..
-rw-------    1 mpciish2 users          52 Apr  6 13:55 .Xauthority
-rw-------    1 mpciish2 users         313 Apr 15 13:32 .bash_history
drwx------    2 mpciish2 users        4096 Apr  6 13:55 .ssh

If you are not prompted for a passphrase for a key, something is not working correctly and you will not be able to login. Notice the directory called .ssh and the permissions on that directory (it is private).

Next, login to storage:

mpciish2@bohrg1: $ ssh storage
mpciish2@storage's password:
Rocks 3.1.0 (Matterhorn)
Profile built 17:25 09-Oct-2004
Kickstarted 17:25 09-Oct-2004
-bash-2.05b$ ls -F
src/                trash/                 compat-libstdc++-7.3-2.96.118.i386.rpm
pgi_master_license  RaidMan-7.00.i386.rpm
-bash-2.05b$ ls -F

Notice that this is not the same home directory as that on bohrg1.

From here, storage, I can use SGE to submit and monitor jobs:

-bash-2.05b$ qstat
job-ID  prior name       user         state submit/start at     queue      master  ja-task-
ID
---------------------------------------------------------------------------------------------
 1075     0 a4aEZRRCa  mbdtsmv      r     04/05/2005 10:05:18 compute-0- MASTER
          0 a4aEZRRCa  mbdtsmv      r     04/05/2005 10:05:18 compute-0- SLAVE
 1211     0 r_h2o_3
 .
 .
 .

9.2. Accessing the Dominion Cluster

Following is a simple example session in which I begin at my desktop machine as user simonh, ssh into bohrg3 and from there into dominion1, the head/submit node for the Dominion cluster.

First, login to bohrg3 � note that a passphrase for a key is prompted for:

simonh@mctalby: $ ssh mpciish2@bohrg3.man.ac.uk
Enter passphrase for key '/home/simonh/.ssh/id_dsa':
Last login: Wed Apr  6 13:40:07 2005 from mctalby.mc.man.ac.uk
-bash-2.05b$ ls
-bash: ls: command not found
-bash-2.05b$ telnet
-bash: telnet: command not found
-bash-2.05b$ pwd
/home/mpciish2

Notice that the environment is severely restricted � neither ls nor telnet are available. (pwd is built in to the shell.)

Next, login to dominion1:

  -bash-2.05b$ ssh dominion1
  Password:
  Linux dominion1 2.4.27 #2 SMP Mon Mar 7 17:42:23 GMT 2005 i686 GNU/Linux
  The programs included with the Debian GNU/Linux system are free software;
  the exact distribution terms for each program are described in the
  individual files in /usr/share/doc/*/copyright.
  Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
  permitted by applicable law.
  Last login: Tue Mar 22 09:44:37 2005 from 10.2.62.250
  mpciish2@dominion1: $ ls -F
  src/                trash/                 compat-libstdc++-7.3-2.96.118.i386.rpm
  pgi_master_license  RaidMan-7.00.i386.rpm
  mpciish2@dominion1: $

Notice that the �les visible are the same as those on storage (above) as the home-directories are shared between the two clusters.

10. Tunnelling X-Windows through SSH

Traditionally X-Windows applications can be started on a remote server and displayed on your local desktop by means of commands like xhost +bohrg.man.ac.uk

  (on your local machine) and export DISPLAY=mymachine.ch.man.ac.uk

(on the remote server). This method is insecure and is blocked on Bohrg and Dominion. Instead, tunnel your display through SSH as described below.

10.1. Tunnelling X-Windows Applications on the Bohrg Cluster

Following is a simple example in which I begin at my desktop machine as user simonh, ssh into bohrg1 and then storage, and from there start a graphical, X-aware client which displays in a new window on my local desktop.

First, login to bohrg1, note the -X option which enables X-Windows forwarding (not -x, which disables forwarding):

    simonh@mctalby: $ ssh -X bohrg1.man.ac.uk -l mpciish2
    Enter passphrase for key '/home/simonh/.ssh/id_dsa':
    Warning: No xauth data; using fake authentication data for X11 forwarding.
    ***************************************************************************
        This is the Bohrg gateway, bohrg1.man.ac.uk (aka bohrg.man.ac.uk).
        Any questions or problems to Mark Vincent in the first instance.
    ***************************************************************************
    Last login: Fri Apr 15 13:32:12 2005 from mctalby.mc.man.ac.uk
    mpciish2@bohrg1: $
Note the line Warning: No xauth data; using fake authentication data for

X11 forwarding. Now con�rm that your SSH client and the SSH server on bohrg1 are in agreement that X11 traf�c should be forwarded:

    mpciish2@bohrg1: $ echo $DISPLAY
    localhost:19.0
    mpciish2@bohrg1: $

If, instead of localhost:19.0 or similar (the number will vary), you see nothing, or something like desktop.ch.man.ac.uk:0, then chances are that tunnelling is not set up. (In the former case bohrg1 is not set up to attempt to display any X-Windows application on your desktop; in the latter case it is attempting to bypass the SSH connection and make a new connection in the �old fashioned� way � this will fail.)

Next, login to storage:

    mpciish2@bohrg1: $ ssh -X storage
    mpciish2@storage's password:
    Rocks 3.1.0 (Matterhorn)
    Profile built 17:25 09-Oct-2004
    Kickstarted 17:25 09-Oct-2004
    -bash-2.05b$

Notice that again I have speci�ed the -X (uppercase) option. Again it is worth con�rming that tunnelling is set before starting a graphical client in the background:

    -bash-2.05b$ echo $DISPLAY
    localhost:19.0
    -bash-2.05b$ xclock &
    [1] 12390
    -bash-2.05b$

The clock should appear on your local desktop, perhaps after a few seconds.

10.2. Tunnelling X-Windows Applications on the Dominion Cluster

At the time of writing (2005 Apr 18) X-Windows applications cannot be tunnelled through SSH on the Dominion cluster. This situation will change in the near future.

11. File System Overview

This page is intended to offer an overview of the �lesystems on the Bohrg and Dominion clusters which are of interest to users. More information is available on the pages below ( , and ).

11.1. Hardware/Disks The �core� storage on Bohrg and Dominion is based around an array of SCSI disks which is physically attached to storage, the head/submit node for Bohrg.

In addition, each node contains 1 or 2 internal disks.

11.2. Central Filesystems

The following �lesystems live on the central SCSI disk and are automounted on dominion1 (head/submit node for Dominion) and on all the compute nodes (on both clusters):

    /home/bohrg/<username>
    /scratch/bohrg/<username>
    /software/bohrg/<application>

These are, respectively, users’ home directories, users’ central scratch space and the applications available, such as Gaussian and the PGI compilers.

11.3. Local Filesystems

On each node, spare disk space has been allocated as scratch space. Currently this is accessible as

    /tmp               # Bohrg compute nodes
    /local_scratch     # Dominion compute nodes

A naming convention which will apply across all nodes will hopefully be worked out soon!

11.4. Automounted Filesystems

All �lesystems which live on the central SCSI disk are automounted to make them available to users. This means that they are mounted on demand and if they are not used for a speci�ed time they are unmounted.

11.5. Automounted Filesystems � A Warning

The automounter can cause confusion. Here is an example:

    bohrg> cd /software
    bohrg> ls -a
        .  ..
    bohrg> cd bohrg                      # or cd ./bohrg
    bohrg> ls -a
        amber  gaussian...

Automounted directories are mounted on demand � listing the parent directory does not count as demand!

12. Home Directories

12.1. Home Directories on the Bohrg and Dominion Clusters

Each user of the Bohrg and Dominion clusters has a home-directory which lives on the central disk array � this directory is shared between the two clusters (i.e., users will see the same �les on

dominion1 as on storage).

Users will �nd themselves in their home-directory on login. These directories are automounted and accessible as

    /home/bohrg/<username>

on storage, dominion1 and both sets of compute nodes.

12.2. Home Directories on the Gateway Machines

Home-directories on bohrg1 and bohrg3 are completely independent of those on the clusters; they live on the internal disks of the gateway machines.

This said, for backup purposes, and so as to help �le transfer between Bohrg (and Dominion), and the outside world, home-directories from storage are accessible as /home/bohrg/<username> on bohrg1 (not on bohrg3) � this access is read-only for security-related reasons.

12.3. Quotas There are currently no home-directory quotas in operation. If space becomes short quotas will be introduced.

12.4. Backups

Home-directories are backed up. In the event of a disk-crash (or accidental �le deletion) �les stored in home-directories will be restored. Backups are taken on most days, so that restored directories (or �les) should normally be at most a few hours out of date.

13. Scratch Space

13.1. Central Scratch Space

A total of 67Gb is currently available for central scratch space. This space is shared amongst all users. Each user has a directory within the central scratch space allocated to them. This directory is automounted as

    /scratch/bohrg/<username>

on both storage and dominion1 (the head/submit nodes), and on all compute nodes.

13.2. Scratch Space Local to Compute Nodes

All compute nodes have scratch space available to users on a local/internal disk. I/O to local scratch space should be faster than to central scratch space.

The amount of local scratch space available varies from node to node, but a minimum of 8.2Gb should be available on all nodes:

Dominion

On Dominion 8.2Gb of scratch space is available on each node. This is currently mounted on

/scratch_local

Bohrg

On Bohrg, some machines have one internal disk while others have two, so that the amount of local scratch space available varies considerably. Roughly speaking, nodes making up the �Big Mem queue� (more accurately, parallel environment) have 19Gb, while the other nodes have 14Gb.

13.3. Rules of Usage

…

13.4. Links from Home Directories to Central Scratch Space

…

13.5. Tidy-Up Scripts

On some machines hosted by Manchester Computing scratch space is regularly �tidied up�, e.g., �les created more that a month ago are automatically deleted. At present (2005 Apr 19) there is no such automated deletion. Should scratch space become short this automation might be introduced.

13.6. Quotas There are currently no scratch space quotas in operation. If space becomes short quotas will be introduced.

13.7. Backups

Scratch space is not backed up. Do not store any �les in scratch space which you need to keep or cannot easily reproduce (e.g., from a re-run of a job).

14. Software: /software

15. Running Gaussian on Storage and Dominion1

1. First you will need to set up your environment such that it knows about the batch system.

a. For Storage and Dominion1 edit your .profile (ksh and bash users) and add to your path

the location of qsub (needed by toq):

            export PATH=$PATH:/usr/local/sge_5.3p6/bin/glinux

b. Also, in your .pro�le put the location of SGE via

            export SGE_ROOT=/usr/local/sge_5.3p6

c. To make these changes take effect type

            . .profile

4. You will need to get a copy of the RunGauss script:

a. For Storage copy the RunGauss script from /usr/local/bin to you own �le space (your own bin directory would be an ideal place for it!). Use this version in your own �lestore for all calculations.

b. For Dominion1 copy the RunGaussDom from /usr/local/bin to your own �lestore (i.e. ~/bin/RunGaussDom). Use this version to run jobs.

    c. Use the -g03 option of RunGauss (i.e. ~/bin/RunGauss -g03 -i job.com -o job.out
      or RunGaussDom -g03 -i input.com -o output.out).

4. Use the toq script to submit jobs:

a. An example of the use of the toq script is

            /usr/local/bin/toq -nodes 1 -procs 2 -q any_std -lt 96:0:0 -r jobname runscript

Needless to say jobname is your name for the job and runscript is your script that has the Rungauss (or RunGaussDom) command in it. Note runscript should be executable (i.e. to make executable do: chmod a+x runscript). any_std is the queue the job will run in (it has a time limit of 96:0:0 hours, hence -lt 96:0:0). Note that most jobs will only need to use this queue, however, there is a bigmem queue on Storage which has a time limit of 120:0:0 hours and a larger memory size (hence the name).

16. Amber

 ???

17. User Environment

Should all just work, but just in case here is what to check:

 -- user environment :
     -- echo $PATH, echo $MANPATH
     -- PATH=.....:/software.....
     -- MANPATH=.......
 -- /etc/profile, /etc/bashrc,  /.profile,  /.bashrc

Shell:

 -- ksh and bash;
 -- chsh...

18. Software/Applications

 -- pgi compilers
     -- PGI_ROOT=/software/pgi-524
     -- LM_LICENSE_FILE="7496@psico.ch.man.ac.uk"
 -- gaussian
 --

19. The Batch/Queue System � SGE

Environment should be set up for you vi /etc/profile, but if there is a problem please check:

 -- export SGE_ROOT=/usr/local/sge_5.3p6
 -- PATH includes...
 -- MANPATH includes...

Using:

 -- qstat --

20. Why do we need to use SSH keys, they make life dif�cult!

Yes, unfortunately the use of SSH keys (with passphrases) can be confusing. SSH is far more complex than Telnet � there at least 4 authentication methods, some of which involve keys, and there are different types of keys too.

(To access bohrg1 and bohrg3, follow these notes^{13}, the section on Key/Passphrase Authentication in particular. N.B. Use DSA keys to access these machines, nor RSA keys.)

13 ../_ssh

At the time of writing (2005/April/05) accounts on HPC machines connected to the Internet are increasingly being compromised, globally. Frequently this is done by �rst compromising the desktop machine from which a user logs in to the HPC machine; key-grabbing software is often installed on such compromised desktops. The use of keys with passphrases means that an HPC account cannot be compromised by this method.

21. How do I copy �les to/from Bohrg/Dominion?

21.1. General There is no FTP access to or from Bohrg/Dominion. Neither can the �r�-commands be used, e.g., rcp. The only way to copy �les to or from Bohrg/Dominion is to use scp or sftp.

21.2. Possible Connections Recipes for copying �les to and from Bohrg and Dominion are given below. By way of background information the following information can be noted:

To/from bohrg1/3

• SSH/SCP/SFTP connections from the outside world to bohrg1 and bohrg3 are permitted (DSA key and passphrase required), but

• SSH/SCP/SFTP connections from bohrg1 and bohrg3 to the outside world are blocked for security-related reasons.

To/from storage/dominion1

• Direct SSH/SCP/SFTP connections from storage and dominion1 to the outside world are possible (such connections travel through bohrg1 or bohrg3 transparently thanks to the wonders of network address translation).

• It is not possible to make any direct connection from the outside world to storage or dominion1 for security-related reasons.

21.3. Additional Info The following information is also pertinent:

• home directories from storage are accessible read-only on bohrg1, as

   /home/bohrg/<username>.

21.4. Recipes

To download to your desktop machine from storage or dominion1

From you desktop machine, scp or sftp �les from /home/bohrg/<username> on bohrg1.

Notes:

1. that this accessibility is read-only, so you cannot upload �les to storage by this means;

2. it is not possible to download �les from bohrg3 in this manner. To upload from your desktop to storage or dominion1

1. From your desktop machine, scp or sftp �les to /home/<username> on bohrg1 or

   bohrg3.
 2. From bohrg1 or bohrg3, scp or sftp �les to storage or dominion1.

Unfortunately, an upload requires two steps (though see below).

For those few running an SSH/SCP/SFTP service/daemon on their desktop machine, it is possible to reduce the previous recipe to a single step. N.B. Running such a service on your desktop machine has signi�cant security implications, so do not do this unless you are con�dent that you fully understand patching, �rewalls and intrusion detection.

To download to, or upload from, your desktop machine to/from storage or dominion1, if your desktop machine is running an SSH daemon

Login to storage or dominion1 in the usual way. From there, scp or sftp directly to your desktop machine. For example:

        storage> scp fred@desktop.ch.man.ac.uk:myfile myfilehere

or,

        storage> scp myfile fred@desktop.ch.man.ac.uk:myfilethere

22. How do I use X-Windows to view graphical applications?

bohrg1/storage

1. desktop> ssh -X bohrg1.man.ac.uk -l <username>
       -- "-X" not always required, depends on config on your desktop machine,
          but will do no harm;
       -- NOT "-x";
2. bohrg1> ssh storage
3. storage>xterm &
    -- do not "export DISPLAY=..." or "setenv DISPLAY ..."
    -- do not su at any stage

bohrg3/dominion1

-- not at the moment, to come...

23. How do I access the machines from home?

The machines are �rewalled and are accessible from Chemistry (130.88.80.*, 130.88.83.*, 130.88.12.*) and from The University VPN^{14}, only. So if you wish to login from home, you must use the VPN.

About this page:

Produced from the SGML: /home/mc/public_html/_bohrg/_reml_grp/bohrg_dominion_user_doc.reml

On: 12/12/2005 at 13:43:19

Options: reml2 -l nolong -o tex -p single

 14 http://www.mcc.ac.uk/vpn/