[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Need "console switch" - any ideas?
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).
This looks like fun :). I think I'd prefer cyclades over what we have.
We do something similar with xlogics terminal servers, which have their own
view of how rs232 works, and a package similar to rtty. Multiple people can be
on the terminal at one time, which is usually annoying and everything gets
logged. It works really well. I do everything but powerdown/up remotely.
Reboots and even machine checks for memory errors don't require anything but
an internal network connection.
While we don't have am many probs with the Suns as described below, they do
have some display probs over a serial terminal at the f/w level.
I use a cybex kvm for my "personal" boxes in my cube. It's been working quite
well for me, but I don't put it to too much stress. Only x86 linux, ppc linux
and aix.
ciao,
der.hans
> 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
>
>
>
>
# +++++++++++=================================+++++++++++ #
# LuftHans@asu.edu #
# http://home.pages.de/~lufthans/ #
# Practice socially consious hedonism, #
# do whatever you want as long as it doesn't #
# hurt anyone else. - der.hans #
# ===========+++++++++++++++++++++++++++++++++=========== #