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
emike@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.