Subject: Re: Off-Topic: Terminal Server
To: None <current-users@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 10/16/2000 13:54:32
[ On Monday, October 16, 2000 at 11:59:42 (+0200), Feico Dillema wrote: ]
> Subject: Off-Topic: Terminal Server
>
> A bit off-topic, but hope you can help me with this one too. Do you
> know of a `terminal server' program (console or X) that I could use to
> easily connect to dozens of serial ports? Somethign a bit less spartan
> than using minicom or kermit. Basically a frontend to such would do
> just fine, if it supports selecting a serial port by a human-readable
> name and connect to it with the proper settings. Any hints? Browsing
> pkgsrc and freshmeat didn't give me much result sofar...

I'm not a big fan of rtty myself....

I've used a script to start a detached "screen" session running "cu" for
each port and then from the operator's ~/.xsession I start an xterm that
attches to each "screen" session.  That worked rather well and with
careful control I could usually even group related machines into
different window manager workspaces (you could also simply have one
"screen" session with many virtual sessions controlling all the
processes at the same time too).  This was what I used when I had a Unix
box with lots of serial ports acting as a console terminal server (and
the operator X session ran on its console -- i.e. it was the NOC server
and workstation all in one).  For remote access you just SIGHUP the
current owner of the current "screen" session and attach to it again
from your remote session.  If you run the NOC's "screen" session in a
little loop it'll reattach again once the remote user is done and all
will be well.  "Screen" of course can keep a scrollback buffer so you
can review old output again after you attach to it.

However with a real terminal server (i.e. one that supports reverse
telnet to the serial ports), I've found it's not worth the hassle of
using "screen" (since you don't have to use "cu" or "kermit" or
anything) and instead I just telnet to the terminal server from wherever
I'm authorised to do so[1].  I generally start a bunch of xterms with
the appropriate telnet commands running in them on the NOC workstation
(still from the operator's ~/.xsession of course).  If I need remote
access I have to kill the given telnet client, either from the server
where it's running, or by hanging it up from the terminal server's
command-line and the telnet to the terminal server port directly, but
that's pretty easy to do.  The only drawback of this scheme is that
unless the terminal server has its own scroll-back buffer you can't
review previous output without using the original NOC xterm session.
(There are true console terminal servers that have built-in scroll-back
buffers to avoid this problem.)

There's another X program somewhere that makes simultaneous command
entry on multiple sessions possible....  I can't remember it's name
right at the moment.

	[1] Normally at each site where I've set up multiple servers
	with serial consoles I've put the terminal server on a private
	administrative network and so I don't have to worry too much
	about people sniffing root passwords or attacking the terminal
	server itself since I can SSH into the administrative server(s)
	and then telnet to the terminal server.  A terminal server that
	supported SSH directly might alleviate this problem a bit.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>