Re: Need "console switch" - any ideas?

[Pat Lynch <lynch@rush.net>]

There was actually a presentation at the last USENIX technical conference
about how to use FreeBSD as a console server, while not particularly
challenging, its probably a good place to point people asking this very
question. I believe the person who presented the solution was Branford
Matheson, but don;t quote me on that.

(the use of "watch(8)" I remember was a big part of it, without the need
for Vixie's rtty)

___________________________________________________________________________

Pat Lynch						lynch@rush.net
Systems Administrator					Rush Networking

Remark made by Bertrand Meyer (inventor of the Eiffel language) at a
panel discussion at OOPSLA '89:

        "COBOL programmers are destined to code COBOL for the
         rest of their lives, and thereafter."

___________________________________________________________________________

On Thu, 14 Jan 1999, Jurgen Botz wrote:

> John Geletej wrote:
> > I find myself in need of a "box" that will allow several UNIX
> > workstations/servers to be controlled at a single
> > keyboard/mouse/monitor. My primary need is for SGI equipment, but I may
> > need to incorporate a couple of Sun SPARCStations into the mix as well.
> 
> My preferred way of doing this is to use a serial console server, as
> follows:
> 
> Stick a 32 or 64 port serial card into a PC (Cyclades makes good ones),
> run Linux or *BSD on the PC, and install Paul Vixie's excellent rtty
> package to serve up the serial ports (available from ftp.vix.com).
> 
> The advantage of this method over a "keyboard/monitor switch" is
> obviously that you can get at the serial console remotely.  The
> advantages of this method over a more simple terminal-server based
> solution are:
> 
> 1) More than one person can be connected to a console port at a time
> 
> 2) Not only can you remotely connect to console ports, but everything
>    that happens on them gets logged... this is a big one because not
>    infrequently when something unusual happens to a machine the only
>    information about it is written to the console, and can thus be lost
>    if not logged.
> 
> 3) You can make it very secure by allowing connections to the console
>    server only via Ssh.  By using Ssh's feature of tying a particular
>    command to a particular public key you can give out keys for specific
>    consoles to specific operators without giving them access to all
>    consoles.
> 
> 4) Since you can put several 64 port cards into a single PC (easily 3
>    or 4) you can manage a LOT of devices from a single console server
>    this way...
> 
> It's really a very good solution and can be used not only for workstations
> but also for routers, hubs, NetApp servers, etc., etc.
> 
> The only downside of using serial consoles with Suns is that Suns have
> the annoying habit of dropping into the ROM monitor when power to the
> console server is lost (they interpret this as a "break" condition).
> As best I can tell this is the case for any serial console hooked up
> to a Sun, even a dumb terminal.
> 
> The workaround is to never shut down the power to the console server
> (reboot is fine), and if you absolutely must, disconnect all the
> serial cables first.  Older Suns also sometimes drop into the monitor
> if you just disconnect the cable, but we've found that this can be
> prevented by putting a resistor across the right pins.  Actually one
> can prevent break conditions altogether by putting a resistor across a
> certain set of pins, but then you can't drop into the boot monitor
> anymore, so that's not desireable.  If anyone has an optimal solution
> to this problem, I'd love to hear it...
> 
> - Jürgen
> 
> 
>