1475 lines
56 KiB
Text
1475 lines
56 KiB
Text
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
|
|
<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
|
|
%articles.ent;
|
|
]>
|
|
|
|
<article>
|
|
<articleinfo>
|
|
<title>Console Server</title>
|
|
|
|
<author>
|
|
<firstname>Gregory</firstname>
|
|
<surname>Bond</surname>
|
|
|
|
<affiliation>
|
|
<address><email>gnb@itga.com.au</email></address>
|
|
</affiliation>
|
|
</author>
|
|
|
|
<pubdate>$FreeBSD$</pubdate>
|
|
|
|
<legalnotice id="trademarks" role="trademarks">
|
|
&tm-attrib.freebsd;
|
|
&tm-attrib.cisco;
|
|
&tm-attrib.intel;
|
|
&tm-attrib.lantronix;
|
|
&tm-attrib.microsoft;
|
|
&tm-attrib.opengroup;
|
|
&tm-attrib.sun;
|
|
&tm-attrib.general;
|
|
</legalnotice>
|
|
|
|
<abstract>
|
|
<para>This document describes how you can use &os;
|
|
to set up a <quote>console server</quote>. A console server is
|
|
a machine that you can use to monitor the consoles of many other
|
|
machines, instead of a bunch of serial terminals.</para>
|
|
</abstract>
|
|
</articleinfo>
|
|
|
|
<indexterm><primary>console-server</primary></indexterm>
|
|
|
|
<sect1 id="problem">
|
|
<title>The Problem</title>
|
|
|
|
<para>You have a computer room with lots of &unix; server machines and lots
|
|
of communications hardware. Each of these machines needs a serial
|
|
console. But serial terminals are hard to find and quite expensive
|
|
(especially compared to a much more capable PC). And they take up a lot
|
|
of precious space in the computer room.</para>
|
|
|
|
<para>You need access to the console because when things break, that is
|
|
where error messages go. And some tasks have to be done on the console
|
|
(e.g. boot problems or OS installs/upgrades). Some &unix; systems allow
|
|
the console to break out to the ROM monitor which can sometimes be the
|
|
only way to unstick a hung machine. This is often done with a
|
|
<literal>LINE BREAK</literal> sent on the console serial port.</para>
|
|
|
|
<para>If we are going to play about with consoles, then there are a couple
|
|
of other things that would be great:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Remote access. Even in the same office, it would be convenient
|
|
to access all the consoles from your desk without walking into the
|
|
computer room. But often the machines are off-site, perhaps even in
|
|
another country.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Logging. If something has gone wrong, you would like to be able
|
|
to have a look at the previous console output to see what is up.
|
|
Ordinary console screens give you the last 25 lines. More would be
|
|
better.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Network Independence. The solution needs to work even if the
|
|
network is down. After all, a failed network is when you need
|
|
consoles the most! Even better is network independence with remote
|
|
access.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>No single-point failure. A console system that crashes every
|
|
machine when it fails is no use. This is particularly tricky with
|
|
Sun &unix; hosts as they will interpret a powered-off terminal as a
|
|
<literal>BREAK</literal>, and drop back to the ROM monitor.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Interface with a pager or some similar alerter device.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ability to power-cycle machines remotely.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Not be <emphasis>too</emphasis> expensive. Free is even
|
|
better!</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="possible-solutions">
|
|
<title>Possible Solutions</title>
|
|
|
|
<para>If you use PC hardware for your servers, then a so-called <quote><acronym>KVM</acronym>
|
|
switch</quote> is one possible solution. A <acronym>KVM</acronym> switch allows the use of
|
|
a single keyboard, video screen and mouse for multiple boxes. This cuts
|
|
down on the space problem, but only works for PC hardware (not any
|
|
communications gear you might have), and is not accessible from outside
|
|
the computer room. Nor does it have much scroll-back or logging, and
|
|
you have to handle alerting some other way. The big downside is that it
|
|
will not work for serial-only devices, such as communications hardware.
|
|
This means that even with a room full of PC-based servers, you are
|
|
probably still going to need some sort of serial console
|
|
solution.</para>
|
|
|
|
<note>
|
|
<para>Actually, Doug Schache has pointed out that you
|
|
<emphasis>can</emphasis> get <acronym>KVM</acronym> switches that also do serial consoles
|
|
or Sun compatible <acronym>KVM</acronym> switching as well as PCs, but they are
|
|
expensive. See <ulink url="http://www.avocent.com/">Avocent</ulink>
|
|
for example.)</para>
|
|
</note>
|
|
|
|
<para>You might be tempted to do without a console terminal, but when
|
|
things go pear-shaped you <emphasis>really</emphasis> need to see what
|
|
is on the console. And you have to use the console to boot the machine
|
|
and do things like OS upgrades or installs.</para>
|
|
|
|
<para>You might try having a single console terminal and switching from
|
|
server to server as needed, either with a serial switch or just by
|
|
patching it into the required machine. Serial switches are also hard to
|
|
come by and not cheap, and may cause problems with sending
|
|
<literal>BREAK</literal> when they switch. And (if your computer room
|
|
is anything like ours) you never seem to have the right combination of
|
|
patch leads to connect to the machine you need to, and even if the leads
|
|
are there you can never work out exactly which combination of
|
|
<literal>DTE/DCE</literal>
|
|
headshells goes with which lead goes with which hardware. So you spend
|
|
the first 10 minutes fooling around with breakout boxes and a box of
|
|
leads, all while the server is down and the users are screaming. Of
|
|
course this does not deal with the logging or remote access
|
|
requirements. And inevitably the console is not switched to the machine
|
|
you need so you lose all the console messages that might tell you what
|
|
is going on.</para>
|
|
|
|
<para>One popular solution is to use terminal server hardware. Typically,
|
|
the serial ports are connected to the various machine consoles, and set
|
|
up for <quote>reverse telnet</quote> access. This means a user can
|
|
telnet to a given IP/port and be connected to the appropriate console.
|
|
This can be very cost-effective, as suitable old terminal servers can be
|
|
picked up fairly cheaply (assuming you do not have a couple lying
|
|
around). And it is of course network-accessible so suitable for remote
|
|
access. But it suffers from one major drawback: if the network is down,
|
|
then you have <emphasis>no</emphasis> access to any console, even if you
|
|
are standing right next to the machine. (This may be partially
|
|
alleviated by having a suitable terminal connected to one of the
|
|
terminal server ports and connecting from there, but the terminal server
|
|
software may not support that.) Also there is no logging or replay of
|
|
console messages. But with a bit of work, and the addition of some
|
|
software such as <application>conserver</application>
|
|
(described below), this can be made to work pretty well.</para>
|
|
|
|
<para>A possibility suggested by Bron Gondwana is similar to the above
|
|
solution. If you use servers with multiple serial ports, you can
|
|
connect each spare serial port to the console port of the
|
|
<quote>next</quote> server, creating a ring of console connections (in
|
|
some sort of order). This can be made to work reasonably well with the
|
|
aid of the <application>conserver</application>
|
|
software, but can be a bit confusing otherwise (i.e. remembering which
|
|
port is connected to which console). And you are stuck if you need to
|
|
use serial ports for other things (such as modems) or you have machines
|
|
without spare ports.</para>
|
|
|
|
<para>Or, if your budget exceeds your willingness to hack, you can
|
|
buy an off-the-shelf solution. These vary in price and
|
|
capability. See, for example,
|
|
<ulink url="http://www.lightwavecom.com/">Lightwave</ulink>,
|
|
<ulink url="http://www.perle.com/">Perle</ulink>,
|
|
<ulink url="http://www.avocent.com/">Avocent</ulink> or
|
|
<ulink url="http://www.blackbox.com/faxbacks/23000/23362.PDF">Black Box</ulink>.
|
|
These solutions can be quite expensive - typically $USD100 - $USD400 per
|
|
port.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="our-solution">
|
|
<title>Our Solution</title>
|
|
|
|
<para>In light of the above requirements, we chose a solution based on a
|
|
dedicated PC running &unix; with a multiport serial card, and some
|
|
software designed to handle serial consoles.</para>
|
|
|
|
<para>It includes the following elements:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>A surplus PC. We used a &pentium; 166, with a PCI bus, 2Gbyte
|
|
hard disk and 64Mb of RAM. This is a massive overkill for this
|
|
task, and P-100, 500Mb, 32Mb would be more than enough.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A PC &unix; system. We used <ulink
|
|
url="&url.base;/index.html">&os; 4.3</ulink> as that is used for
|
|
other tasks within our office.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A multi-port serial card. We chose the <ulink
|
|
url="http://www.stallion.com/html/products/easyio.html">&easyio; PCI</ulink>
|
|
8-port card from <ulink url="http://www.stallion.com/">Stallion
|
|
Technologies</ulink>. This cost us about $AUD740, or under
|
|
$100/port, from <ulink url="http://www.ht.com.au/">Harris
|
|
Technologies</ulink> (which has lots of stuff but is by no means the
|
|
cheapest place in town - shop around and you might get it a lot
|
|
cheaper). This card has a big DB80 connector on the back, and a
|
|
cable plugs into that which has a block with 8 RJ-45 sockets on it.
|
|
(We chose the RJ-45 version as our entire cable plant is RJ-45.
|
|
This allows us to patch connections from the required box to the
|
|
console server without any special cables.) This is the only thing
|
|
we needed to buy to make this all happen.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>We build two servers, one for each computer room, with 8 ports
|
|
in one and 16 ports (via two &easyio; PCI cards) in the other. If we
|
|
needed more than 16 ports, then another of the Stallion cards would
|
|
be more cost-effective. We could conceivably support 128 ports in
|
|
each server (with 2 EasyConnect 8/64 host cards and 8 16 port RJ-45
|
|
modules) for about $AUD12,000.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A modem for remote access to the console server host when the
|
|
network is down. We have not done this yet as the computer room is
|
|
next door, but when we put a server in Sydney we will add the modem.
|
|
The idea is that when the network is down, you can dial up and log
|
|
into the server machine and run the console program locally. For
|
|
security, we will probably leave the modem powered off and ask the
|
|
gopher in Sydney to turn on the well-labelled button when we need
|
|
it.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A program called <ulink
|
|
url="http://www.conserver.com/">conserver</ulink>. This program
|
|
does all the magic required to enable remote access to consoles, and
|
|
do the replaying and logging etc. It comes in two parts: a server
|
|
called <application>conserver</application> that runs as a daemon
|
|
and connects to the serial ports, handles logging etc, and a client
|
|
program called <application>console</application> that can connect
|
|
to the server, display console messages, send keystrokes (and
|
|
<literal>BREAK</literal>), etc.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>This design covers all the major requirements except remote power
|
|
cycling:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Remote access comes because the
|
|
<application>console</application> client program works across the
|
|
network.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Logging is handled by the <application>conserver</application>
|
|
program.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If the network is down, then we can use the console on the PC to
|
|
run the <application>console</application> client locally. For
|
|
remote sites, we can add a modem for dial-in access to the the
|
|
server command line to run the client.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>By patching the &solaris; servers (see <xref linkend="solaris">),
|
|
we can avoid pranging the whole computer room when the console
|
|
server PC crashes (or the power supply fails, or whatever).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>We already have pager alerts from another system we have
|
|
installed, but the console server has all the required log info so
|
|
that could easily be implemented if we needed. And it even has a
|
|
modem for calling the pager company!</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>We do not currently support remote power cycling. Some versions
|
|
of the <application>conserver</application> program support this, but it does require
|
|
specialised serial-controlled power boards. We have no immediate
|
|
need for remote power cycling (we have a gopher in each remote
|
|
office who can do it by remote control) so this is not a major
|
|
problem, and we could add it easily should we ever see the need and
|
|
get the appropriate hardware.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This solution was very cheap. Total cost for the 9-port server
|
|
was $AUD750 for the IO card, as we re-used a surplus PC and already
|
|
owned the hardware for the special cables. If we had to buy
|
|
everything, then it would still only cost around $AUD1500 for the
|
|
8-port server.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="setting-up-server">
|
|
<title>Setting Up The Server</title>
|
|
|
|
<sect2 id="patching-stallion">
|
|
<title>Checking the Stallion driver</title>
|
|
|
|
<para>&os; has adequate support for modern Stallion cards since
|
|
4.4 release. If you are running an older version of &os;, you
|
|
will need to upgrade to a more modern version of &os; (which
|
|
you should do anyway, to make sure your system is not
|
|
vulnerable to known security issues). See the <ulink
|
|
url="&url.books.handbook;/makeworld.html">&os;
|
|
Handbook</ulink> for information about updating your
|
|
system.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="configuring-kernel">
|
|
<title>Configuring a new kernel</title>
|
|
|
|
<para>The Stallion driver is not included in the default
|
|
<literal>GENERIC</literal> kernel, so you will need to create a kernel
|
|
config file with the appropriate entries. See &man.stl.4; and the
|
|
appropriate section of the <ulink
|
|
url="&url.books.handbook;/kernelconfig.html">&os;
|
|
Handbook</ulink>.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="making-devices">
|
|
<title>Making The Devices</title>
|
|
|
|
<para>You will need to make the device notes for the Stallion card
|
|
(which are not made by default). A new version of
|
|
<filename>/dev/MAKEDEV</filename> with Stallion support will have been
|
|
created by the <application>mergemaster</application> run during the
|
|
above procedure. If you have a Stallion card with more than 8 ports,
|
|
then you will need to edit <filename>/dev/MAKEDEV</filename> and
|
|
change the definition of <literal>maxport</literal> at about line 250.
|
|
By default, <filename>MAKEDEV</filename> only makes device nodes for 8
|
|
ports to keep the size of the <filename>/dev</filename> directory
|
|
down.</para>
|
|
|
|
<para>Run a command like:
|
|
|
|
<screen>&prompt.root; <userinput>cd /dev/ && sh MAKEDEV cuaE0</userinput></screen>
|
|
|
|
to create dial-out devices for the first Stallion card. See the
|
|
comments in <filename>MAKEDEV</filename> and the &man.stl.4; man page
|
|
for more details.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="compiling-conserver">
|
|
<title>Compiling conserver</title>
|
|
|
|
<note>
|
|
<para>See the section on <application>conserver</application> versions
|
|
<xref linkend="conserver-versions">; the version I use is
|
|
available in the &os; ports collection; however, it is not the only
|
|
one.)</para>
|
|
</note>
|
|
|
|
<para>There are two ways to install <application>conserver</application>.
|
|
You can either compile
|
|
from the source or use the &os; ports framework.</para>
|
|
|
|
<sect3 id="using-ports">
|
|
<title>Using the ports framework</title>
|
|
|
|
<para>Using the ports is a bit cleaner, as the package system can then
|
|
keep track of installed software and cleanly delete them when not
|
|
being used. I recommend using the
|
|
<filename role="package">comms/conserver-com</filename> port.
|
|
Change into the
|
|
port directory and (as <username>root</username>) type:</para>
|
|
|
|
<screen>&prompt.root; <userinput>make DEFAULTHOST=<replaceable>consolehost</replaceable> install</userinput></screen>
|
|
|
|
<para>where <replaceable>consolehost</replaceable> is the name of the
|
|
machine running the console server. Specifying this when the binary
|
|
is compiled will avoid having to either specify it each time the
|
|
program is run on remote hosts or having to maintain a
|
|
<filename>conserver.cf</filename> file on every host. This command
|
|
will fetch, patch, configure, compile and install the
|
|
<application>conserver</application> application.</para>
|
|
|
|
<para>You can then run <command>make package</command> to create a
|
|
binary package that can be installed on all the other &os; hosts
|
|
with &man.pkg.add.1;. For extra style points, you can make a two
|
|
versions of the package: one for the console server machine without
|
|
a <literal>DEFAULTHOST</literal> argument, and one for all the other
|
|
hosts with a <literal>DEFAULTHOST</literal> argument. This will
|
|
mean the console client program on the console server machine will
|
|
default to <hostid>localhost</hostid>, which will work in the
|
|
absence of name servers when the network is busted, and also allow
|
|
<quote>trusted</quote> (i.e. no password required) connections
|
|
via the localhost IP address for users logged into the console
|
|
server machine (either via the console screen or the emergency
|
|
backup modem). The version for the other machines with a
|
|
<literal>DEFAULTHOST</literal> argument means users can just use the
|
|
<application>console</application> client without specifying a
|
|
hostname every time, and without needing to configure the
|
|
<filename>conserver.cf</filename> file on every machine.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="from-tarball">
|
|
<title>From the source tarball</title>
|
|
|
|
<para>If you prefer, you can download <application>conserver</application>
|
|
and compile it yourself.
|
|
You might need to do this if you want to install the
|
|
console client on non-&os; systems. We run the client on our
|
|
&solaris; hosts and it inter-operates with the &os;-hosted server
|
|
with no problems. This allows anyone in the whole company (many of
|
|
whom have PCs and no &os; host access on their desk) to access
|
|
the console server.</para>
|
|
|
|
<para>Download the file from the <ulink
|
|
url="ftp://ftp.conserver.com/conserver/conserver-8.1.9.tar.gz">conserver.com
|
|
FTP site</ulink>. Extract it into a handy directory then
|
|
configure it by running</para>
|
|
|
|
<screen>&prompt.user; ./configure <option>--with-master=<replaceable>consoleserver</replaceable></option> <option>--with-port=<replaceable>782</replaceable></option></screen>
|
|
|
|
<para>The <option>--with-master</option> argument avoids having to
|
|
specify the master server every time the client is run remotely (or
|
|
keeping up-to-date config files on all remote hosts). The
|
|
<option>--with-port</option> argument avoids having to update
|
|
<option>/etc/services</option> on every machine.</para>
|
|
|
|
<para>Then type <command>make</command> and, as root,
|
|
<command>make install</command>.</para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2 id="configuring-conserver">
|
|
<title>Configuring conserver</title>
|
|
|
|
<para>The <application>conserver</application> program is configured via a file called
|
|
<filename>conserver.cf</filename>. This file usually lives in
|
|
<filename>/usr/local/etc</filename> and is documented in the
|
|
&man.conserver.cf.5; manual page.</para>
|
|
|
|
<para>Our config file looks like this:</para>
|
|
|
|
<programlisting>LOGDIR=/var/log/consoles
|
|
gallows:/dev/cuaE0:9600p:&:
|
|
roo:/dev/cuaE1:9600p:&:
|
|
kanga:/dev/cuaE2:9600p:&:
|
|
%%
|
|
allow: itga.com.au
|
|
trusted: 127.0.0.1 buzz</programlisting>
|
|
|
|
<para>The first line means all the console log files by default go into
|
|
the <filename>/var/log/consoles</filename> directory. The
|
|
<quote>&</quote> in each line says the log file for that machine
|
|
will be
|
|
<filename>/var/log/consoles/<replaceable>machine</replaceable></filename>.</para>
|
|
|
|
<para>The next three lines show three machines to which we need to
|
|
connect. We use the
|
|
<devicename>cuaE<replaceable>x</replaceable></devicename> devices
|
|
rather than the
|
|
<devicename>ttyE<replaceable>x</replaceable></devicename>
|
|
devices because console ports typically do not show carrier. This
|
|
means that opening
|
|
<devicename>ttyE<replaceable>x</replaceable></devicename> would hang
|
|
and <application>conserver</application> would never connect. Using
|
|
the
|
|
<devicename>cuaE<replaceable>x</replaceable></devicename>
|
|
device avoids this problem. Another solution would be to use the
|
|
<devicename>ttyE<replaceable>x</replaceable></devicename>
|
|
devices and enable <quote>soft carrier</quote> on these ports, perhaps by
|
|
setting this using the
|
|
<devicename>ttyiE<replaceable>x</replaceable></devicename>
|
|
device in the <filename>/etc/rc.serial</filename> file. See the
|
|
comments in this file for more details. Also see &man.sio.4;
|
|
for information on the initial-state and locked-state devices. (The
|
|
Stallion driver also supports these conventions). And see the
|
|
&man.stty.1; for details on setting device modes.</para>
|
|
|
|
<para>The last section shows that any user logged into the
|
|
server machine has passwordless access to all consoles. We do
|
|
this because there are no user accounts on this machine and it
|
|
is safely isolated from the wide world behind our firewall.
|
|
The allow line allows anyone on a machine inside our
|
|
organisation to access the console server if they provide
|
|
their password, which is recorded in the
|
|
<filename>conserver.passwd</filename> file (see next
|
|
section).</para>
|
|
</sect2>
|
|
|
|
<sect2 id="setting-passwords">
|
|
<title>Setting conserver passwords</title>
|
|
|
|
<para>The <filename>conserver.passwd</filename> file contains the
|
|
encrypted version of the password that each user. The file is
|
|
documented in the <literal>conserver.cf(5)</literal> manual
|
|
page.</para>
|
|
|
|
<para>The only tricky bit is loading the file with encoded passwords.
|
|
It appeared in &os; that was is no obvious way to generate an
|
|
encrypted password for inclusion in another file (but see below). So
|
|
I put together a quick hack perl script to do this:</para>
|
|
|
|
<programlisting>@rands = ();
|
|
foreach (0..4) {
|
|
push(@rands, rand 64);
|
|
}
|
|
|
|
$salt = join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[@rands];
|
|
|
|
$salt = '$1$' . $salt . '$';
|
|
|
|
print 'Enter password: ';
|
|
`stty -echo`;
|
|
$cleartext = <>;
|
|
`stty echo`;
|
|
chop($cleartext);
|
|
print crypt($cleartext, $salt), "\n";</programlisting>
|
|
|
|
<note>
|
|
<para>This uses the &os; <acronym>MD5</acronym>-style encrypted passwords. Running
|
|
this on other &unix; variants, or on &os; with DES passwords, will
|
|
likely need a different style of salt.</para>
|
|
</note>
|
|
|
|
<para>&a.kris; has since pointed out you can get the same effect using
|
|
the <command>openssl passwd</command> command:</para>
|
|
|
|
<screen>&prompt.user; openssl passwd -1
|
|
Password: <userinput>password</userinput>
|
|
$1$VTd27V2G$eFu23iHpLvCBM5nQtNlKj/</screen>
|
|
</sect2>
|
|
|
|
<sect2 id="starting-conserver">
|
|
<title>Starting <application>conserver</application> at system boot time</title>
|
|
|
|
<para>There are two ways this can be done. Firstly, you could start up
|
|
<application>conserver</application> from <application>init</application>
|
|
by including an entry in
|
|
<filename>/etc/ttys</filename> that is similar to this:</para>
|
|
|
|
<programlisting>cuaE0 "/usr/local/sbin/conserver" unknown on insecure</programlisting>
|
|
|
|
<para>This has two advantages: <application>init</application> will restart
|
|
the master console
|
|
server if it ever crashes for any reason (but we have not noticed any
|
|
crashes so far), and it arranges for standard output of the
|
|
<application>conserver</application>
|
|
process to be directed to the named tty (in this case
|
|
<devicename>cuaE0</devicename>). This is useful because you
|
|
can plug a terminal into this port, and the
|
|
<application>conserver</application> program
|
|
will show all console output not otherwise captured by a
|
|
client console connection. This is useful as a general
|
|
monitoring tool to see if anything is going on. We set this
|
|
terminal up in the computer room but visible from the main
|
|
office. It is a very handy feature. The downside of running
|
|
<application>conserver</application>
|
|
from the ttys file is that it cannot run in daemon
|
|
mode (else &man.init.8; would continually restart it). This means
|
|
<application>conserver</application> will not write a PID file,
|
|
which makes it hard to rotate the log files.</para>
|
|
|
|
<para>So we start <application>conserver</application> from an rc.d script.
|
|
If you installed <application>conserver</application> via the port,
|
|
there will be a
|
|
<filename>conserver.sh.sample</filename> file installed in
|
|
<filename>/usr/local/etc/rc.d</filename>. Copy and/or rename this to
|
|
<filename>conserver.sh</filename> to enable <application>conserver</application>
|
|
to start at boot time.</para>
|
|
|
|
<para>In fact we use a modified version of this script which also
|
|
connects <application>conserver</application> to a terminal via a tty device so we can monitor
|
|
unwatched console output. Our <filename>conserver.sh</filename> script looks like
|
|
this:</para>
|
|
|
|
<programlisting>#!/bin/sh
|
|
#
|
|
# Startup for conserver
|
|
#
|
|
|
|
PATH=/usr/bin:/usr/local/bin
|
|
|
|
case "$1" in
|
|
'start')
|
|
TTY=/dev/cuaE7
|
|
conserver -d > $TTY
|
|
# get NL->CR+NL mapping so msgs look right
|
|
stty < /dev/cuaE7 opost onlcr
|
|
echo -n ' conserver'
|
|
;;
|
|
|
|
'stop')
|
|
kill `cat /var/run/conserver.pid` && echo -n ' conserver'
|
|
;;
|
|
|
|
*)
|
|
echo "Usage: $0 { start | stop }"
|
|
;;
|
|
|
|
esac
|
|
exit 0</programlisting>
|
|
|
|
<note>
|
|
<para>Note the use of <devicename>cuaE0</devicename> device
|
|
and the need to set tty modes for proper NL-<CR
|
|
handling).</para>
|
|
</note>
|
|
</sect2>
|
|
|
|
<sect2 id="trimming-logs">
|
|
<title>Keeping the log files trimmed</title>
|
|
|
|
<para>&os; has a program called
|
|
<application>newsyslog</application> that will automatically
|
|
handle log file trimming. Just add some lines to the
|
|
configuration file <filename>/etc/newsyslog.conf</filename>
|
|
for the console logs:</para>
|
|
|
|
<programlisting>#
|
|
# The log files from conserver
|
|
/var/log/consoles/gallows 644 10 1000 * Z /var/run/conserver.pid
|
|
/var/log/consoles/kanga 644 10 1000 * Z /var/run/conserver.pid
|
|
/var/log/consoles/roo 644 10 1000 * Z /var/run/conserver.pid</programlisting>
|
|
|
|
<para>This tells <application>newsyslog</application> (which is run from cron every hour on the
|
|
hour) that the console log files should be archived and compressed
|
|
once they reach 1Mb, that we should keep 10 of them, and that to
|
|
signal the server program you send a <literal>SIGHUP</literal> to the process whose PID
|
|
is in the <filename>conserver.pid</filename> file. This is the master server, and it will
|
|
arrange to signal all the child processes. Yes, this will send a <literal>HUP</literal>
|
|
to all clients whenever a single log file needs rotating, but that is
|
|
quite cheap. See &man.newsyslog.8; for details.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="cabling">
|
|
<title>Cabling</title>
|
|
|
|
<para>This is always the hardest part of this kind of problem. We had
|
|
only a dozen or so cables/headshells to build, and we already had a
|
|
collection of the appropriate crimping tools and hardware, so we did it
|
|
ourselves. But if you are not set up for this, or you have a large
|
|
number of cables to make, then you might consider getting some cables
|
|
custom made. Look in the yellow pages, there are a surprising number of
|
|
places that do this! Getting custom-made cabling is good, and you can
|
|
get much more professional results, but can be expensive. For example,
|
|
the RJ-45 to DB-25 adapter kits described below are about $10 each;
|
|
custom-made headshells are about twice that (and take a couple of weeks
|
|
to arrive). Similarly, crimping custom RJ-45 to RJ-45 leads is quite
|
|
cheap (say, $5 each) but it takes a fair amount of time. Custom made
|
|
RJ-45 socket to RJ-45 plug converters cost about $25 each.</para>
|
|
|
|
<para>We have settled on RJ-45 Cat-V cabling for all our office and
|
|
computer room cabling needs. This included patching between racks in the
|
|
computer room. For serial connections, we use patchable headshells that
|
|
have RJ-45 sockets on the back. This allows us to patch whatever
|
|
RJ-45–DB-25 connections we need.</para>
|
|
|
|
<para>Which is just as well, because there are many incompatible ways to
|
|
represent serial connections on the RJ-45 plug. So the cabling has to
|
|
be very careful to use the right mapping.</para>
|
|
|
|
<sect2 id="rj45-colors">
|
|
<title>RJ-45 colors</title>
|
|
|
|
<para>RJ-45 cables and plugs have 8 pins/conductors. These are used as
|
|
4 matched pairs. There are a couple of conventions about how the
|
|
pairs are mapped onto pins, but 100baseT uses the most common (known
|
|
as EIA 586B). There are three common color-coding conventions for the
|
|
individual conductors in RJ-45 cables. They are:</para>
|
|
|
|
<table>
|
|
<title><!-- XXX: Add title for this table --></title>
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry>Pin</entry>
|
|
<entry>Scheme 1</entry>
|
|
<entry>Scheme 2 (EIA 568B)</entry>
|
|
<entry>Scheme 3 (EIA 568A)</entry>
|
|
<entry>Pair</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>Blue</entry>
|
|
<entry>White+Green</entry>
|
|
<entry>White+Orange</entry>
|
|
<entry>2+</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>Orange</entry>
|
|
<entry>Green</entry>
|
|
<entry>Orange</entry>
|
|
<entry>2-</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>3</entry>
|
|
<entry>Black</entry>
|
|
<entry>White+Orange</entry>
|
|
<entry>White+Green</entry>
|
|
<entry>3+</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>Red</entry>
|
|
<entry>Blue</entry>
|
|
<entry>Blue</entry>
|
|
<entry>1+</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>5</entry>
|
|
<entry>Green</entry>
|
|
<entry>White+Blue</entry>
|
|
<entry>White+Blue</entry>
|
|
<entry>1-</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>6</entry>
|
|
<entry>Yellow</entry>
|
|
<entry>Orange</entry>
|
|
<entry>Green</entry>
|
|
<entry>3-</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>7</entry>
|
|
<entry>Brown</entry>
|
|
<entry>White+Brown</entry>
|
|
<entry>White+Brown</entry>
|
|
<entry>4+</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry>White or Grey</entry>
|
|
<entry>Brown</entry>
|
|
<entry>Brown</entry>
|
|
<entry>4-</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Note EIA 468A and EIA 568B are very similar, simply swapping the
|
|
colors assigned to pair 2 and pair 3.</para>
|
|
|
|
<para>See for example the <ulink
|
|
url="http://www.cabletron.com/support/techtips/tk0231-9.html">Cabletron
|
|
Tech Support Site</ulink> for more details.</para>
|
|
|
|
<para>The pins in the RJ-45 plug are numbered from 1 to 8. Holding a
|
|
patch lead with the cable pointing down and the clip away from you,
|
|
pin 1 is at the left. Or, looking into an RJ-45 socket with the clip
|
|
to the top, pin 1 is on the right. The following illustration
|
|
(shamelessly lifted from the Cabletron web site above) shows it pretty
|
|
well:</para>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="tk0231-9-1.png">
|
|
</imageobject>
|
|
|
|
<textobject>
|
|
<literallayout class="monospaced"><!-- XXX: add asci art --></literallayout>
|
|
</textobject>
|
|
|
|
<textobject>
|
|
<phrase><!-- XXX: add RJ45 image description --></phrase>
|
|
</textobject>
|
|
</mediaobject>
|
|
|
|
<para>We have four classes of equipment to deal with in our
|
|
setup:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Sun servers</term>
|
|
|
|
<listitem>
|
|
<para>Sun servers operate as DTE (i.e. send data on TxD and read
|
|
RxD, and assert DTR) with a female DB-25 socket on board. So we
|
|
need to create a headshell for the Stallion that operates as DCE
|
|
and has a male DB-25 plug (i.e. acts as a <quote>null
|
|
modem</quote> cable as well as converts from RJ-45 to DB-25).
|
|
We use headshells that have an RJ-45 socket in them and 8 short
|
|
flyleads with DB-25 pins on the end. These pins can be inserted
|
|
into the DB-25 plug as required. This allows us to create a
|
|
custom RJ-45-DB-25 mapping. We used a couple of different
|
|
sorts, including the
|
|
<ulink url="http://www.molexpn.com.au/">MOD-TAP</ulink>
|
|
part no. <ulink
|
|
url="http://www.molexpn.com.au/products/index.nsx/1/7/0/0/id=340">06-9888-999-00</ulink>
|
|
and the <ulink
|
|
url="http://www.blackbox.com/faxbacks/12000/12654.PDF">FA730
|
|
series</ulink> from
|
|
<ulink url="http://www.blackboxoz.com.au/">Black
|
|
Box</ulink>.</para>
|
|
|
|
<para>On our version of the headshells, these flyleads had the
|
|
following colours (from Pin 1-8): Blue, Orange, Black, Red,
|
|
Green, Yellow, Brown, White. (Looking into an RJ-45 socket,
|
|
with the clip towards the top, pin 1 is on the right.) This is
|
|
how they are connected to the DB-25 socket:</para>
|
|
|
|
<table>
|
|
<title><!-- XXX: Add a title here --></title>
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry>Stallion RJ-45 Pin</entry>
|
|
<entry>Colour</entry>
|
|
<entry>Signal</entry>
|
|
<entry>Sun DB-25 Male Pin</entry>
|
|
<entry>RS232 Signal</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>Blue</entry>
|
|
<entry>DCD</entry>
|
|
<entry>20</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>Orange</entry>
|
|
<entry>RTS</entry>
|
|
<entry>5</entry>
|
|
<entry>CTS</entry>
|
|
</row>
|
|
<row>
|
|
<entry>3</entry>
|
|
<entry>Black</entry>
|
|
<entry>Chassis Gnd</entry>
|
|
<entry>1</entry>
|
|
<entry>Chassis Gnd</entry>
|
|
</row>
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>Red</entry>
|
|
<entry>TxD</entry>
|
|
<entry>3</entry>
|
|
<entry>RxD</entry>
|
|
</row>
|
|
<row>
|
|
<entry>5</entry>
|
|
<entry>Green</entry>
|
|
<entry>RxD</entry>
|
|
<entry>2</entry>
|
|
<entry>TxD</entry>
|
|
</row>
|
|
<row>
|
|
<entry>6</entry>
|
|
<entry>Yellow</entry>
|
|
<entry>Signal Gnd</entry>
|
|
<entry>7</entry>
|
|
<entry>Signal Gnd</entry>
|
|
</row>
|
|
<row>
|
|
<entry>7</entry>
|
|
<entry>Brown</entry>
|
|
<entry>CTS</entry>
|
|
<entry>4</entry>
|
|
<entry>RTS</entry>
|
|
</row>
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry>White</entry>
|
|
<entry>RTS</entry>
|
|
<entry>8</entry>
|
|
<entry>DCD</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Note that colours may be different for your
|
|
cables/headshells. In particular, pin 8 may be grey instead of
|
|
white.</para>
|
|
|
|
<para>Remember to label the headshell
|
|
<emphasis>clearly</emphasis>, in a way that will not fade/fall
|
|
off/rub off with time!</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Cisco 16xx/26xx/36xx Routers</term>
|
|
|
|
<listitem>
|
|
<para>I think that all Cisco gear that has RJ-45 console ports and
|
|
runs &ios; will have the same cable requirements. But best to
|
|
check first. We have tried this on 1600s and 2600s only.</para>
|
|
|
|
<para>Both the Stallion card and the 2600 have RJ-45 connections,
|
|
but of course they are not compatible. So you need to crimp up
|
|
a special RJ-45-RJ-45 cable. And this cable must be plugged in
|
|
the right way round! We use normal RJ-45 flyleads from the
|
|
router to the patch panel, then the special flylead from the
|
|
patch panel to the Stallion card.</para>
|
|
|
|
<para>We built two special Stallion-Cisco leads by cutting in half
|
|
a 2m flylead and crimping an RJ-45 with the appropriate pinouts
|
|
to each free end. The original connector will be the Cisco end
|
|
of the cable, the new crimped connector will be the Stallion
|
|
end. Holding the RJ-45 connector on the flylead with the cable
|
|
pointing down and the clip pointing away, this is the order of
|
|
the colours of the cables in our flylead (pins 1-8, from L to
|
|
R): white/green, green, white/orange, blue, white/blue, orange,
|
|
white/brown, brown. For the Stallion end, trim and discard the
|
|
brown/white+brown and green/white+green pairs. Then holding the
|
|
RJ-45 plug in the same manner (cable down, clip away), the
|
|
connections should be (from L to R): None, None, Blue, Orange,
|
|
White/Orange, White/Blue, None, None, as shown:</para>
|
|
|
|
<table>
|
|
<title><!-- XXX: add title for this table --></title>
|
|
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry>Cisco RJ-45 Pin</entry>
|
|
<entry>Colour</entry>
|
|
<entry>Cisco Signal</entry>
|
|
<entry>Stallion RJ-45 Pin</entry>
|
|
<entry>Stallion Signal</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>White/Green</entry>
|
|
<entry>RTS</entry>
|
|
<entry>N/C</entry>
|
|
<entry> </entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>Green</entry>
|
|
<entry>DTR</entry>
|
|
<entry>N/C</entry>
|
|
<entry> </entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>3</entry>
|
|
<entry>White/Orange</entry>
|
|
<entry>TxD</entry>
|
|
<entry>5</entry>
|
|
<entry>RxD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>Blue</entry>
|
|
<entry>Gnd</entry>
|
|
<entry>3</entry>
|
|
<entry>Gnd</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>5</entry>
|
|
<entry>White/Blue</entry>
|
|
<entry>Gnd</entry>
|
|
<entry>6</entry>
|
|
<entry>Gnd</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>6</entry>
|
|
<entry>Orange</entry>
|
|
<entry>RxD</entry>
|
|
<entry>4</entry>
|
|
<entry>TxD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>7</entry>
|
|
<entry>White/Brown</entry>
|
|
<entry>DSR</entry>
|
|
<entry>N/C</entry>
|
|
<entry> </entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry>Brown</entry>
|
|
<entry>CTS</entry>
|
|
<entry>N/C</entry>
|
|
<entry> </entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Note again that colours may be different for your
|
|
cables/headshells.</para>
|
|
|
|
<para>Carefully label the cable, and each end of the cable, and
|
|
test it. If it does not work, testing is
|
|
<emphasis>really</emphasis> hard as they do not make RJ-45
|
|
serial line testers!</para>
|
|
|
|
<para>Let me state this more strongly: Be <emphasis>very</emphasis>
|
|
sure that you label this cable in a way that is easily,
|
|
instantly and permanently recognisable as a special cable and
|
|
not easily confused with normal drop cables. Some suggestions
|
|
(from Hugh Irvine):</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Make them out of different coloured cable.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>For marking the ends, clear heat-shrink tubing slipped
|
|
over printed labels *before* putting on the connectors is
|
|
the best way I have seen for marking what they are.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You can also use Panduit or similar tags that you put on
|
|
with nylon tie straps, but I find the ink wears off the
|
|
tags.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Cisco &catalyst; switches</term>
|
|
|
|
<listitem>
|
|
<para>Astoundingly, the pinout on the console ports of the
|
|
&catalyst; switches is actually <emphasis>different</emphasis> to the
|
|
pinout used on the 26xx-series Cisco hardware. I think the way
|
|
to tell which is which is by considering the operating software.
|
|
If it uses &ios;, then the previous pinout is required. If it
|
|
uses the switch software, then this pinout is required.</para>
|
|
|
|
<para>Fortunately, while the pinouts are different, the &catalyst;
|
|
pinout is simply a mirror image of the pinout for the 2600.
|
|
Even more fortunately, the Ciscos (both &catalyst; switches and 2600s)
|
|
seem to ship with a special <quote>rollover</quote> cable, which
|
|
is exactly what is required in this case. We use the rollover
|
|
cable from the &catalyst; switches to the patch panel, then the same cable
|
|
as above for the 2600s from the patch panel to the Stallion
|
|
card, and it all works just fine.</para>
|
|
|
|
<para>This rollover cable is an RJ-45-RJ-45 cable and is intended
|
|
to be used with the shipped (hardwired) RJ-45 - DB-25 and
|
|
RJ-45–DB-9 headshells for console connections. Ours are
|
|
2m long, either light blue or black, and are quite flat.
|
|
Attempts to use them for 100baseT Ethernet will fail miserably!
|
|
You can tell it is a rollover cable by holding both ends with
|
|
the cable pointing down and the clip pointing away from you.
|
|
Check the colour of the leads in each pin in the two connectors,
|
|
they should be mirror images. (In our case, one goes
|
|
grey-orange-black-red-green-yellow-blue-brown, the other
|
|
brown-blue-yellow-green-red-black-orange-grey). This is a
|
|
rollover cable.</para>
|
|
|
|
<para>If you do not have a rollover cable present, then you can
|
|
use the same cable as for the 26xx except plug it in the other
|
|
way around (i.e. original 8-pin plug goes into the Stallion, the
|
|
new crimped plug with only 4 active wires goes into the
|
|
&catalyst; switch).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&os; servers (or any other &i386; PC systems using a serial
|
|
console)</term>
|
|
|
|
<listitem>
|
|
<para>We run &os; 4 on a couple of &i386; PCs for various peripheral
|
|
uses. &os; usually uses a screen and keyboard for the
|
|
console, but can be configured to use a serial port (usually the
|
|
first serial port known as <devicename>COM1</devicename> in DOS/&windows; or
|
|
<devicename>ttyd0</devicename> in &unix;).</para>
|
|
|
|
<para>The cabling for these servers depends on the PC harware. If
|
|
the PC has DB-25 female socket on board (as most older PCs do),
|
|
then the same headshell as works for the Sun server above will
|
|
work fine. If the PC has DB-9 male plug on board (as more
|
|
recent PCs tend to do), then there are two choices. Either use
|
|
a DB-9 to DB-25 converter (this is not recommended as it can
|
|
lead to unreliable connections over the long term as the adapter
|
|
is bumped/works loose), or build an RJ-45 to DB-9 cable as
|
|
follows:</para>
|
|
|
|
<table>
|
|
<title><!-- XXX: add title for this table --></title>
|
|
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry>Stallion RJ-45 Pin</entry>
|
|
<entry>Colour</entry>
|
|
<entry>Signal</entry>
|
|
<entry>PC DB-9 Female Pin</entry>
|
|
<entry>RS232 Signal</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>1</entry>
|
|
<entry>Blue</entry>
|
|
<entry>DCD</entry>
|
|
<entry>4</entry>
|
|
<entry>DTR</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>2</entry>
|
|
<entry>Orange</entry>
|
|
<entry>RTS</entry>
|
|
<entry>8</entry>
|
|
<entry>CTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>3</entry>
|
|
<entry>Black</entry>
|
|
<entry>Chassis Gnd</entry>
|
|
<entry>N/C</entry>
|
|
<entry> </entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>4</entry>
|
|
<entry>Red</entry>
|
|
<entry>TxD</entry>
|
|
<entry>2</entry>
|
|
<entry>RxD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>5</entry>
|
|
<entry>Green</entry>
|
|
<entry>RxD</entry>
|
|
<entry>3</entry>
|
|
<entry>TxD</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>6</entry>
|
|
<entry>Yellow</entry>
|
|
<entry>Signal Gnd</entry>
|
|
<entry>5</entry>
|
|
<entry>Signal Gnd</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>7</entry>
|
|
<entry>Brown</entry>
|
|
<entry>CTS</entry>
|
|
<entry>7</entry>
|
|
<entry>RTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>8</entry>
|
|
<entry>White</entry>
|
|
<entry>RTS</entry>
|
|
<entry>1</entry>
|
|
<entry>DCD</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>See <xref linkend="freebsd"> for tips on configuring &os;
|
|
to use a serial console.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="solaris">
|
|
<title>On Sun Systems And Break</title>
|
|
|
|
<para>Anyone who has turned off a terminal used as a console for a Sun
|
|
system will know what happens and why this is a problem. Sun hardware
|
|
recognises a serial <literal>BREAK</literal> as a command to halt the
|
|
OS and return to the ROM monitor prompt. A serial <literal>BREAK</literal>
|
|
is an out-of-band signal on an RS-232 serial port that involves making
|
|
the TX DATA line active (i.e. pulled down to less than -5v) for more than
|
|
two whole character times (or about 2ms on a 9600bps line).
|
|
Alas, this <literal>BREAK</literal> signal is all to
|
|
easily generated by serial hardware during power-on or power-off. And
|
|
the Stallion card does, in fact, generate breaks when the power to the
|
|
PC fails. Unless fixed, this problem would mean that every Sun box
|
|
connected to the console server would be halted whenever the power
|
|
failed (due to dead power supplies, or fat-fingered operators unplugging
|
|
it, or whatever). This is clearly not an acceptable situation.</para>
|
|
|
|
<para>Fortunately, Sun have come up with a set of fixes for this. For
|
|
&solaris; 2.6 and later, the <command>kbd(1)</command> command can be used
|
|
to disable the <literal>ROM-on-BREAK</literal> behaviour. This is a good start,
|
|
but leaves you out of luck in the situation where a break is needed to get into a
|
|
broken machine.</para>
|
|
|
|
<para>Starting with &solaris; 8, the <command>kbd</command> command can also
|
|
be used to enable an alternate break sequence using the
|
|
<command>kbd -a alternate</command> command.
|
|
When this is set, the key sequence
|
|
<keycap>Return</keycap><keycap>Tilde</keycap><keycombo><keycap>Ctrl</keycap><keycap>B</keycap></keycombo>
|
|
(within 5 seconds) will drop to the ROM. You can enable this
|
|
permanently by editing the <filename>/etc/default/kbd</filename> file;
|
|
see the <literal>kbd(1)</literal> man page. Note that this alternate
|
|
break sequence is only active once the kernel has started running
|
|
multiuser and processed the default file. While the ROM is active
|
|
(during power-on and during the boot process) and while running
|
|
single-user, you still need to use a <literal>BREAK</literal> to get to the ROM prompt.
|
|
The console client can cause the server to send a <literal>BREAK</literal> using the escape
|
|
sequence
|
|
<keycap>Esc</keycap><keycap>c</keycap><keycap>l</keycap><keycap>1</keycap>.</para>
|
|
|
|
<para>If you have a Sun software support contract, there are patches
|
|
available for &solaris; 2.6 and 2.7 that add the <quote>alternate
|
|
break</quote> capability integrated into &solaris; 2.8. &solaris; 2.6
|
|
requires patch 105924-10 or higher. &solaris; 2.7 requires patch 107589-02
|
|
or higher.</para>
|
|
|
|
<para>We have added this patch to all our &solaris; 2.6 servers, and added
|
|
it (and the entry in the /etc/default/kbd file) to our jumpstart
|
|
configuration so it will automatically be added to every new
|
|
install.</para>
|
|
|
|
<para>We have confirmed by direct testing that neither the Cisco 16xx,
|
|
26xx, or &catalyst; hardware suffers from the <literal>BREAK</literal> sent
|
|
when the Stallion card loses power. Contemporary Cisco software listens
|
|
for <literal>BREAK</literal> signal only for first 30 seconds after
|
|
power-on or reboot.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="freebsd">
|
|
<title>Using a Serial Console on &os;</title>
|
|
|
|
<para>The procedure for doing this is described in detail in the
|
|
<ulink url="&url.books.handbook;/serialconsole-setup.html">&os;
|
|
Handbook</ulink>. This is a quick summary.</para>
|
|
|
|
<sect2 id="freebsd-kernconf">
|
|
<title>Check the kernel configuration</title>
|
|
|
|
<para>Check that the kernel configuration file has
|
|
<literal>flags 0x10</literal> in the config line for the
|
|
<devicename>sio0</devicename> device. This signals this device (known
|
|
as <devicename>COM1</devicename> in DOS/&windows; or
|
|
<devicename>/dev/ttyd0</devicename> in &os;) can be used as a
|
|
console. This flag is set on the <filename>GENERIC</filename> and
|
|
<filename>LINT</filename> sample configs, so is likely to be set in
|
|
your kernel.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="freebsd-bootconf">
|
|
<title>Create the <filename>/boot.conf</filename>
|
|
file</title>
|
|
|
|
<para>This file should be created containing a single line containing
|
|
just <quote><literal>-h</literal></quote> (minus the quotes). This
|
|
tells the &os; boot blocks to use the serial console.</para>
|
|
</sect2>
|
|
|
|
<sect2 id="freebsd-ttys">
|
|
<title>Edit <filename>/etc/ttys</filename></title>
|
|
|
|
<para>Edit this file and make the following changes.</para>
|
|
|
|
<para>If you are not going to have any keyboard/video screen on this
|
|
server at all, you should find all the lines for
|
|
<devicename>ttyv</devicename> devices like</para>
|
|
|
|
<programlisting>ttyv1 "/usr/libexec/getty Pc" cons25 on secure</programlisting>
|
|
|
|
<para>Change the <literal>on</literal> to <literal>off</literal>. This
|
|
will stop login screens being run on the useless video
|
|
consoles.</para>
|
|
|
|
<para>Find the line containing <devicename>ttyd0</devicename>. Change
|
|
it from</para>
|
|
|
|
<programlisting>ttyd0 "/usr/libexec/getty std.9600" dialup off secure</programlisting>
|
|
|
|
<para>to</para>
|
|
|
|
<programlisting>ttyd0 "/usr/libexec/getty std.9600" vt100 on secure</programlisting>
|
|
|
|
<para>(replacing <literal>vt100</literal> with the term type of your
|
|
console. The <literal>xterms</literal> terminal type might be a good
|
|
choice). This allows you to log in to the console port once the
|
|
system is running multi-user.</para>
|
|
|
|
<para>Reboot and off you go!</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="security">
|
|
<title>Security Implications</title>
|
|
|
|
<para>The client-server protocol for <application>conserver</application>
|
|
requires the user of the <application>console</application> client to
|
|
enter a password. This password is passed across the net in
|
|
<emphasis>cleartext</emphasis>! This means
|
|
<application>conserver</application> is not really suitable for use
|
|
across untrusted networks (such as the Internet). Use of conserver-only
|
|
passwords (in the <filename>conserver.passwd</filename> file) slightly
|
|
mitigate this problem, but anyone sniffing a
|
|
<application>conserver</application> connection can
|
|
easily get console access, and from there prang your machine using the
|
|
console break sequence. For operating across the Internet, use
|
|
something secure like <application>SSH</application> to log into to the
|
|
server machine, and run the console client there.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="conserver-versions">
|
|
<title>On Conserver Versions</title>
|
|
|
|
<para>The <application>conserver</application> program has fractured into
|
|
a number of versions. The home page referenced below seems to be the
|
|
latest and most featureful version around, and for July 2004 carries a version number
|
|
of <quote>8.1.9</quote>. This is maintained by Bryan Stansell
|
|
<email>bryan@conserver.com</email>, who has brought together the work of
|
|
many people (listed on his webpage).</para>
|
|
|
|
<para>The &os; ports collection contains a port for version 8.5 of
|
|
<application>conserver</application> at
|
|
<filename role="package">comms/conserver</filename>.
|
|
This seems to be older and less featureful than the 8.1.9
|
|
version (in particular, it does not support consoles connected to
|
|
terminal server ports and does not support a
|
|
<filename>conserver.passwd</filename> file), and is written in a fairly
|
|
idiosyncratic manner (using a preprocessor to generate C code). Version
|
|
8.5 is maintained by Kevin S. Braunsdorf
|
|
<email>ksb+conserver@sa.fedex.com</email> who did most of the original
|
|
work on <application>conserver</application>,
|
|
and whose work Bryan Stansell is building on. The
|
|
8.5 version does support one feature not in the 8.1.9 version
|
|
(controlling power to remote machines via a specific serial-interfaced
|
|
power controller hardware).</para>
|
|
|
|
<para>Beginning with December 2001, Brian's version (currently 8.1.9) is
|
|
also presented in ports collection at
|
|
<filename role="package">comms/conserver-com</filename>. We therefore
|
|
recommend you to use this version as it is much more appropriate for
|
|
console server building.</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="links">
|
|
<title>Links</title>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><ulink url="http://www.conserver.com/"></ulink></term>
|
|
|
|
<listitem>
|
|
<para>Homepage for the latest version of <application>conserver</application>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="ftp://ftp.conserver.com/conserver/conserver-8.1.9.tar.gz">ftp://ftp.conserver.com/conserver/conserver-8.1.9.tar.gz</ulink></term>
|
|
|
|
<listitem>
|
|
<para>The source tarball for version 8.1.9 of
|
|
<application>conserver</application>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="http://www.stallion.com/"></ulink></term>
|
|
|
|
<listitem>
|
|
<para>Homepage of Stallion Technologies.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="http://www.conserver.com/consoles/msock.html"></ulink></term>
|
|
|
|
<listitem>
|
|
<para>Davis Harris' <quote>Minor Scroll of Console Knowledge</quote>
|
|
contains a heap of useful information on serial consoles and
|
|
serial communications in general.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="http://www.conserver.com/consoles/"></ulink></term>
|
|
|
|
<listitem>
|
|
<para>The <quote>Greater Scroll of Console Knowledge</quote>
|
|
contains even more specific information on connecting devices to
|
|
various other devices. Oh the joy of standards!</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="http://www.eng.auburn.edu/users/doug/console.html"></ulink></term>
|
|
|
|
<listitem>
|
|
<para>Doug Hughes has a similar console server, based on the
|
|
<application>screen</application> program and an old &sunos; host.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><ulink url="http://www.realweasel.com/"></ulink></term>
|
|
|
|
<listitem>
|
|
<para>The Real Weasel company makes a ISA or PCI video card that
|
|
looks like a PC video card but actually talks to a serial port.
|
|
This can be used to implement serial consoles on PC hardware for
|
|
operating systems that can not be forced to use serial console
|
|
ports early enough.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
|
|
</variablelist>
|
|
</sect1>
|
|
|
|
<sect1 id="manpages">
|
|
<title>Manual Pages</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><ulink url="http://www.conserver.com/docs/console.man.html">console(8)</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><ulink url="http://www.conserver.com/docs/conserver.man.html">conserver(8)</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><ulink url="http://www.conserver.com/docs/conserver.cf.man.html">conserver.cf(5)</ulink></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
</article>
|