As usual, thanks for the fast and informative replies. This list
remains the most useful of the many I subscribe to. I received about 25
replies in approx 6 hours.
Regards,
Joel Spieth
RPM Consulting
www.rpm.com
ORIGINAL:
Dear Sun Gurus,
We are preparing to move from a desktop environment to a rack
environment to save space. We have some Sparc 5s, 20s, and U2s. We will be
purchasing U10s, E250s, and E450s. To access these systems, we will use
the standard network connectivity and we plan on implementing Cisco 3640s
(96 ports) for terminal/console access. Has anyone done this before? Is
this a mistake? Are there any gotchas?
I recently heard a nightmare that some of the older Sun hardware would
crash to the Open Boot PROM if a terminal server died? Is this still a
concern? How can I avoid it?
Is it possible to design redundant terminal server access, or do you
have to dedicate a tty to the console?
Does anyone have any advice on other terminal servers?
Does anyone have any design advice regarding terminal server access?
RESPONSES:
Recommendations for terminal servers-----------------------------
*Many* people recommended the Bay (Xylogics) Annex series terminal
servers. Some people recommended KVMs of one kind or another, but I didn't
list those posts here since I was really looking for remote terminal server
(console) access.
--- >I personally have had wonderful luck with the Magma devices >(www.magma.com). At my last place, we used a 16port version of their >product. Here we've been using their 64 port Maxport 64 device and have >been very happy with it. --- >We are using SCSI 16-port terminal servers from Central Data, and they >seem to work quite well with the cable setup shown above. --- >I used a xylogic/bay network 72 port 600 series. easy. Pinout of the >actual connector is very critical. don't but those *octopus* telco >connector to rj-45 cables >unless you know that the source is good (lots of them will fail ). >Discussion of redundant terminal server configuration-------------
Not possible since the console only binds to a single tty. You can connect two terminal servers, but the second one would only provide standard tty access rather than console access.
Discussion of BREAK/DTR/CRASH to OBP Problem & Design Issues-----
I didn't receive any information for large installations. Many people seem to be using small terminal servers with 8 or 16 ports and seem satisfied. Some folks are using Linux systems as terminal servers. Cisco has a url that discusses the break problem at http://www.cisco.com/warp/public/770/fn-tsbreak.html
--- > If a BRK gets asserted on the tty line that is the console (by default >ttya), it is the equivelent of an L1-A. There is a way to turn it off, but >I don't remember it off the top of my head. As far as redundant access, >I'm not sure I understand what you are asking. The console can only be >assigned to one port, so you couldn't have one terminal server attached to >ttya and another attached to ttyb and be able to do "console stuff" on both >terminal servers. The other port would be just another user terminal. >Consoles can also be used as a user terminal, but the BRK concern remains. --- >Effectively, with our Terminal Servers (Digital Decserver 300 or 700) >connected like remote console, the system hang (like a STOP-A) when you >switch-it off (it sends a XOFFsignal, I think). For avoiding that, on >our high avalibity Sun, we have some Annex terminal servers, from >Xylogics: the machine do not hang when we cut-off the terminal server. >Unfortunately, with the Annex, we cannot use Polycenter Console Manager, >because we use LAT on the VMS machine. We are obliged to access the >terminal server port with a telnet: not very nice, especially because we >don't have logging facilities. > >We use Polyconsole Center Management (from DEC), implemented on VMS >machines, to access our Sun servers consoles (about 40 servers, SS5 to >E4000). If yo find another solution, I'm very interresting ... --- >ANY Sun machine will drop to the PROM monitor when using a serial console >if it sees a "break" signal, or if DTR goes low. Many serial >communications packages will drop DTR when the program terminates, or the >other end of the link is powered down. You can avoid the DTR problem by >using cables that only pass the data signals and ground, as in this >pinout: > > > 3 ------------------------------------- 2 > 2 ------------------------------------- 3 > 7 ------------------------------------- 7 > > > 4 --v v-- 4 > 5 --^ ^-- 5 > > > 20 --v v-- 20 > 6 --+ +-- 6 > 8 --^ ^-- 8 > >TD transmit Data (DB-25 connector) Pin 2 >RD received data 3 >SG signal ground 7 >RTS request to send 4 >CTS clear to send 5 >DTR data terminal ready 20 >DSR data set ready 6 >CD carrier detect 8 >RI ring indicator 22 (not used here) > >Since we're talking one box that can access lots of machines which are >presumably critical to your operations, I'd say that access should be >pretty limited. Our approach here is that the IPX operating as the >console server is not connected to the network at all. Granted, there is >some small fraction of the time it would be useful to be able to access >the console of an uncooperative machine from home, but the risk of >somebody hacking into such access makes this inconvenience a reasonable >tradeoff. --- >All of the Sun's are very sensitive to the DTR pin on the console >port. For example, if you connect a vt100 terminal to the Sun and >then power off the vt100, the Sun machine will halt. There are lots of >multi-console products out there, but using these devices does have >the potential to halt all the machines if a problem occurs with the >console server (which could create huge production issues). We have >a few console servers, but the vast majority of our machines have no >connected consoles. We manage all the machines through the network and >physically connect a floating Wyse terminal with 50 foot cable to the >machine on the very rare occasions where direct console access is >needed. This is a low-tech approach, but it is effective and eliminates >the issues with the DTR. I very strongly recommend that, as >you are evaluating console servers, you power the console server device >and verify that it does not halt the connected machines. I think that >you can make special cables (or remove the pin from the DB-25 connector) >that eliminate DTR to eliminate potential for the problem (I have not >test this so you will need to expiriment). > --- >I do it with Xylogics Annex III (Bay networks) and it works great >Investigate the cable types modem vs null modem if the terminal server >has options so you have a neat installation. > >I do this to the eeprom so if I disconnect from the console, >it logs off > >echo >echo "If this is a server and is going to use /dev/ttya for the console" >echo "do the following" >echo >/usr/sbin/eeprom ttya-rts-dtr-off=false >/usr/sbin/eeprom ttya-ignore-cd=false >/usr/sbin/pmadm -p zsmon -r -s ttya --- >Make sure you disable the EEPROM variable that recognizes DTR on ttya. >That is the only gotcha. Also, on SS1000 systems there is a keylock on the >front panel, and if it is in the lock position you cannot use the DTR to >break to OK on the console. --- > The problem relates to receiving a "break" signal from the terminal >server or terminal concentrator. > >The first step is to put the system key into the "lock" position. This >will cause the system to ignore any and all keyboard break signals. When >operator intervention is really desired the key may be repositioned to >allow the break signal to return the system to the OBP. When finished, >return the key to >the "lock" position. > >With Solaris 2.6, you can also disable the keyboard aborts by changing >settings in /etc/default/kbd > > %kbd -a enable|disable > /etc/default/kdb > KBD_ABORT=enable|disable > >Smaller systems without key locks and running prior releases of Solaris >operating system require a modified serial line driver [available from Sun >Consulting].
_____________________________________________________________________ RPM Consulting - A Network Solutions Subsidiary of Computer Horizons Joel D. Spieth http://www.computerhorizons.com Network Management Consultant http://www.rpm.com jspieth@rpm.com V: 800-776-0073 _____________________________________________________________________
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:46 CDT