Serial Consoles can be very useful
This article isn’t fully complete yet. I wanted to have two serial cables going from one box to the other.
But what’s here and in Adding a new drive via the serial console using dump/restore
should be enough to get you going.
Serial consoles have their uses. Unfortunately, this seems to be a hard learned lesson.
Especially when you have locked yourself out of the box during
a firewall rule change, or a /etc/hosts.allow modification, or even when you accidentally or
inadvertently kill sshd.
During a recent -STABLE upgrade of two remote boxes, I managed to lock myself out of the box (see my post to the
mailing list. Luckily,
the solution was rather simple, and I recovered both boxes. The elapsed time between problem discovery and problem resolution
was about four days (I found the problem on a Sunday, and fixed it on Thursday morning). If a serial console had been
available, the problem would have been fixed within 30 minutes. The fact that I was in Ottawa and the machines were in
New Zealand didn’t help the situation. Luckily, the staff at CityLink have been
very helpful and kind to me over the years…
The handbook
Have you heard about the FreeBSD Handbook?
If not, where have you been? I count over 200 references to the handbook from within my website. If you’ve never
read this document, you need to. In fact, as I type this, I’m about to start reading the section on serial
communications which deals with Setting Up the Serial Console. You will need to read
that document first. If you don’t, you won’t find my article any use at all.
I think you should
I will not be going into detail about what I did to get the serial console running. I will only be providing
points which I had to deal with for my situation. Your needs will vary and that necessitates that you read that
document.
My particular situation
In my situation, I have two computers, over which I have exclusive access, and which are the same location. They have
two serial cables between them. Each has com1 [also known as sio0] configured to be a serial console
and is listening on com2 to the other computer. That is, each computer has a null modem
cable from going from its own COM1 to the other computer’s COM2. My objective is the ability to access the
broken box from the other box. The assumption is that at one box will be running fine whenever the other box breaks.
What it looks like during the boot
The following is what the reboot looked like after my first attempt. I was using -D
in /boot.config:
cvsup reboot:Waiting (max 60 seconds) for system process vnlru' to stop...stopped
Waiting (max 60 seconds) for system process bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process syncer' to stop...stoppedsyncing disks... 3 2 2
done
Uptime: 16m38s
Rebooting...
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.6-STABLE #0: Sat Aug 10 04:35:41 NZST 2002
dan@cvsup.example.org:/usr/home/ncvs/usr-obj/usr/src/sys/ZEKE
That wasn’t good enough. I also wanted the boot sequence. So I changed the options to -Dh.
Then I saw this:
cvsup reboot:
Waiting (max 60 seconds) for system process vnlru' to stop...stopped
Waiting (max 60 seconds) for system process bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process syncer' to stop...stopped
syncing disks...
done
Uptime: 26m44s
Rebooting...
Console: serial port
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS drive D: is disk2
BIOS 639kB/64512kB available memoryFreeBSD/i386 bootstrap loader, Revision 0.8
(dan@cvsup.example.org, Fri Aug 2 20:21:34 NZST 2002)
Loading /boot/defaults/loader.conf
/kernel text=0x2e3775 data=0x3b4a0+0x345f4 syms=[0x4+0x3e450+0x4+0x44e15]
-
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [kernel]...
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.6-STABLE #0: Sat Aug 10 04:35:41 NZST 2002
dan@cvsup.example.org:/usr/home/ncvs/usr-obj/usr/src/sys/ZEKE
Connecting to the serial console
On the other box (i.e. the one which is working and does not have the problem), enter this
command:
# tip com1
connectedFreeBSD/i386 (cvsup.example.org) (ttyd0)
login:
To disconnect the serial session, type ~. (that’s a tilde followed by
a period). WARNING: you should
be aware of the possible consequences of not logging out before you disconnect.
If the first machine is compromised, it is trivial to connect via the serial link. If you
have not logged out, then the second machine will be compromised as well.
This article brought to you by the letter A…
Coincidentally, my copy of Absolute BSD: The Ultimate Guide to FreeBSD
by Michael W. Lucas arrived today. Just in time for me to use Chapter 20 which contains a section on the
serial console.
if you use -P in the /boot.config, it will probe for a keyboard.
If no keyboard is found, it will output the the serial port.
If a keyboard is found, it will output to the video card.
Good point.
I did not want to use that option. Given that the box is remote, I have no control over whether or not a keyboard is attached or not. If the keyboard is attached, I will never get access using -P.
The article is rather lacking in useful content. Sorry.
The handbook also mentions using using the -h flag to output the boot stuff to the console. I have a box with no video card whatsoever and the serial console runs at 115200, which is quite nice.
I agree, having a serial console is great to have in case of lockouts and general maintenance.
In your latest article a slight error has crept in:
Each has com1 [also known as sio1]
should read
Each has com1 [also known as sio0]
FreeBSD is off by one from old DOS device names.
Fixed. Thank you.
Shouldn’t that be DOS was off by one compared to Unix standard device numbering? 😉
While I’ve my editors hat on, some items in the article grated on this reader.
"I count over 200 references to this document with my website along." Should this read: I count over 200 references to this document [with]IN my website alonE?
Also, while host to host Ethernet cables are "crossover", host to host Serial Cables are typically called "null modem".
One more item, if you rsh into the first box, then tip in to the second, a ~. will kill your rsh, not the tip. Use ~~. to kill the tip. I almost always forget this one at work. Not sure how ssh will behave.
Jed wrote:
>
> "I count over 200 references to this document with my website
> along." Should this read: I count over 200 references to
> this document [with]IN my website alonE?
How about:
I count over 200 references to the handbook from within my website.
> Also, while host to host Ethernet cables are "crossover",
> host to host Serial Cables are typically called "null modem".
Fixed.
> One more item, if you rsh into the first box, then tip in to
> the second, a ~. will kill your rsh, not the tip. Use ~~. to
> kill the tip. I almost always forget this one at work. Not
> sure how ssh will behave.
ssh will be OK with the ~. and I never use rsh. But good tip.
Thanks.
The article suggests using two null-modem cables, one from sio0 on box A connecting to sio1 on box B, and the other one connecting sio1 on box A to sio0 on box B. Would it not be possible to use just one cable and connect sio0 on A to sio0 on B?
Or am I missing something?
Yes, but that would only allow you use one serial console. You can’t have one serial console listening on both ends of the cable. I asked around about this and was told that.
I’d be very happy for people to show me otherwise.
Sorry for my dummy question:wat is null-modem cable actually?can i used the serial cable comes with external modem?
Recent platforms from Sun Microsystems take this a couple of steps futher.
"Entry level" server products (Netra) with LOM interfaces bring up the LOM serial port with soft-power, and have firmware with support for power control, fan status, and manual or watchdog reset.
Mid-range servers (E250, Sun Fire 280) have the "RSC", a card with on-board backup battery, PCMCIA modem, serial, and ethernet, with full power control over the host and the ability to do TAP text messaging to a pager.
Nothing like having your server page you to let you know that the datacenter just lost all power and the UPS failed to kick in in time 🙂
Oh wow…that is so sweet. I love the idea of an onbard modem.
I am now blessing your mid-range server…
Hi All,
it could be a good idea to use a console server if you have to manage several unix boxes.
Try to checkout cyclades, they manufacture linux based (yes, unfortunatly no BSD) Console Access Server.
http://www.cyclades.com
This should not be seen as advertisement, just as a real good approach of managing unix based servers 🙂
You may use the low cost version of two crosscabled servers like described in the article, but a console server may be more useful if you have more than two servers.
BeSD regards,
Marian
Yes, I’d love a console server. But my budget doesn’t. So if anyone has a spare 8 or 16 port console server, please keep me in mind.
Under the section "Connecting to the serial console" you write:
"enter this command:"
# tip com1 connected FreeBSD/i386 (cvsup.example.org) (ttyd0) login:
Since I am new to the topic, it took me awhile to figure out what you meant. Now I realize it should be two (or more lines). This tip command, followed by the screen output.
# tip com1
# connected FreeBSD/i386 (cvsup.example.org) (ttyd0)
# login:
At least I think that is what happens; I can’t quite get it working my box (I don’t get the prompt).
HTH
[%sig%]