Disabling Quit On Telnet

[Bob Rasmussen]

Boy, lots of room for discussion here, although the sun is shining and the
flower beds need turning...

A Couple of Minor Points
------------------------
1. Anzio can't behave like FacetWin, because we don't have a piece running
on the host.

2. Alt-F4 doesn't normally quit Anzio, because we dedicate all the F-key
combinations to other puerposes.

How Quits Happen Normally
-------------------------

Assuming you're connected via telnet or SSH, here is what happens. When
you quit Anzio by ANY means (the X box, the File:Quit menu item, a macro,
a Windows shutdown, etc.), Anzio does an orderly socket shutdown. The
telnetd (sshd) detects this, and generates a hangup signal, SIGHUP, to the
tty process associated with this socket.

Like any Unix signal, this can be trapped or propogated down the chain of
child processes.  If in fact it reaches the filePro runtime (that is, it
has not been trapped above that point), I don't know if fP gives you any
control over its behavior.

If the SIGHUP is successfully trapped by some process, such as a shell
script), further up the chain, the filePro process should continue to run.
However, it would be an orphaned process, and Unix provides no way to
reconnect to it, except, I have been told, by clever use of "screen". But
at least, if you later on killed that process, it should have finished its
burst of file updates.

Ideally, filePro would let you temporarily trap certain signals during a
critical update phase, and untrap them later.

A "dirty" termination should occur only if the user turns off the PC, uses
task manager to terminate the process, the network  is interrupted, etc.

How You Can Restrict Anzio
--------------------------

We've addressed this in many ways. As has been mentioned, there is a
"Disable Quit" security setting. This affects almost all methods of
quitting. The only exception is the QUIT command, which can be placed in a
macro for instance. Users are not likely to know of this. It's one step up
from killing the Windows process, and is necessary in certain situations.

It's also possible to configure Anzio so it doesn't have the title bar.
This prevents the user from clicking the X, because it's not there.

But the OP is right, the user might find a configuration setting and
change it. If you want to exercise control over the client side, there are
many options. I'll touch on them here. There is more information in the
Anzio manual and the README.TXT file.

1. Run Anzio in kiosk mode. This can be specified either at the command
line that launches Anzio, or in the settings file that Anzio uses. In
kiosk mode, you can specify a limited menu, down to no menu at all. The X
box is dependent on File:Quit still being there.

2. In kiosk mode, the user can not change any settings, other than the
most trivial.

3. You can alter the Anzio executable, with a resource editor, to include
certain settings strings that are a) the default, and/or b) required
settings.

4. In the settings file, you can include a string of menu items to delete
on startup.

5. The EXE can be loaded from an HTTP[S] or FTP server, with parameters
specified in the filename.

6. The settings file can be loaded from an HTTP[S] or FTP server.

7. You can "Block hibernation" and "Block screensaver", as either of those
might disrupt a network connection.

Some of these were new in 15.0.

Brainstorming
-------------

I've also batted around a couple of other ideas, which would involve
modifying the daemon (probably sshd) on the server. I'll throw them out
here and ask for comments:

1. Conditional Close

When the user attempts to quit, a request would be sent to the server, as
a hangup signal. If this signal was trapped on the server, nothing would
happen (or the user could be informed). If the hangup was processed on the
server, the socket connection would close, and Anzio would react to that
by quitting. (Actually this might be doable without modifying the SSH).

2. Reconnect

If this feature were enabled, upon quitting in Anzio the server-based
session would remain open. When the same user (or machine? or IP address?
or MAC?) reconnected, they would be plugged back in to the same session,
and the screen would be refreshed. This could be especially handy if a
wireless user moved out of range and then back into range. It might be
possible to use 'screen' for this now - I haven't experimented that far.

I'm always interested in more suggestions.

Regards,
....Bob Rasmussen,   President,   Rasmussen Software, Inc.

personal e-mail: ras at anzio.com
 company e-mail: rsi at anzio.com
          voice: (US) 503-624-0360 (9:00-6:00 Pacific Time)
            fax: (US) 503-624-0760
            web: http://www.anzio.com