Before beginning, make sure you understand the difference between using rlogin and telnet to access remote machines. You should also be familiar with the format of an .rhosts file (even though you are not allowed to use these on departmental machines).

You should have read Chapter 1 in Nye and O'Reilly, Vol. 4, before starting this exercise.

1. Practice using X's facilities for distributed computing. First, use the -e option of the xterm command to open a telnet session on kite.cs.orst.edu (or some other machine to which you are not already logged on); see xterm's man page for details).

   What command did you use? What happens when you try to invoke xlogo& from that xterm?

2. The problem is that kite doesn't know where your X server is running.

   ---

   NOTE: If kite had a graphical console, it would display try to xlogo there, right on top of whatever else was already showing. This can be a dangerous exercise. For the departmental machines, a special X utility, xauthority is used to ensure that you don't accidentally alter the appearance of someone else's screen.

   ---

   You must tell the xlogo client which server to use, by adding the -display command-line option. Note that this option should name the machine or Xterminal (either the name or the IP address), followed by :0.0 to indicate that you want the main screen of the main display facility.

   What happens when you run xlogo& again with the -display option?

3. The problem this time is that newt has not been "approved" by your X server. Add python to your server's "approved host" list via the command
   xhost +host-name
   Be careful that this is issued in a window connected to your local machine, not the one you opened onto kite, then try xlogo& again.

   Can the client(remote)-machine, the server-machine, or both kill the xlogo? Describe each way it can be done.

   Now, logout without killing the background logo client.

   What happens?

   Note that you are responsible for terminating all X clients before logging out -- otherwise the server will be unaware that the client is no longer attached.

   Another problem is that xhost is a weak mechanism; it allows any client on the named host to display on your screen. This means that another person could maliciously or accidentally cover everything you have, and you would be helpless to deal with it. Therefore, you should be careful to undo the effects of xhost whenever you have finished with it, by issuing xhost -host-name.

4. The -display option is handy for telling the client where to appear, but it must be specified each time you start up a new client. One alternative is to use the UNIX DISPLAY environment variable on the client's machine. If you use
   setenv DISPLAY host-name:0.0
   any X client started up on that machine will try to display on host-name, unless you specifically override the setting with a -display option (i.e., command-line options take precedence over environment settings). Try this mechanism.

5. Using what you know about remote access, modify your .twmrc file so that the "hosts" menu (accessible using the rightmost button while the cursor is positioned over the backdrop) brings up a list of machines you normally use. Selecting that machine name should automatically open a window and establish the connection. Try out your modifications by using the re-read .twmrc option from the root-window menu.

   Be sure to delete the remote machine from your xhost file when you sever the remote connection.