centralizing consoles
2007-12-25 7:54:00
Thanks to :
Jeremy Olsen <jmho@cogsci.edinburgh.ac.uk>
Gary Blumenstein <garyb@gcm.com>
Curt Freeland <curt@ecn.purdue.edu>
"Lawrence R. Rogers" <lrr@Princeton.EDU>
"Donald A. MacLeod" <dmacleod@mailbox.syr.edu>
Mike Raffety <miker@sbcoc.com>
steve@ibx.com (Steve Giuliano)
mitch@cirrus.com (Mitch Wright)
pmetzger@shearson.com (Perry E. Metzger)
ups!kevin@fourx.aus.sun.com (Kevin Sheehan {Consulting Poster Child})
jeff@auratek.com (Jeff Martin)
dasun!wdceng!muir@sunkist.west.sun.com (Scott Muir (Muir) x6764)
arnold@synopsys.com (Arnold de Leon)
jkays@msc.edu (Jeffrey Kays)
poffen@sj.ate.slb.com (Russ Poffenberger)
valencia@auratek.com (Stephen T. Valencia)
kms@sunrise.east.sun.com (Kevin M. Samuels (Sun NE Area Professional Services))
My original inquiry :
>
>I am interested in centralizing the consoles of sun4m and sun4c systems.
>I would prefer to do this via a terminal server (i.e. xylogics) but would
>consider the SBus async multiplexors (e.g aurora).
>
>I am sure some of you folks have wrestled with this and I am interested in
>your input/experience. Specifically, will this work ? Is there a kludge to
>bypass the monitor trap (i.e. losing DTR or whatever signal accounts for this
>behavior) ? Will it work with lunch boxes as well as refrigerator,
>microwave, & pizza size containers ?
>
Presently, there seems to be several ways to centralize the consoles of
Sun systems. This can be done with hardware and/or software. It will
provide consolidation as well as remote access. Before I begin, I would
like to digress on the console itself first. The following is a summary
of: the email replies, TFM, Hal Stern's May 1992 SunWorld article, the Field
Engineers Handbook, and the AMD Data Book (haven't looked at one of these
in years !). Its probably more than you want to know but here goes ....
Notes on Sun console ports
--------------------------
The boot PROM monitor reads the NVRAM to determine the system console
(i.e. input-device & output-device). By default these are a keyboard/video
interface. However, if the monitor detects the absence of these devices
it *automagically* sets the system console to ttya.
The zs device driver is responsible for the ttya interface but note that it
actually uses the monitor driver to display output to the system console rather
than a kernel resident subroutine.
Both serial ports are controlled by a Zilog 8530 Serial Communications
Controller (SCC) or clone chip. The SCC generates interrupts when the receiver
logic, tied to pin 3 (RxDA), detects the start/end of a received BREAK signal.
Note that when the line is idle the signal is all one's (high voltage) - also
referred to as MARK or MARKING LINE. A BREAK signal is all zero's (low voltage),
nominally 1 null character, as opposed to the continuous stream of 1's when idle.
When BREAK interrupts are seen, the zs driver traps to the monitor suspending
all system execution. This is appropriate when the BREAK signal is software
generated via the break key (L1A works a little different) because this is
necessary to restart a hung system. On older Sun systems, a BREAK condition is
**interpreted** when the line goes open (e.g. pulled cable or power-down of
terminal) since no-voltage looks like low voltage to the SCC. In some sense, its
still appropriate to trap to the monitor to avoid filling the kernel serial line
buffers ( ~ 1 MB capacity) which would eventually hang the system. However,
this creates inadvertent system halts and inhibits the centralization of
consoles (besides it would take a little while to overflow the buffers).
I know that the latter condition does not occur on SPARC 2's and MP systems
because I have tested them. It does occur on 4/4x0 machines as well as older
SPARCstations. It is possible to trick these machines by providing a trickle
current on the RxDA which can be derived from strapping a 4.7 K ohm resistor
across pin 25 and pin 3 (so called pull-up resistor). Software BREAK will still
work but ttya can be left wide open and the system will hum along.
It is assumed that this modified connector WILL BE attached to the required
systems ONLY. This will allow the "async concentrator" in any of the solutions
to be disabled (e.g. power down/reboot) and not necessarily affect the other
systems.
NOTE: IPC/IPX do not have the -5 V reference signal and so this cannot be used.
Its unclear whether they have the "fix" like the SPARC 2/MP systems.
NOTE: there is a Sun Consulting special (REMOTE-CONSOLE) to *BRANCH* the console
to the serial port even when the keyboard/frame buffer are active. This
might be useful for certain systems (especially IPC/IPX).
Solutions
---------
There are basically 4 flavors of H/W async concentration : patch panel, terminal
server using ethernet, ALM using VME, or 3rd party device using Sbus/SCSI (e.g.
Aurora/Central Data). There is one X-based software solution.
Patch Panel
-----------
This works fine if you have your servers in one building or you use line drivers
to get to somewhere else. Basically, you patch the ttya's from all servers to the
panel and then you just plug in a dumb terminal to the particular system your
interested in.
Terminal Server
-----------------
With a terminal server (TS) (e.g. Annex from Xylogics), you simply telnet,
select the port/console you want, and BINGO you're in there. The TS port
configuration is fairly straight forward (it uses mnemonics rather than wierd
codes and symbols), it can usually be managed with SNMP, and it provides passwd
security to prevent "any old user" from doing harm. All necessary software comes
with the TS. Several people have been using this for as long as 2 1/2 years.
ALM
---
The so-called console server or ALM solution is very similar but requires
changes to system files that are slightly arcane and would **probably** have
to be restored upon SunOS upgrade. This also requires the use of dedicated tip
sessions to all of the consoles. The console-server package is a fairly good
interface built on the client/server model allowing you to remotely tap the
real concentrator/server system. It is available from tut.cis.ohio-state.edu
via anonymnous ftp. There seems to be several people doing this successfully -
including Sun. I believe that the csw package available from
harbor.ecn.purdue.edu will also do the job of handling all the tip sessions.
But, there was no README (tsk, tsk) in the archive and I haven't had time to
look at the code !
SBus/SCSI
---------
The SBus solution is very similar to the ALM solution but is not available
from Sun and requires the normal driver installation, etc.. I don't
know anyone using this. Also, note that SBus slots are at a premium since
we use HSI, Ether/SCSI, FDDI, TRI, FAX, parallel port, & prestoserve all over
the place.
The SCSI solution is also similar with a twist. Since this device sits on the
SCSI bus it can be moved around easily or attached to non-SBus slot systems
(e.g. SLC/ELC or sun4). Only one respondent is doing this.
Using X
-------
By using "xterm -C" OR "contool" (xview version) you can use any X device
to provide an X based solution. One disadvantage of this approach is reboot
messages have nowhere to go and single user operation still requires the use
of a dumb terminal that could be temporary/shared. Another disadvantage is
limited remote capability (i.e. have to be at the X device - can't dial in
from home, etc..) However, this is a resource that most folks can scrounge
up fairly quickly !
What I am planning to do here is use a hybrid approach which should be
pretty slick.
1) In a sort of heads up display fashion, I will use a sizable X-terminal
to capture the output of a contool running on all servers and started
by default. Note I will be using contool in the "read-only" mode (i.e -n
option) since, apparently, SunOS will *ONLY* allow a single process to
control the console. This will provide a status monitoring function to
the masses and a visual logging facility.
2) I'll be using a patch panel to connect the servers - although you could just
as easily use a bank of garden variety (e.g. BlackBox) async fan-out boxes.
Each panel bank will have a master port connected to ttya of every server.
3) There will be 3 remaining ports. 1 port will go to a Xylogics Annex 3
terminal server to allow remote access between floors/wings/home via telnet.
The fact that the older servers are strapped will allow for terminal server
disruptions stemming from power loss, reset, extended diagnostics on other
ports (e.g. modem lines), etc..
4) The other 2 ports will be available for on-the-fly patching of a dumb terminal.
There will be 2 of these sitting in between all the beasties.
5) At some point later on, I can add other connections (e.g new servers, routers,
concentrators) with little effort.
I think this will provide a fair amount of availability and flexibility and
at the same time save me some mileage on my legs and my car !!
Chris
-------------------------------------------------------------------------------
Christian A. Lawrence Real mail : cal@soac.bellcore.com
Bell Communications Research Fake mail : bellcore!pandora!cal
444 Hoes Lane, RRC 1J-322 Voicemail : 908-699-3909
Piscataway, N.J. 08854 FACSimile : 908-699-9091
Comments
Got something to say?
You must be logged in to post a comment.
