next up previous contents index
Next: Transmitting Events Up: Internals Previous: Encoding Event Values

Creating and Controlling Remote Clients


      Clients on a remote host are controlled by a daemon called glishd. This process takes care of starting clients, checking on them as they run, and terminating them. It is Glish's intermediary on the remote machine. An important point, though, is that while glishd will create clients, all event communication between those clients and the interpreter is still done directly, via a socket connection, and not using glishd as an intermediary.

glishd is designed to be run either by root or by individual users. glishd is only started by the interpreter (on behalf of a user) if a glishd has not already been started by root on the remote machine. The behavior of glishd is different depending on if it is running as root or not.

glishd Started by Root


When glishd is started by root, it handles all client requests for all users on a given machine. It does this by listening to a published port (TCP port 4077) to which interpreters connect.       When an interpreter connects to this port, glishd forks a copy of itself. This forked copy of glishd immediately sets its userid to the user which connected. From that point on, the forked process will handle all requests from that user. In general when all of that user's interpreters exit, the forked process exits too. The only time when this isn't true is if the forked glishd started shared clients which are persistent; in this case, it sticks around to manage these remaining clients which will be used again.

glishd must be started by root for the shared client capabilities (see § 7.9) to work properly.

To identify users, glishd uses key files. Each host is assigned a unique key when glishd is set up. A key file is created for each user by Glish (if one doesn't already exist) the first time the user starts a client. It is assumed that the key directory will either be network accessible, e.g. via NFS, or that the keys will be distributed to all machines on which clients will be started. Note that if keys must be distributed manually, keys will need to be created for users as well as hosts because the keys automatically created by Glish won't be seen on other hosts. Key files must be owned by the user to whom the key belongs and only the user should have read/write permission. Here's an example of what the keys directory for Glish might look like:

    bash$ ls -lR keys
    total 8
    drwxr-xr-x   2 jdoe          512 Sep  3 10:16 hosts/
    drwxrwxrwx   2 jdoe          512 Sep  3 10:18 users/

    total 16
    lrwxrwxrwx   1 jdoe           17 Sep  3 10:21 milisant ->
    -rw-r--r--   1 jdoe          132 Sep  3 10:21

    total 8
    -rw-------   1 jdoe          132 Sep 14 11:48 jdoe
This is the directory hierarcy Glish expects to find for its keys. The important thing to note is that the ``hosts'' directory must be readable by all Glish users, and the ``users'' directory must be writable by all Glish users.

Key files can be created by running glishkey which should be built along with Glish. Here's an example:

    bash$ glishkey 
    5971b940c8eb94edc374aa0389c46a409fbcf1c91eb3b27e0bae444ee0259f57 \
    bash$ glishkey 
    5966343f14f643ae3371e7b7fbfd183253c1834e7c386e15ee164aca8eb8b11a \
    bash$ glishkey >
Each time glishkey is run it generates another key. A key file is created by simply piping the output of glishkey to a file.

The full path to the directory containing the ``users'' and ``hosts'' directory is built into Glish, but it can be changed from within Glish by setting system.path.key     value to a specific path. The path which glishd uses can't currently be changed, though.

If you need to kill a root glishd, you should use the HANGUP signal, i.e. kill -HUP.

glishd Started by the Interpreter


If the Glish interpreter fails to connect to the glishd port, it assumes that there is no root glishd running and starts a glishd. The interpreter starts glishd using   the rsh command   (called remsh on some systems). Thus the user that invoked the interpreter must have an account on the remote host, and must have transparent access to that account enabled via the user's   .rhosts file. Furthermore, glishd runs with that user's permissions. This glishd which was started by an interpreter does all of the things that the root glishd would do, but it only handles request from that specific interpreter. So each interpreter running remote clients on a given machine would have a glishd running. When the interpreter exits, glishd exits.

glishd Events


In addition to creating and controlling clients, glishd provides   a mechanism for detecting network outages. Every five seconds the Glish interpreter sends a ``probe'' event to glishd. If it receives no response within the next five seconds, the interpreter deems network connectivity lost, generates a warning message to this effect, and creates a ``connection_lost'' event for the system agent (§ 9.11, page gif). If glishd subsequently responds to another probe then the interpreter deems connectivity regained, reports this fact, and generates a ``connection_restored'' event for system. If glishd exits for any reason (e.g. it crashes or is killed), then the interpreter generates a ``daemon_terminated'' event for system.

glishd is itself a Glish client and responds to the following events:


next up previous contents index
Next: Transmitting Events Up: Internals Previous: Encoding Event Values

Thu Nov 13 16:44:05 EST 1997