FAQ

About this document

How to add/correct an entry to the FAQ?

Just like any other page of the wiki, you can edit the FAQ yourself to improve it. If you click on one of the little "edit" placed after each question, you'll get the possibility to edit that particular question. To edit the whole page, simply choose the edit tab at the top of the page.

Accessing Grid'5000

How to directly connect by SSH to any machine within Grid'5000 from my workstation?

This tip consists of customizing SSH configuration file ~/.ssh/config. We use for this the nc (tcpconnect could also be used) in order to bind stdin and stdout to a network connection:

Host *.g5k
   User login
   ProxyCommand ssh login@access.grid5000.fr "nc  -w 60 `basename %h .g5k` %p"

Please have a look at the SSH page to a deeper understanding of this proxy feature.

Note: Grid'5000 internal network hostnames like *.grid5000.fr are unknown outside of Grid'5000.

Warning: nc and tcpconnect commands are not always available on frontends.

How to access Internet from nodes?

For security reason, it is not possible to connect to Internet from inside Grid'5000, except using the Web proxy client. However, SSH port forwarding is not disabled and you can use the following command, that forward connection to host:port when we connect to host_g5k:port_g5k:

ssh -R port_g5k:host:port host_g5k.site.grid5000.fr

	Note
	If your need is only to access web sites that are not allowed thru the Web proxy server, you may ask the staff to add them to the white listed sites.

How to access InriaGforge from frontends

Accessing INRIA's Gforge repository directly from within Grid'5000 for checkout, commit or even synchronize your project data between Grid'5000's sites is very useful.

Due to security policy, access to InriaGforge from inside Grid'5000 is by default prohibited. Decision to allow access to InriaGforge depends on each site. Following frontends can access InriaGforge:

frontend.bordeaux.grid5000.fr
frontend.nancy.grid5000.fr
frontend.rennes.grid5000.fr
frontend.sophia.grid5000.fr

For other frontends, that do not allow access to InriaGforge, there is a little SSH trick. Edit your SSH configuration file ~/.ssh/config on the host used to access Grid'5000 sites (do not forget to replace site by targeting site, g5klogin by your Grid'5000 username and fwdport by an arbitrary port number > 1024):

Host acces.site.grid5000.fr
    User g5klogin
    RemoteForward fwdport scm.gforge.inria.fr:22

Now connect to configured host (localhost:fwdport will be forwarded to scm.gforge.inria.fr:22):

ssh acces.site.grid5000.fr

Then modify your SSH configuration file ~/.ssh/config on this Grid'5000 frontend (do not forget to replace gforgelogin by your InriaGforge username and fwdport by the previously defined forwarded port number):

Host scm.gforge.inria.fr
    Hostname localhost
    Port fwdport
    User gforgelogin

You can checkout and commit your InriaGforge project repository:

svn co svn+ssh://scm.gforge.inria.fr/svn/project

Link title

How to access InriaGforge from nodes

	Note
	First of all, remember that your home directory is mounted (or can be mounted, in case of a deployed node). As a consequence, you should be able to perform the svn commands from the frontend, while actually using the files on the nodes also.

If connecting a server (e.g. scm.gforge.inria.fr SSH server) that lives outside of Grid'5000, from a Grid'5000 node, you must use both of the previous tips

First

connect to the node from your workstation directly, creating a reverse tunnel

ssh gdx-42.orsay.g5k -R fwdport:scm.gforge.inria.fr:22

Second

reverse connect from the node to the server that is outside of Grid'5000 thru the tunnel

Using:

Host scm.gforge.inria.fr
   Hostname localhost
   Port fwdport
   User gforgelogin

You can checkout and commit your InriaGforge project repository:

svn co svn+ssh://scm.gforge.inria.fr/svn/project

Account management

Why does my home directory not contain the same files on every site ?

Every site has its own file server, this is the user's responsibility to synchronize the personal data between his home directory on the different sites. You may use the rsync command to synchronize a remote site home directory (be careful this will erase any file that are not the same as on the local home directory):

rsync -n --delete -avz ~ frontend.site.grid5000.fr:~

NB : please remove the -n argument once you are sure you actually don't want to do a dry-run only...;)

How to restore a wrongly deleted file?

No backup falicity is provided by Grid'5000 platform. Please watch your fingers and do backup your data using external backup services.

How to increase my quota disk limitation?

Should you need higher quotas, please send an email to support-staff@listes.grid5000.fr, explaining how much storage space you want and what for.

SSH related questions

How to fetch all the SSH host keys of one site?

To avoid answering 'yes' when connecting with SSH for the first time to hosts, the ~/.ssh/known_hosts file can be automatically generated for one site:

nodelist site | ssh-keyscan -tdsa,rsa  -f -

Please have a look at "How to get a site list of nodes?", for information on the nodelist command.

	Warning
	This hint is deprecated with OAR2 and oarsh (but still worths the read if using ssh thru the allow_classic_ssh mode). Report to the staff if needed.

How to avoid SSH host key checking?

With the StrictHostKeyChecking option, SSH host key checking can be turned of. This option can be set in the ~/.ssh/config file:

StrictHostKeyChecking no

Or it can be passed on the command line:

ssh -o StrictHostKeyChecking=no host

How not to get tons of SSH errors about Man-in-the-middle attacks while deploying images ?

If you get the following error when you try to connect a machine using ssh:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 fingerprint for the RSA key sent by the remote host is
6e:44:89:6d:ac:fc:d8:84:fd:2b:fb:22:e5:ba:5c:88.
Please contact your system administrator.

This is because SSH get worried by the fact that the machine answering to the connexion is not the same from run to run. This is actually really logical if you just redeployed the image so it is not same system that is answering...

Technically speaking, the file /etc/ssh/ssh_host_dsa_key.pub is likely to be different in your own deployed image and in the default image. SSH will thus freak out since such replacement usually denote that someone is intercepting the communication and pretend to be the server to get informations from you.

If you don't want to care about this issues, there several solutions:

• Add StrictHostKeyChecking=no to your .ssh/config file to explain SSH to ignore about those errors.
• Pass this option (StrictHostKeyChecking=no) on the command line to ssh (using -o)
• Make sure that you have the same host_dsa_key in your own images than in defaults one. They can usually be found in the pre/post install scripts of your site.

Outside of Grid'5000 scope, the correct solution is to fix your ~/.ssh/known_hosts, either by hand or using the command ssh-keygen -R hostname.

Please have a look at the SSH page also.

Deployment related issues

How to quickly check for nodes health

You can check for nodes health, based on ICMP request, with nmap command if it is available on a site:

nodelist site | nmap -iL - -sP

Or with fping command, if it is available:

nodelist site | fping -a 2> /dev/null

(See TakTuk).

How to kill all my processes on a host ?

On the currently connected host (warning, it will disconnect you)

kill -KILL -1

Job submission related issues

What is the so called "best-effort" mode of OAR?

The best-effort was implemented to back-fill the cluster with jobs considered as less important without blocking "regular" jobs. To submit jobs under that policy, you simply have to select the besteffort type of job in your oarsub command.

oarsub -t besteffort script_to_launch

Jobs submitted that way will only get scheduled on processes when no other job use them (any regular job overtake besteffort jobs in the waiting queue, regardless of submission times). Moreover, these jobs are killed (as if oardel were called) when a regular job recently submitted needs the nodes used by a besteffort job.

By default, no checkpointing or automatic restart of besteffort jobs is provided. They are just killed. That is why this mode is best used with a tool which can detect the killed jobs and resubmit them. However OAR2 provides options for that. You may also have a look at tools like CIGRI or APST.

How to pass arguments to my script

When you do passive submission through oarsub, you must specify a script. This script can be a simple script name or a more complex command line with arguments.

To pass arguments, you have to quote the whole command line, like in the following example:

oarsub -l nodes=4,walltime=2 "/path/to/myscript arg1 arg2 arg3"

Note: to avoid random code injection, oarsub allows only alphanumeric characters ([a-zA-Z0-9_]), whitespace characters ([ \t\n\r\f\v]) and few others ([/.-]) inside its command line argument.