PTYs

If one wants a login-shell, there's still some final point missing. Let's assume that glogin has started /bin/bash, which waits for the user to type some input. Unfortunately, we will not get any response. Why is this?

The answer is that we need something called a 'pseudo-terminal'. A pseudo-terminal is a device which 'emulates' a teletyper-terminal, that is, it allows to set baud-rates (useless in a networked environment), allows to set the size of characeters (5, 6, 7, 8 bits, again, useless in a networked enviroment). But a terminal also can be instructed to convert characters, for instance, it can turn the carriage-return (CR, 0x0d) into a newline (NL, 0x0a). If we turn on this conversion, then suddenly all commands will start to work. The reason: the keyboard generates a CR when the users hits the enter-key, but the shell/the C-library accepts a NL as the end of line. If the terminal doesn't convert CR -> NL, the shell won't recognise the end of line and therefore not be able to execute any command.

Of course we could do this conversion ourselves. But why should we, if the pseudo-terminal already does that job. Moreover, a pseudo-terminal provides additional useful featuers. For instance, hitting the ^C key wont interrupt the program if we are not using pseudo-terminals: we need a pseudo-terminal for the generation of signals such as SIGINT (^C) , SIGSUSP (^T) , we need a pseudo-terminal if we want to suspend/resume the output of a terminal with XON/XOFF. Editors such as vi wont work without a pseudo-terminal: they depend on the 'termios'-structure to read information such as the dimensions of the terminal (rows, cols). Without PTYs, many things are not possible.

A PTY can be thought of as a special kind of data-pipe. This pipe has two endpoints, a pty-master and a pty-slave. Data sent through this pipe is processed by the kernel according to the termios-structure. In a real-terminal enviroment (say, you have a vt100-terminal), the pty-master is the hardware. The pty-slave is connected to the login-shell. In a networked environment, our "hardware" is the network. Therefore, glogin will drive the pty-master. If this sounds to complicated, a little diagram clarifies things:

On the left side, standard input and standard output of the "real" terminal are connected to the glogin-client. On the right side, stdin and stdout are redirected to the slave-endpoint of the pseudo-terminal. Therefore, data flows the way it is required: stdin of the terminal will be sent to stdout of the shell (and vice versa) with the bonus of grid-authentication and a GSS-secured connection.

Additionally, glogin accepts a parameter which allows executing of arbitrary commands. If the "command-to-execute"-paramter is not specified, glogin will execute the standard shell of the user (mapped from grid-mapfile) found in /etc/passwd. By default, this command will be connected to a pty, too, if this is not required, it is possible to turn pty allocation of. In this case, a plain bidirectional pipe will be used.

Tricks pseudo-terminals play

One interesting feature pseudo terminals offer is, at least on linux, the changing of the line discipline. The available line-disciplines can (on linux) be found in /usr/include/asm/termios.h. By default, linux discipline 0 is used, which is "N_TTY". As of kernel 2.4.24, the following line-discplines are available:

     /* line disciplines */
     #define N_TTY           0
     #define N_SLIP          1
     #define N_MOUSE         2
     #define N_PPP           3
     #define N_STRIP         4
     #define N_AX25          5
     #define N_X25           6       /* X.25 async */
     #define N_6PACK         7
     #define N_MASC          8       /* Reserved for Mobitex module  */
     #define N_R3964         9       /* Reserved for Simatic R3964 module */
     #define N_PROFIBUS_FDL  10      /* Reserved for Profibus  */
     #define N_IRDA          11      /* Linux IR - http://irda.sourceforge.net/ */
     #define N_SMSBLOCK      12      /* SMS block mode - for talking to GSM data 
					  cards about SMS messages */
     #define N_HDLC          13      /* synchronous HDLC */
     #define N_SYNC_PPP      14      /* synchronous PPP */
     #define N_HCI           15  /* Bluetooth HCI UART */

The line-disciplines of interest are SLIP and PPP. If we change the line disciplines of our pseudo-terminal to SLIP or PPP, then we will get a network device for free! While I don't know of a comfortable configuration programm for SLIP (although I'm pretty sure there is one), a PPP connection can easily be configured using the widely available ppp-daemon. However, be aware that at least ppp-2.4 is required.

How does this work:

It has been said above that glogin allows the execution of arbitrary commands. Therefore, glogin just has to start a properly configured pppd on the grid-node. Fortunately, there is not much to configure. The configuration file on the grid-node only needs two entries: noauth and loc:rem. The noauth entry tells pppd to avoid pap/chap-authentication. At this point, authentication is not required anymore, because we are using grid-authentification. The loc:rem paramter contains the local and remote IP-addresses, which are used for the point-to-point-connection. An example helps to clarify the setup:
Say, we have two hosts, clio, which is a user-workstation, and pan, which is a grid-node. For the sake of completeness, we'll demonstrate how to perform a simple login first.
We have to "log into the grid", that is, create a valid proxy-certificate:

     hr@clio$ grid-proxy-init
     Your identity: /O=LinzGrid/OU=GUP/CN=Herbert Rosmanith
     Enter GRID pass phrase for this identity:
     Creating proxy .................................................. Done
     Your proxy is valid until: Sun Jan 11 11:07:51 2004

Now, we can log into any grid-node which recognises the CA which signed our certificate. On clio, we just type:

     hr@clio$ glogin pan
    
     hr@pan$ hostname
     pan
     hr@pan$ ps xf
       PID TTY      STAT   TIME COMMAND
     21554 ?        S      0:00 /home/globus/bin/glogin -r -p 0 -c 
     27695 pts/5    S      0:00  \_ -bash
     27300 pts/5    R      0:00      \_ ps xf
     28301 ?        S      0:00 globus-job-manager -conf /opt/globus/etc/globus-job-m

Since we are working with globus, we now have that "single sign-on feature". Any grid-node will accept us as long as the proxy-certificate is valid, without the need to reauthenticate.

By the way, in the output from ps xf above you see that our login-shell, bash, is a child-process of glogin running in service-mode (-r flag). The empty -c option tells glogin to start the users login shell. Analogous to rsh/ssh, any command can be specified using the -c paramter:

     hr@clio$ glogin pan -c "ls -l /usr/src"
     total 3
     lrwxrwxrwx    1 root     root    23 Aug 26 12:30 linux -> linux-2.4.20-gentoo-r6/
     drwxr-xr-x   16 root     root    840 Jan 10 23:31 linux-2.4.20-gentoo-r6
     drwxr-xr-x   16 root     root    656 Sep 17 12:30 linux-2.4.20-gentoo-r7
     drwxr-xr-x    7 root     root    192 May 20  2003 pc
     Connection closed by foreign host.