path: root/en_US.ISO8859-1/articles/console-server/article.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
	"../../../share/xml/freebsd45.dtd">

<article lang='en'>
  <articleinfo>
    <title>Console Server</title>

    <author>
      <firstname>Gregory</firstname>
      <surname>Bond</surname>

      <affiliation>
	<address><email>gnb@itga.com.au</email></address>
      </affiliation>
    </author>

    <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>

    <pubdate>$FreeBSD$</pubdate>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <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
	  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/ &amp;&amp; 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.&nbsp;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:&amp;:
roo:/dev/cuaE1:9600p:&amp;:
kanga:/dev/cuaE2:9600p:&amp;:
%%
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>&amp;</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 = &lt;>;
`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.email; 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 &lt; /dev/cuaE7 opost onlcr
		echo -n ' conserver'
                ;;

        'stop')
		kill `cat /var/run/conserver.pid` &amp;&amp; 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-&lt;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&ndash;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"/>
	</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.&nbsp;<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>&nbsp;</entry>
		  </row>

		  <row>
		    <entry>2</entry>
		    <entry>Green</entry>
		    <entry>DTR</entry>
		    <entry>N/C</entry>
		    <entry>&nbsp;</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>&nbsp;</entry>
		  </row>

		  <row>
		    <entry>8</entry>
		    <entry>Brown</entry>
		    <entry>CTS</entry>
		    <entry>N/C</entry>
		    <entry>&nbsp;</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&ndash;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 hardware.  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>&nbsp;</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.&nbsp;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>