Re: Serial console setup

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Fri, 23 Dec 2016, Greg Troxel wrote:
> You are not really wrong in theory.

Heh, whew.

> There, getty waiting for open to succeed until CD was asserted made 
> sense, especially when the modem/line was shared with outgoing UUCP.

Oh, I get what you are saying. Even back in the day I rarely put the 
console on a modem. Rather, as in my case, we'd just setup a "secure" 
getty on the modem (usually with mgetty, if possible since it tended to 
handle modems quite well). The only time I'd stick a modem on the console 
was when I had to ship machines to IT deserts in BFE and I had tested the 
snot outta the rig and had scripts in place to periodically poke-or-reset 
the modem, as needed.

I also wouldn't accept anything less than a top-of-the-line US Robotics 
Courier because rarely did other vendors meet their level of quality and 
speed. I had Zoom and Atmel modems that could never be relied upon if they 
were left to sit for too long with no calls/reset. I'd have never trusted 
those on a must-be-available-or-I'm-screwed-800-miles-away-console port.

> A modem console would be beyond bizarre these days.

Heh, very true, but as strange as it is, I've seen it now and again even 
to this day. The main place is on EMC storage arrays where they take 
incoming calls from support to do things like system checks and firmware 
updates. They tend to get a lot less hassle from security folks for 
whatever reason. I haven't seen it on the newer VMAX chassis, but the 
older Symmetrix "DMX" line used modems quite a bit and people still use 
them. There is an outfit on the East coast that still maintains them via 
dial-in, too. Of course, it's not exactly the same thing because I think 
those machines they are either DOS or Windows machines running some kind 
or remote access package (ie.. not gettys). I've also run into 
refrigeration controllers and digital signage systems that also still run 
on modems, but again these are embedded devices, not Unix boxen.

> My point was really that if the cables are not wired up right and DCD 
> ends up not asserted (there are a lot of wrong serial cables out there), 
> then it seems better to just have the console work, rather than not 
> work.

I get it now, and I get why you said it and it makes good sense. Ie.. In 
this case, folks can debate which pins to set high or not, but "working" 
is considerably more comfortable than "broken" no matter what "standard" 
is getting violated or who thinks that's not the ideal wiring scheme. 
Right on. :-)

Thanks for explaining.

-Swift