Hi.
Well, the overwhelming consensus was to add a console server. Unfortunately, this is not an option for us. The end result will be to ensure that the laptop and hyperterminal software is fully up and running prior to cabling it to the Ultra 60. Tests here so far have shown this to not send the dreaded brak signal. Powercycling the laptop will send it, however. At this point, we will take our chances and leave well enough alone. Should we encounter problems in the future, we will need to build the custom cable or find another way to suppress the break.
Thanks to the following people for your responses:
Casper Dik [casper@holland.Sun.COM]
David Thorburn-Gundlach [david@bae.uga.edu]
Ronald Loftin [reloftin@mailbox.syr.edu]
Celeste Stokely [celeste@stokely.com]
Jeff Putsch [putsch@unitrode.com]
Michael Richards [mar@xylogics.com]
Kevin Sheehan {Consulting Poster Child} [Kevin.Sheehan@uniq.com.au]
Jim Harmon [jharmon@telecnnct.com]
Jason Axley [jason.axley@attws.com]
Rick Reineman [reineman1@raiders.llnl.gov]
Eddy Fafard [eddy@slimepuppy.apple.com]
David Schiffrin [daves@adnc.com]
Dwight Peters [dpeters@nswc.navy.mil]
Raymond Wong [negativl@netcom.com]
Louis Hoo [lhoo@fcicom.com]
Have, R. van der [r.vanderhave@kpn-telecom.nl]
Stephen Harris [sweh@mpn.com]
Arthur Darren Dunham [add@netcom.com]
Jim Seavey [jwseavey@norseaconsulting.com]
> Casper Dik [casper@holland.Sun.COM] :
SInce they're running 2.6, all you need to do is:
kbd -a disable
to make it persistant after boot edit /etc/default/kbd and
add
KEYBOARD_ABORT=disable
Note that this will disable break and there's no way to get it back
to the OK prompt except in case of power failure.
The preferred solution is to get a terminal server or a multiple
serial line card for a system and build a console server.
Casper
> David Thorburn-Gundlach [david@bae.uga.edu]
You mentioned wanting to pick the best option, so I'll go straight to
it: a BlackBox (or other manufacturer) server switch, which lets you
use a single keyboard/monitor/mouse for multiple machines. There's
actually a better option than that: use a product such as Polycenter
Console Manager to give you a *remote* console capability with console
logging and console sharing. Unfortunately, PCM runs on VAXen (ugh),
and it's the only product of its kind of which I'm aware (though that
certainly doesn't mean it's the only one out there).
You can modify the zs driver to remap break to another key; Sun
Integration whipped up a package for us for just that purpose and we
use another sequence (like Ctrl-Shf-_ or some such). Unfortunately,
that mod is OS- and architecture-specific, so you'll have to go back
to them every time you rev your OS -- and I don't know what it costs
if you don't have a service contract that covers it. The package that
we have is called SUNIzsbrk; it may even be a standard package that
they can shoot you for free or cheap. Unfortunately, it's not a
kernel mod that you want, AFAIK, and programs such as disable_l1a or
abortkey are actually remapping the keyboard so that some other
sequence (like Ctrl-Shf-_ or some such) sends a break (and so they
won't work on your console port).
I haven't tried playing with resistors, and I certainly haven't tried
keeping keyboards plugged in on all of my servers (nowhere near enough
room :-)
> Ronald Loftin [reloftin@mailbox.syr.edu]
We use the following pinout for serial cables between individual machines
and a central "Console" machine with a couple of SCSI terminal servers.
This prevents dropping DTR and generating the break signal.
Note that pins 4/5 and pins 6/8/20 are jumpered together at each end.
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)
> Celeste Stokely [celeste@stokely.com]
I'd get 1 kbd/monitor or terminal, and attach it to all the
machines with some type of console switch box. I hate having
systems with no ready console of any sort.
What if it's 3am, and you have to fix the machine via console
to get it running again? Do you want to run around looking for
a working laptop? Or, would you rather just turn the console
switch to your machine and do the work? My approach is always
to make it as easy as possible to do the work quickly and
well.
I have lots of Sun console switches listed at:
http://www.stokely.com/unix.serial.port.resources/serial.switch.html
> Jeff Putsch [putsch@unitrode.com]
I suggest you check out Lightwave Communications products. They make console
switches that work either with the Sun keyboard and monitors or via ttyA and a
VT100/laptop.
You can connect all the servers to a console switch and then connect the
switch to the laptop when you need to work on one of the systems. The servers
do not notice when you connect/disconnect the laptop from the console switch.
It works quite well for us!
You can find Lightwave Communications at: http://www.lightwavecom.com ,
800-871-9838 , or 203-878-9838.
> Michael Richards [mar@xylogics.com]
Why don't you just get a terminal server and hook the all the consoles to
the terminal servers. It works great and you can get to the consoles from
anywhere.
> Jim Harmon [jharmon@telecnnct.com]
I don't like any of these options.
They don't give you console security on any of your systems.
The recommended method is to connect the ttya port to a terminal server,
and use the terminal server via telnet to access the console port of all
your servers.
A single terminal server can act as the console for all your systems,
(if under the number of ports on the term server.)
The one we use is the BayNetworks MicroAnnexIII with 16 ports and
10-base-T port.
It can even be used as a modem bank controller, allowing yout to dial in
or out of your network, and has independant password protection so you
can isolate the modem pool from your network logins.
> Jason Axley [jason.axley@attws.com]
I've heard that the resistor fix doesn't work. Haven't tried it though.
Disabling the break signal is not a good idea...what if you need to break
to the ok prompt?
I've used a console server attached to several console ports and that
works flawlessly. I've also used a dumb terminal (DEC vt100) attached to
a switch box and then from the switch box to several console ports. This
doesn't work as well because it doesn't allow remote access to the
consoles and you cannot turn the vt100 off or it will send the break
signal and put the selected computer at the ok prompt.
If the machine gets bumped to the ok prompt, I've been successful in just
typing "go" and the machine will go back to the state it was at when
broken out. I don't know about the problems that could arise from doing
this. It worked alright for me at the time!
Operating systems like NT probe the serial ports on bootup so if you were
to plug the laptop in and then boot it, it will send a break signal. It's
best to have those types of OS's up and running *before* connecting to the
sparc. Good luck!
> Rick Reineman [reineman1@raiders.llnl.gov]
I may have misunderstood your problem as the solution seems so simple.
How about a terminal server connected to each of the tty console ports?
The other end of the terminal server is on the network, you have console
access from anywhere. If you need console access in the computer room
(like when the network is down) you connect a laptop or dumb terminal
to one of the serial ports on the term server.
> David Schiffrin [daves@adnc.com]
I use terminal servers for these sorts of situations.
many (annex for one) have options so they won't send a break even on
powerfail. This way you can telnet to the termserver, or plug your
laptop into it, and use it to access the various console ports without
all that nasy plugging and unplugging.
If they're really remote colo's you can plug a power controller into
the term server to, and then remotely tell the power controller to
turn your servers off and on, if they get really obstinate
> Dwight Peters [dpeters@nswc.navy.mil]
not meaning it a a complete response, but you are probably on to something when
you talk about leaving the keyboard attached. I have had several occassions,
in past jobs, in which I used a sun keyboard, in conjunction with a vt100 or
other
terminal to get around problems interfacing with the monitor. Based on this I
further confirm that if you can leave a sun keyboard hooked up to the box, it
will make the box happy. Also several jobs back we had a switch unit for
monitor and keyboard that worked well. I can't give you the brand or anything
but I suspect this means that the correct terminating resistor will work
wonders for your situation.
> Raymond Wong [negativl@netcom.com]
I've never had a problem with connecting the laptop if you let the terminal
emulation finish loading beffore you connect the serial... Are you using
a handshaking or non handshaking null? tying 6,8 and 20 (DSR, DCD, DTR)
together on each side will mean it never detects the disconnect... just
leave the null attached to the back of the sparc and it shoud be fine...
Most of the time, the break signal is sent by the term program starting, so
waiting until it's loaded to hook it up stops that part. I wouldn't
want to disable break sense or you can't do it when you want to, either.
(Of course, the other thing I got used to doing was typing go as soon
as I hooked up the laptop... the system doesn't die unless you try and
run some other commands at the ok prompt, so starting off with a go means
you're okay, worst case is you get prompted for a password and have to
hut return again before you log on.)
Another option you might want to consider: do you need true console?
If not, enable ttyb (I think the Ultra60 has one, doesn't it?), and
hook the laptop to that if you just want to be able to login as root
(enable it secure, that is). You can do everything but single user mode stuff,
without risk of BREAKing the machine. If you do at some point want true
console, just move the cable over. The system will boot fine (and with ttya as
console) if nothing's connected to either the kbd or tty ports.
> Louis Hoo [lhoo@fcicom.com]
The best solution to this problem is to use a terminal server
like the bay networks microannex. This also provides remote
console access.
In the past I used this to setup a remote site with about
10 sparcs, all headless. I also connected a modem to the
annex so I could dial in, if the wan connection went down.
BTW, the Sun NTS is the same as the annex.
> Kevin Sheehan {Consulting Poster Child} [Kevin.Sheehan@uniq.com.au]
man kbd on 2.6 and you will find that the kbd command now does this quite
nicely:
The keyboard abort sequence (L1-A or STOP-A on the keyboard
and BREAK on the serial console input device on most sys-
tems) effect may only be changed by the superuser, using the
-a option.
On most systems, the default effect of the keyboard abort
sequence is to suspend the operating system and enter the
debugger or the monitor. Some systems have key switches
with a 'secure' position. On these systems, the key switch
in the 'secure' position, overrides any software default set
with this command.
If you want to permanently change the software default
effect of the keyboard abort sequence, you can add or change
the current value of the KEYBOARD_ABORT variable to the
value disable in the keyboard default file,
/etc/default/kbd, as shown here.
KEYBOARD_ABORT=disable
> Have, R. van der [r.vanderhave@kpn-telecom.nl]
To my humble opinion (and experience) it (=going down to boot prom) does
not occur when you first startup a terminal emulation on your laptop
before connecting it to the ttya.
The other way around when your work on site is done: first
disconnectfrom ttya, then stop the terminal emulation program on your
portable.
Furthermore: what's wrong with using the ttyB port instead?
Brent
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:39 CDT