Overview

In the grid-environment, it may not be possible to directly log into grid-nodes. The usual practise is to firewall login-sessions to grid-nodes, but give the user an account on a different machine to bounce off. This method is a bit long winded, because it requires the user to connect to two machines, eventually entering the password each time. On the other hand, a direct connection to the grid-node is neccessary: it is required to contact the gatekeeper in order to submit jobs. Consequently the gatekeeper is used to start up a login-shell. 

Limitations of the Globus-Gatekeeper

As we have already learned, it is not possible to communicate through the gatekeeper-connection (this is done by globus_gram_client_-calls) in "real time". This connection is an https-stream, and everything sent through it is placed in the gass-cache. As of globus-2.4, there is no possibility to force emptying of the gass-cache. At the time of this writing, it is unknown if globus-3 offers such a feature. It has been observed that the gass-cache is emptied within a polling interval after the program writing to the cache has exited. The polling period seems to be somewhere at 10 seconds, which means that data could survive the exiting of the generating program for this amount of time at worst. This system is a batch-job-submission-system, obviously. If one needs interactivity, as login-shells need, one has to use a different approach.

Getting interactive connections

The solution has already been shown at the conference in Poznan, when the flowvisualisation was demonstrated. Once the remote program has been started on the grid-node by the gatekeeper, it will take care of communication itself. While in Poznan secure communication was not ready, it has been implemented now. The next diagram shows how interactive communaction is established trough the globus-gatekeeper:

• In (1), the requesting client contacts the gatekeeper
• In (2), the gatekeeper starts the requested service
• In (3), the requested service creates a listener socket
• In (4), the requesting client directly contacts the requested service
• A direct connection (=no globus-gatekeeper) between the client and the service has now been established. Interactive data exchange between the peers can now take place. Since this connection is a globus-connection, data can be transmitted in a secure way.

glogin: Some Details

• How does the client know where to concact the service?

  For one, glogin accepts a port-parameter, which instructs it to create fixed port tcp-connections. This is not good practice, since one can never be sure if another user is using the same port, which would cause failure when trying to create the listener socket. Another option is to use dynamic tcp-ports, which means that the system will assign a free tcp-port. In this case, the service has to tell the client where it can be reached. At this point, the only connection to the client is the gram-client gatekeeper-connection. But as stated earlier, anything written to the gass-cache will stay there unless either the program terminates or one overflows the gass-cache by writing useless data to it. Since the size of the gass-cache is unknown to us, glogin uses the first method. After it has allocated a free tcp-port, it fork()s a copy of itself. Then, it sends the port-number to the client trough the gatekeeper connection. After that, it terminates. The gatekeeper will recognise program-termination and empty its cache. The client will then connect to the listern socket which is still held active by the perviously fork()ed copy of the service.

• What is "client" and "service" with respect to glogin? What is the "service" if we want a login-shell?

  glogin is both the client and the service. It tells the gatekeeper to start itself. By using the -r option, glogin is instructed to act as the remote-part of the connection, that is, act like a service. Once the client-side has a "direct" connection to the service-side of glogin (see above), the service-side will start up the user's login shell. It will intercept all output from the shell, transmit it over the globus-connection. The client-side of glogin will read data from the globus-connection and write it to the users terminal. It will accept any keystrokes, transmit it over the globus-connection, where the serivice-side of glogin will pick it up and send it to the shell. Voila - there is the globus-IO-secured shell.

  At this point you might ask yourself, why this is done in such a complicated way. Why not just start the shell...? The answer was given above: globus seems to be a batch-job-submission system. If we want interactivity, we need a helper program. This helper-program is "glogin" in this case. It is not possible to

      globusrun -w -r <grid-node> '(&executable=/bin/bash)'
  

  and hope to get an interactive shell from the gatekeeper.