My original posting:
I would like to find out if there is a software only solution (perhaps by kernel
patch) to setting up a pair of Sparcstation 10 systems (running SunOS 4.1.3)
with only one of the systems having keyboard, monitor and external devices.
The systems are to be connected together ONLY via ethernet in a simple two node
network at each site.
This is for a turnkey system to be installed at customer sites to their
specification (which requires the single keyboard/monitor). The software runs
under OpenWindows on the monitor, so a recent posting which mentioned using a
single ASCII terminal as a console switched between systems is inadequate here.
The systems are as follows:
(Primary) Sparc 10 with CD Rom, external disks, tape, monitor, and keyboard.
|
ethernet |
|
(Secondary) Sparc 10 with internal disk but NO external devices, keyboard or
monitor.
(Note that both systems are otherwise fully standalone, with the secondary
having a full O/S install).
There is a fairly simple solution that we are aware of that consists of using a
serial line between the workstations (and redirecting the secondary systems
console to a terminal emulation program running on the primary). However, we
would like to avoid using a serial cable and route all console traffic via
ethernet, without losing the ability to reboot the primary or secondary systems,
when required.
We would also also like to be able to log all messages from the secondary's
console via the terminal emulation software on the primary (rather than rely on
syslog to do it). It may also be necessary to fully install replacement
secondary (or primary) systems from the CD Rom and tape drive on the primary.
--------------------------------------------------------------------------------
Summary:
Problems:
Booting a system which has only an ethernet connection, no keyboard or
console terminal is a problem in that just using an rlogin will permit the
command to be given to the system, but no output from it can be received.
Only when the system is back up and running can a new rlogin be made and
contact re-established. Alternatively X can be used to run the console locally,
by setting up a cmdtool -C to run automatically after boot.
Further, plugging an ASCII terminal, or a serial line from a Sun, into a tty
port that is set up to be the console will cause that system to reboot, which
prevents the examination of the current system state.
Solutions:
These came into three categories:
a) those which required extra hardware. These were attempting to access the
console i/o all the time, even during booting. This also permits installation.
Mike Raffety and Perry Hutchison suggested a using a switched keyboard & screen,
or terminal.
Pat Cain made a slightly different suggestion of setting ttya as console,
connecting ttya to ttyb on the secondary, and then writing some kind of program
to force all i/o on ttyb to a pseudo-tty on the primary system.
Andrew Benson's idea was more suitable for a setup with more than one secondary
system, in that he suggested using a terminal server (perhaps on ethernet, or
directly on another system) to connect to ttya on each machine.
Glenn Satchell specified, more precisely, the original solution from my question
of using a serial line between the systems and running tip as terminal emulator
on the first. This included one possible setup for the 1st systems /etc/remote:
console|second:\
:dv=/dev/ttyb:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
b) those who addressed the problem of capturing the console output.
These ranged from using an xterm -C to log to a file, to special X programs
called contool (suggested by Chris Dale) and conserver (suggested by Elmar
Kurgpold). The two latter programs provide greater control over the levels of
logging of data and provide a range of ways of alerting an operator to problems
on the systems that they monitor. Both should be available from local archie
sites.
c) those who addressed the problem of booting a system with no keyboard while
not making ttya or ttyb default (unused) console lines.
This contribution came from Hal Stern, and rather than compromise its content
by describing it, here it is complete:
> Here is a patch that can be added to NVRAMRC on any version 2.x PROM.
> It directs console input and out to the proverbial bit bucket.
>
> cd /
> new-device
> " nulltty" xdrstring " name" attribute
> : open true ;
> : close ;
> : read 2drop -2 ;
> : write nip ;
> : install-abort ;
> : remove-abort ;
> finish-device
> device-end
>
> That patch creates a null device. To select that device, execute
> the following at the "ok " openboot prom prompt:
>
> setenv input-device /nulltty
> setenv output-device /nulltty
> reset
>
> To recover control of the console, plug in a keyboard and power up with
> the L1 and N keys held down. This is the usual "reset the NVRAM contents"
> sequence as described in the Open Boot manual.
>
> To test this patch without "committing" the NVRAM i/o device selection,
> type:
>
> " /nulltty" io boot
>
> That must all be on the same line, because after the line is executed,
> you lose the keyboard!
>
> If you want to load the patch from the command line, you can
> use the eeprom() interface to the open boot prom to write
> the device definition and console settings into the nvramrc.
> be sure to load the nvramrc contents and set "use-nvramrc?" to "true"
He also mentioned the use of the TIOCCONS ioctl on a login to the 2nd system
to grab all the console messages once it is up.
Indeed this method seems to be the basis of operation of all of the software
solutions: cmdtool/xterm -C, contool and conserver.
--------------------------------------------------------------------------------
Conclusion:
Running a console over ethernet is always a compromise between the convenience
of a single wire solution and the potential problems that might result from
not being able to access the PROM level for booting, reconfiguration and
reinstallation.
Clearly this greatly reduces the level of control available so using the serial
line would be preferable, were it an option, and an ethernet terminal server
approach would be better in a configuration with more than one secondary system.
However, after evaluating the contributions we will probably go with Hal Stern's
open boot prom code plus contool or our own software using ioctl. We might also
provide our installers with an ASCII terminal while they set up the system at
the customer sites.
--------------------------------------------------------------------------------
Last but not least, my thanks to those who responded:
Andrew Benson <drew@mtu.edu>
Pat Cain <pjc@denver.ssds.COM>
Chris Dale <ccd@frey.newcastle.edu.au>
Perry Hutchison <perry@pluto.rain.com>
Elmar Kurgpold <ekurgpol@Law.USC.EDU>
Mike Raffety <miker@il.us.swissbank.com>
Glenn Satchell <glenn@uniq.com.au>
Hal Stern <stern@sunne.East.Sun.COM>
plus anyone else whose info I missed, or who might reply in the future.
-- alan@ssu.stc.co.uk <Alan.Logue@ssu.stc.co.uk> STC Submarine Systems, Stevenage, UK Telephone: +44 438 738198, Fax: +44 438 738187
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:24 CDT