FreeBSD has adequate support for modern Stallion cards since 4.4 release. If you are running an older version of FreeBSD, you will need to upgrade to a more modern version of FreeBSD (which you should do anyway, to make sure your system is not vulnerable to known security issues). See the FreeBSD Handbook for information about updating your system.
The Stallion driver is not included in the default
GENERIC
kernel, so you will need to create a kernel
config file with the appropriate entries. See stl(4) and the
appropriate section of the FreeBSD
Handbook.
You will need to make the device notes for the Stallion card
(which are not made by default). A new version of
/dev/MAKEDEV
with Stallion support will have been
created by the mergemaster run during the
above procedure. If you have a Stallion card with more than 8 ports,
then you will need to edit /dev/MAKEDEV
and
change the definition of maxport
at about line 250.
By default, MAKEDEV
only makes device nodes for 8
ports to keep the size of the /dev
directory
down.
Run a command like:
#
cd /dev/ && sh MAKEDEV cuaE0
to create dial-out devices for the first Stallion card. See the
comments in MAKEDEV
and the stl(4) man page
for more details.
See the section on conserver versions Section 9, “On Conserver Versions”; the version I use is available in the FreeBSD ports collection; however, it is not the only one.)
There are two ways to install conserver. You can either compile from the source or use the FreeBSD ports framework.
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
comms/conserver-com
port.
Change into the
port directory and (as root
) type:
#
make DEFAULTHOST=consolehost
install
where consolehost
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
conserver.cf
file on every host. This command
will fetch, patch, configure, compile and install the
conserver application.
You can then run make package
to create a
binary package that can be installed on all the other FreeBSD hosts
with pkg_add(1). For extra style points, you can make a two
versions of the package: one for the console server machine without
a DEFAULTHOST
argument, and one for all the other
hosts with a DEFAULTHOST
argument. This will
mean the console client program on the console server machine will
default to localhost
, which will work in the
absence of name servers when the network is busted, and also allow
“trusted” (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
DEFAULTHOST
argument means users can just use the
console client without specifying a
hostname every time, and without needing to configure the
conserver.cf
file on every machine.
If you prefer, you can download conserver and compile it yourself. You might need to do this if you want to install the console client on non-FreeBSD systems. We run the client on our Solaris™ hosts and it inter-operates with the FreeBSD-hosted server with no problems. This allows anyone in the whole company (many of whom have PCs and no FreeBSD host access on their desk) to access the console server.
Download the file from the conserver.com FTP site. Extract it into a handy directory then configure it by running
%
./configure --with-master=consoleserver
--with-port=782
The --with-master
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
--with-port
argument avoids having to update
/etc/services
on every machine.
Then type make
and, as root,
make install
.
The conserver program is configured via a file called
conserver.cf
. This file usually lives in
/usr/local/etc
and is documented in the
conserver.cf(5) manual page.
Our config file looks like this:
The first line means all the console log files by default go into
the /var/log/consoles
directory. The
“&” in each line says the log file for that machine
will be
/var/log/consoles/
.machine
The next three lines show three machines to which we need to
connect. We use the
cuaE
devices
rather than the
x
ttyE
devices because console ports typically do not show carrier. This
means that opening
x
ttyE
would hang
and conserver would never connect. Using
the
x
cuaE
device avoids this problem. Another solution would be to use the
x
ttyE
devices and enable “soft carrier” on these ports, perhaps by
setting this using the
x
ttyiE
device in the x
/etc/rc.serial
file. See the
comments in this file for more details. Also see sio(4)
for information on the initial-state and locked-state devices. (The
Stallion driver also supports these conventions). And see the
stty(1) for details on setting device modes.
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
conserver.passwd
file (see next
section).
The conserver.passwd
file contains the
encrypted version of the password that each user. The file is
documented in the conserver.cf(5)
manual
page.
The only tricky bit is loading the file with encoded passwords. It appeared in FreeBSD 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:
This uses the FreeBSD MD5-style encrypted passwords. Running this on other UNIX® variants, or on FreeBSD with DES passwords, will likely need a different style of salt.
Kris Kennaway <kris@FreeBSD.org>
has since pointed out you can get the same effect using
the openssl passwd
command:
%
openssl passwd -1
Password: password
$1$VTd27V2G$eFu23iHpLvCBM5nQtNlKj/There are two ways this can be done. Firstly, you could start up
conserver from init
by including an entry in
/etc/ttys
that is similar to this:
This has two advantages: init 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
conserver
process to be directed to the named tty (in this case
cuaE0
). This is useful because you
can plug a terminal into this port, and the
conserver 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
conserver
from the ttys file is that it cannot run in daemon
mode (else init(8) would continually restart it). This means
conserver will not write a PID file,
which makes it hard to rotate the log files.
So we start conserver from an rc.d script.
If you installed conserver via the port,
there will be a
conserver.sh.sample
file installed in
/usr/local/etc/rc.d
. Copy and/or rename this to
conserver.sh
to enable conserver
to start at boot time.
In fact we use a modified version of this script which also
connects conserver to a terminal via a tty device so we can monitor
unwatched console output. Our conserver.sh
script looks like
this:
Note the use of cuaE0
device
and the need to set tty modes for proper NL-<CR
handling).
FreeBSD has a program called
newsyslog that will automatically
handle log file trimming. Just add some lines to the
configuration file /etc/newsyslog.conf
for the console logs:
This tells newsyslog (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 SIGHUP
to the process whose PID
is in the conserver.pid
file. This is the master server, and it will
arrange to signal all the child processes. Yes, this will send a HUP
to all clients whenever a single log file needs rotating, but that is
quite cheap. See newsyslog(8) for details.
This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/
For questions about FreeBSD, read the
documentation before
contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.