Difference between revisions of "The Hello GPE World Tutorial"

From ARL Wiki
Jump to navigationJump to search
Line 67: Line 67:
 
== Logging Into an SPP's GPE ==
 
== Logging Into an SPP's GPE ==
  
Now, let's try to log into the SPP interface that you your able to ''ping''.
+
Now, let's try to log into the SPP interface that you were able to ''ping''.
The example below assumes that interface was 64.57.23.210, interface 0 of the Salt Lake City SPP.
+
The example below assumes that interface was 64.57.23.210; that is, interface 0 of the Salt Lake City SPP.
 
Note the following:
 
Note the following:
  
Line 75: Line 75:
 
* Furthermore, you will be logging into your slice in a GPE.
 
* Furthermore, you will be logging into your slice in a GPE.
 
* Even if your network blocks your ''ping'' packets, you should be able to log into a GPE as long as there is a route to the SPP's external interface address.
 
* Even if your network blocks your ''ping'' packets, you should be able to log into a GPE as long as there is a route to the SPP's external interface address.
 +
* You can 'ssh' to any of the SPP's external interfaces.
  
 
To log into a GPE at the Salt Lake City SPP, I would enter:
 
To log into a GPE at the Salt Lake City SPP, I would enter:
  
If you have used ''ssh'' extensively, you probably know how to use an SSH agent so that you only enter your passphrase once.
+
<pre>
If so, you can skip over the next few paragraphs which are oriented for novice ''ssh'' users.
+
    ssh pl_washu_sppDemo@64.57.23.210
 +
</pre>
  
>>>>> HERE <<<<<
+
where my slice is ''pl_washu_sppDemo''.
 +
Thus, the general format is:
  
YOUR_SLICE XXXXX
 
 
<pre>
 
<pre>
     myhost> ssh -v -i ~/id_rsa YOUR_SLICE@64.57.23.210    # Salt Lake City
+
     ssh YOUR_SLICE@IP_ADDRESS
 
</pre>
 
</pre>
  
* The ''-v'' flag (verbose mode) causes ''ssh'' to output debug messages that indicate its progress.
+
where ''YOUR_SLICE'' is the slice you were assigned during account registration, and ''IP_ADDRESS'' is the IP address of an SPP external interface.
* The argument following the ''-i'' flag indicates the private identity file.
 
* This form of ''ssh'' will prompt you for your passphrase.
 
  
 +
During the login process, you will be asked to enter your RSA passphrase unless ''ssh-agent'' or an equivalent utility (e.g., ''keychain'', ''gnome-keyring-daemon'') is holding your private RSA key.
  
 +
== Using ''ssh-agent'' ==
  
If you are successful, you will get about 30 lines of debug output followed by a slice prompt that looks like this:
+
This section is a very brief explanation of how to use ''ssh-agent''.
 +
You can skip this section if you are already using such an agent.
 +
If you have never used such an agent, note that there are several alternatives to the procedure described below and our description is meant to be a simple cookbook procedure.
 +
>>> Reference <<< provides a more detailed explanation of how to use an agent.
 +
 
 +
The basic idea is to run ''ssh-agent'' which is a daemon process that caches private keys and listens for requests from SSH clients needing a private key related computation.
 +
Then, run the ''ssh-add'' command to add your private key to your agent's cache.
 +
This is only done once after you start the SSH agent.
 +
The process will ask you for your passphrase which is used to decrypt the private key which is then held in main memory by the agent.
 +
 
 +
For example,
  
 
<pre>
 
<pre>
    myhost> ssh -v -i ~/id_rsa YOUR_SLICE@64.57.23.210
+
    eval `ssh-agent`
    debug1: Reading configuration data /etc/ssh/ssh_config
 
    debug1: Applying options for *
 
    debug1: Connecting to 64.57.23.210 [64.57.23.210] port 22.
 
    ... 20-30 lines of debug output ...
 
    Last login: Sun Feb 28 00:45:11 2010 from imbrium.seas.wustl.edu
 
    [YOUR_SLICE@salt_spp1 ~]$
 
 
</pre>
 
</pre>
  
Now, log out (enter ''exit'' or ''ctrl-d'') and login again but omit the ''-v'' flag.
+
Notice that we are using backquotes, NOT the normal forward quote characters.
 +
The agent is now running.
 +
It outputs two commands on stdout which is then evaluated by the ''eval'' command.
 +
These two commands set the two environment variables ''SSH_AUTH_SOCK'' and ''SSH_AGENT_PID''.
 +
Enter the command "''printenv | grep SSH_A''", and you
 +
will get output that looks like:
  
Experienced ''ssh'' users use ''ssh-agent'' or an equivalent utility (e.g., ''keychain'', ''gnome-keyring-daemon'') so that they only enter their passphrase once at the beginning of the day.
+
<pre>
Then, they login by enterring:
+
    SSH_AUTH_SOCK=/tmp/ssh-sTNf2142/agent.2142
 +
    SSH_AGENT_PID=2143
 +
</pre>
 +
 
 +
which says that process 2143 is the ssh-agent and it is listening for requests on the Unix Domain socket ''/tmp/ssh-sTNf2142/agent.2142''.
 +
 
 +
Now, add your private key to your agent's cache:
  
 
<pre>
 
<pre>
    myhost> ssh YOUR_SLICE@64.57.23.210
+
    ssh-add        # respond with your paraphrase
 
</pre>
 
</pre>
  
Furthermore, there is no prompt for a password or a passphrase.
+
This adds your private key to the list of private keys held by ''ssh-agent''.
This approach substantially reduces a user's login effort, especially if he/she has to log into SPPs many times during the day.
+
You can now verify that you can ssh to an SPP without a password
 
+
or passphrase.
XXXXX
+
In fact, any subshell of the current shell will not need to enter
 +
a password when logging into an SPP as long as the agent is running because the SSH environment variables are passed to all children of the current shell.
  
 
== Getting Information About Interfaces and Peers ==
 
== Getting Information About Interfaces and Peers ==

Revision as of 06:33, 1 March 2010

Template:Under Construction

Introduction

XXXXX

The SPP Components

XXXXX

Pinging SPP External Interfaces

Unlike most PlanetLab nodes, an SPP has multiple external interfaces. In the GENI deployment, some of those interfaces have Internet2 IP addresses and some are interfaces attached to point-to-point links going directly to an external interfaces of other SPPs. This section introduces you to sone of the Internet2 interfaces.

Let's try to ping some of those Internet2 interfaces. Enter one of the following ping commands (omit the comments):

    ping -c 3 64.57.23.210         # Salt Lake City interface 0
    ping -c 3 64.57.23.214         # Salt Lake City interface 1
    ping -c 3 64.57.23.218         # Salt Lake City interface 2
    ping -c 3 64.57.23.194         # Washington DC interface 0
    ping -c 3 64.57.23.198         # Washington DC interface 1
    ping -c 3 64.57.23.202         # Washington DC interface 2
    ping -c 3 64.57.23.178         # Kansas City interface 0
    ping -c 3 64.57.23.182         # Kansas City interface 1
    ping -c 3 64.57.23.186         # Kansas City interface 2

For example, my output from the first ping command looks like this:

myhost> ping -c 3 64.57.23.210
PING 64.57.23.210 (64.57.23.210) 56(84) bytes of data.
64 bytes from 64.57.23.210: icmp_seq=1 ttl=56 time=67.5 ms
64 bytes from 64.57.23.210: icmp_seq=2 ttl=56 time=55.9 ms
64 bytes from 64.57.23.210: icmp_seq=3 ttl=56 time=59.0 ms

--- 64.57.23.210 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 55.949/60.823/67.511/4.895 ms

Note that you may not be able to ping an SPP external interface. Some reasons why it might fail are:

  1. Your host doesn't have ping installed. This is not typical.
  2. The SPP interface is down.
  3. Your network blocks ping traffic.
  4. Your network provider doesn't route Internet2 addresses.

In the first case, you will get a command not found error message. The ping command is usually located at /bin/ping. See your system administrator if you can't find ping. In the other cases, your ping command will eventually return with a 100% packet loss message. In the last case, running the command traceroute 64.57.23.210 will give a Network unreachable indication (the last router is marked !N).

If you are unsuccessful with one interface, try to ping the interface of a different SPP.

However, you can always get around these problems (except for an SPP being down) by issuing the ping command from a PlanetLab node. We discuss how to log into a PlanetLab node in The IPv4 Metanet Tutorial.

Logging Into an SPP's GPE

Now, let's try to log into the SPP interface that you were able to ping. The example below assumes that interface was 64.57.23.210; that is, interface 0 of the Salt Lake City SPP. Note the following:

  • You must use ssh to log into an SPP.
  • When you ssh to an SPP's external interface, you will actually get logged into a GPE of the SPP.
  • Furthermore, you will be logging into your slice in a GPE.
  • Even if your network blocks your ping packets, you should be able to log into a GPE as long as there is a route to the SPP's external interface address.
  • You can 'ssh' to any of the SPP's external interfaces.

To log into a GPE at the Salt Lake City SPP, I would enter:

    ssh pl_washu_sppDemo@64.57.23.210

where my slice is pl_washu_sppDemo. Thus, the general format is:

    ssh YOUR_SLICE@IP_ADDRESS

where YOUR_SLICE is the slice you were assigned during account registration, and IP_ADDRESS is the IP address of an SPP external interface.

During the login process, you will be asked to enter your RSA passphrase unless ssh-agent or an equivalent utility (e.g., keychain, gnome-keyring-daemon) is holding your private RSA key.

Using ssh-agent

This section is a very brief explanation of how to use ssh-agent. You can skip this section if you are already using such an agent. If you have never used such an agent, note that there are several alternatives to the procedure described below and our description is meant to be a simple cookbook procedure. >>> Reference <<< provides a more detailed explanation of how to use an agent.

The basic idea is to run ssh-agent which is a daemon process that caches private keys and listens for requests from SSH clients needing a private key related computation. Then, run the ssh-add command to add your private key to your agent's cache. This is only done once after you start the SSH agent. The process will ask you for your passphrase which is used to decrypt the private key which is then held in main memory by the agent.

For example,

    eval `ssh-agent`

Notice that we are using backquotes, NOT the normal forward quote characters. The agent is now running. It outputs two commands on stdout which is then evaluated by the eval command. These two commands set the two environment variables SSH_AUTH_SOCK and SSH_AGENT_PID. Enter the command "printenv | grep SSH_A", and you will get output that looks like:

    SSH_AUTH_SOCK=/tmp/ssh-sTNf2142/agent.2142
    SSH_AGENT_PID=2143

which says that process 2143 is the ssh-agent and it is listening for requests on the Unix Domain socket /tmp/ssh-sTNf2142/agent.2142.

Now, add your private key to your agent's cache:

    ssh-add         # respond with your paraphrase

This adds your private key to the list of private keys held by ssh-agent. You can now verify that you can ssh to an SPP without a password or passphrase. In fact, any subshell of the current shell will not need to enter a password when logging into an SPP as long as the agent is running because the SSH environment variables are passed to all children of the current shell.

Getting Information About Interfaces and Peers

  • The scfg utility
  • scfg --cmd get_ifaces
  • scfg --cmd get_peer

Constructing a Tunnel Map

  • Use the output of get_ifaces and get_peer

Making a Resource Reservation

  • scfg --cmd make_reservation and the reservation file
  • Other reservation commands

Creating a Slowpath (GPE) Endpoint

  • scfg --cmd alloc_plspec
  • scfg --cmd alloc_endpoint

Hello SPP

Putting Things Together