Disabling Quit On Telnet

[Fairlight]

Is it just me, or did Scott Walker say:
> 
> How do we prevent this?  Facetterm term has a great feature that you
> could turn on at the server in the .facet file (something like
> Disable_Quit_While _Windows_Active) to prevent the user from exiting
> while some program was running underneath Facetterm.
> 
> Anzi has this feature to disable the Quit:
> 
> To see this feature:
> 
> 	Edit
> 	  Advanced Options
> 	    Security
> 	       Check Disable Quit Box
> 
> This does the job great.  The problems with it are:
> 
> 	1.  Since it is set at the workstation level I am counting on
> whoever installs Anzio to set it.
> 
> 	2.  I'm counting on the fact the the user will not change it.
> 
> I don't have a high degree of confidence in both 1 & 2 above.
> 
> I really need something that is setup/configured at the server so I can
> do it from my remote location one time and users can't get at it.
> 
> How about it....how is this best handled.  What do you guys do at your
> installations?

A couple suggestions...one for Bob at Anzio, two for Scott.

1) The handling of the "X" button event is only really possible to do at
the client level.  That isn't anything Scott will be able to do without the
vendor changing the client.  However, I know for a fact that you can tell
the Windows wm not to draw those three buttons -at all-.  If that were
done, there's no way to click on them, obviously.  A feature you might
consider from even an aesthetic standpoint--why have decorations there that
are rendered unusable anyway?

2) Regarding installation, that's not something I can address.  That comes
down to training, pure and simple.  Regarding changes, however, the answer
to me seems obvious:  Install Anzio and configure it as an administrator,
and make sure your users are running as -users- rather than as
administrator.  Assuming that the multiuser permissions in 2000, XP, and
2003 are as far improved as I was led to believe, you should be able to
make that config file unchangeable by the user.  Actually, they might be
able to change it on the fly--unless Anzio takes steps to give an option
that forbids any configuration changes--which would also reside in the
protected config file.

3) My best answer for server-side is to use screen(1).  You didn't specify
your server environment, and I'm not sure anyone ever ported it to SCO.  If
you're on Solaris, Linux, or FBSD, you're in luck.  The screen application
will actually detect a disconnect and keep everything running--then let you
reattach later.  Something could be pretty easily cobbled together to allow
testing for the presence of a socket and auto-resume at login, assuming one
is only logging in one window at a time.  One would actually only -need- to
do so if one used screen, as it's a multiplexer and lets you have pretty
much unlimited (more than even I use, and my default is 10 screens--8 as
fairlite, 2 as root, and I can still go far higher).

The only thing I know that lets you pick up where you left off on any kind
of accidental hangup is screen with autodetach set to on.  It's been 8-bit
clean for years now, although you'll have to change termcaps to accomodate
function and special keys.  The program basically makes -any- terminal into
a vt100.  So you're using an adm4, a pl3+, a z49, or a software emulator
running wyse60 mode--all of them act like a vt100 whenever you're in
screen.  It does the translation internally.  So you'd need the right
termcap setups.

I use this a lot though.  I detach from remote and reattach, for example.
You can be logged in at work and doing something, realise you needed to
finish, log in from home with an entirely different terminal emulation, and
pick up right where you left off--it will let you detach the original
terminal (optionally logging it off), and reattach the session to your
current terminal.  Boom.  Instantly I have IRC, instant messaging, 3
screens of coding, and several other things all right on my current
terminal at my current location--as if I were still at the first location.
The programs keep running, so conversations in IRC will have progressed,
etc.  It does NOT suspend the processes.  For you, this means that any
files or records filePro had locked because something was sitting on them
will stay that way until the session is resumed and closed out properly (or
until someone kills it with kill(1), of course).

I've used fP under screen before.  Just not reaaaaally extensively.  Mostly
I use it on the linux box here.  I log into that and constantly have it
running.  If I log into remote servers, even...Bob Stockler lets me use fP
on his system sometimes to test things, and I used that from inside screen.
So yes, it works.  Actually, that's a filePro <-> SCO 5.6 <-> screen <->
linux <-> PuTTY on Win2k solution I'm using in that particular scenario. :)
And I can still pick up and leave off anywhere I like, assuming the
emulator is powerful enough to handle colour and line drawing if I have
them on (I do...full colour and graphics in fP, on SCO, going through those
layers, to PuTTY).

The nice thing is, it protects you from just about anything.  The power
could go out and the UPS could shut down your computer--you could still
reattach.  It doesn't matter -why- you were detached, you can reattach.

You could look into it...  ftp.gnu.org.  It's free.  Always has been.

mark->