demasi@paisano.UUCP (Michael C. De Masi) (01/08/88)
Hello People,
Well, I guess it's been a while since I started a major
argument on the net, so here goes!
We're running a variety of 3b2/310, 400 & 600 computers
in an area which is already too small to accomodate the one
dedicated console per machine which is necessary for system
messages, etc. We will probably soon be expanding the area,
but that doesn't help much now. We do, however, have an
abundance of ports cards on several of the machines. The
logical solution, it would seem, would be to have the machines
monitor each others' consoles, in some sort of a hierarchical
fashion. Eg, plug the console from one machine into one of
the regular terminal ports of another machine in much the
same way one does when direct connecting two machines for
uucp transfer.
Of course, in order to do this, the port on the monitoring
machine must be conditioned in a special way, so as to get
it to accept the incoming data from the monitored machine
in an unconditional fashion, without returning to it an
endless series of "Login: Passwd:" prompts. It would also
be nice to have the monitoring machine redirect the output
from the monitored machine to a file somewhere, so that
important console messages won't simply be lost.
Now, I'm sure that there are some slick packages somewhere
that will do this for us nicely, but I can't help but think
that the same effect must be possible through some fairly
simple combination of stty, init and redirection commands.
Anybody know how? I've been playing with it for some time
now, but I just can't seem hit the right combination.
Thanks in advance for any help,
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
UUCP: decuac!grebyn!paisano!demasi
"Cigarette?" "Yes, I know" - Detective Frank Drebyn & Suspectgwyn@brl-smoke.ARPA (Doug Gwyn ) (01/08/88)
In article <301@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes: >We're running a variety of 3b2/310, 400 & 600 computers >in an area which is already too small to accomodate the one >dedicated console per machine which is necessary for system >messages, etc. Consider using one model 630 MTG terminal per two 3B2 computers. You can monitor one console in each of two windows (layers). The 630 is worth having for other reasons, too.
paddock@mybest.UUCP (Steve Paddock) (01/09/88)
In article <301@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes: >We're running a variety of 3b2/310, 400 & 600 computers >in an area which is already too small to accomodate the one >dedicated console per machine which is necessary for system >messages, etc. One alternative I am fond of, and which requires no fancy hot-wiring, is to configure a serial printer onto the console port. This will let you take the 3b2 up and down, give you a log, and unless you get console messages in the middle of a print job, cause no problems for the printer. As an added security feature, the lack of a keyboard forces users to use su, and make the sulog, to use root permissions. Of course, if you don't run a serial printer this doesn't help you... Steve -- Steve Paddock (ut-emx!mybest!paddock) 512-477-9736 Best Printing Co, Austin, Texas 78767
ninja@bradley.UUCP (01/10/88)
The idea of not having a console nearby (either physically or electronically)
sounds unsafe/unwise to me. Say, one of your machines crashes, then
one more electronically "distant" machine decides to really go out to
lunch, throws some panics out the console and they are lost forever because
the machine that crashed first still isn't back up yet ("Pick those
bits up off the floor !!!" (:-).
What I would suggest is, find some cheap AT clone somewhere. Pack it
with serial ports. Run unix on it, preferably one with CSH and TIP.
If you don't have or can't get tip, cu should work okay too.
Connect the console of each of your 3B2's to one of these serial ports.
Run tip on each line, and use the job control features of csh to switch
from console to console. I've seen ports boards for AT's that have
8 serial ports; I don't know what the physical limit is for one (I think
it's 32). Anyway, I think that's a much better solution than
daisy-chaining your consoles. The other possibility would be to
dedicate one of your 3B's to do the same thing. If you want "hard" logs,
(good idea) you could hack tip/cu on that machine to log them to the printer
and a file for each console. There's a possibility you could get around
the hacking by using pipes and 'tee' but I don't know if that would work.
Good luck,
Frank McGeeemike@richp1.UUCP (E. Mike Durbin) (01/13/88)
In article <301@paisano.UUCP> demasi@paisano.UUCP (Michael C. De Masi) writes:
->>We're running a variety of 3b2/310, 400 & 600 computers
->>in an area which is already too small to accomodate the one
->>dedicated console per machine which is necessary for system
->>messages, etc.
One 3b2 running Windowing Utilities (layers) and a 630 terminal
connected to both "console" and "contty" (the 630 can connect to
two hosts) can simultainiously monitor to 14 consoles (7 windows
per host, 2 hosts).
You might have to run your consoles going into the 3B2 at 4800 baud
if the 3B2 has problems keeping up.
Real rough: turn off gettys on all serial ports connected to
remote consoles (in /etc/inittab)
Create two layersys files that open each opens 7 windows.
An example entry in layersys would be:
x1 y1 x2 y2 cu hostN
Set up your Systems file to know about all 14 hosts.
On /dev/console, run "layers -f layersys1", on /dev/contty
run "layers -f layersys2".
WARNING: I don't have a 3b2 or a 630 terminal to check out the above
claim, but the general idea should work. One terminal monitoring 14
machines!
--
------------------------------------------------------------------------------
...!cuuxb \ E. M. Durbin
...!purdue >!richp1!emike Rich Inc.
...!ihnp4 / Chicagotgr@picuxa.UUCP (Dr. Emilio Lizardo) (01/14/88)
In all of this discussion about using one machine (3B, PC or whatever) to monitor the console ports of multiple 3Bs, I see something missing: the problem of a remoted console when the machine being monitored goes down. When a 3B2 boots/shuts down (possibly for any change of init state, but I'm not sure of that), the console port *deliberately* drops DTR. This is to ensure that you have a locally attached console terminal, not a modem (which will hang up the call when it perceives loss of DTR). A 3B2 ports card will also drop the connection unless you do something with the stty, so just hooking up a 630 to a 3B2 to monitor other 3B2s will not work; some effort will be involved. If $$ are available, I suggest the original poster look into buying the 3B2 Remote Management Package, which includes an Alarm Interface Card (AIC). This board provides the capability to remotely access the console port of any 3B by trapping loss of DTR. Additional features include the ability to monitor the 3B for panics/crashes with other computer alarm devices available from assorted vendors, "panic auto-reboot" capability, and support for UPS. Use an alarm device (the one I've seen used is called "Silent Knight" but that's not to be construed as a recommendation) to monitor the machines for crashes, and use a single terminal with a ABC switch to connect to the AIC console ports from a single terminal. Not only will you be able to monitor multiple 3Bs, but your monitoring capability will not be hampered when one of the machines crashes. -- Tom Gillespie ( ...ihnp4!picuxa!tgr) | (attmail!tgillespie) (201) 952-1178 AT&T/EDS Product Integration Center 299 Jefferson Rd. Parsippany NJ 07054 "Don't take life so serious ... it ain't nohow permanent." -- Walt Kelly
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/15/88)
In article <448@picuxa.UUCP> tgr@picuxa.UUCP (Dr. Emilio Lizardo) writes: >the console port *deliberately* drops DTR. So? You don't have to look at DTR. Hot-wire it always-on on the monitoring system.