Well, you've heard it before ..... the list comes thru again !
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))
was@gdwb.oz.au
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
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:49 CDT