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.
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/
keys/hosts:
total 16
lrwxrwxrwx 1 jdoe 17 Sep 3 10:21 milisant -> milisant.nrao.edu
-rw-r--r-- 1 jdoe 132 Sep 3 10:21 milisant.nrao.edu
keys/users:
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 \
619c5f151f059ba7186c24c8031b05a8f5f94187439cff947a0a5b1499db3ea7
bash$ glishkey
5966343f14f643ae3371e7b7fbfd183253c1834e7c386e15ee164aca8eb8b11a \
d2977ec140fbe3cd17a68c6be9f4e0a70f61b34d2040b68e82c940d77e84fcc7
bash$ glishkey > milisant.nrao.edu
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.
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.
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 
). 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:
).
).
If glishd is unable to run the shell command it generates a fail event with a value of F. If successful then it first generates a okay event with a value of T, then a shell_out event for each line of output generated by the shell command (better would be to buffer all of the output lines together into a single event), and finally a status event containing the exit status of the shell command. All of these events are handled directly by the Glish interpreter; they are not ``visible" in a Glish script.
kill -HUP.