OVERVIEW Hopefully, you already understand the general idea, but just to make sure: The idea is you have a big network. You have several machines whose consoles you want to access remotely. You connect the console lines of these machines to serial ports on another machine, which runs the server half of our software. Then you can use the client program to get at the consoles from anywhere in the network. It also provides log file of the consoles. Send questions, comments, and bug reports to: fine@cis.ohio-state.edu WHAT YOU GOT Here's what you should have from the shar file: README (obviously) NEWSTUFF comments on some recent changes Sun-serial a description on wiring up finicky Suns mips a description of compiling on a MIPS Magnus 3000 (description is based on older version of console server) paper.asc plain text version of LISA paper. Makefile first attempt at a Makefile console.c client sources conserver.c server sources cons.h source configuration constab sample config file console.1 man pages constab.5 conserver.8 BUILDING and INSTALLING First off, this stuff isn't guarenteed to work, or compile or anything. Second, the makefile doesn't even really do that much, because most people with large networks don't have very normal configurations (that's alot like an excuse :-). Third, I assume you have the hardware set up done, and don't need any help there. With that out of the way, let's get started. First, edit cons.h to your desires. It should be self-explanatory. Next, edit Makefile, setting DMNDIR, BINDIR, MANDIR, CTAB, and GRP. Also self-explanatory. Type "make". This compiles the client and server. The server program, conserver, will compile under SUNOS 3.5.1, 4.0.1, and 4.1. It will probably compile under most similar UNIXs, but I have nothing to base this assumption on. The client program, console, should compile without any problems on most UNIX systems. It's been done on pyramids, HPs, an Encore Multimax, and Suns running SUNOS 3.5.1, 4.0.1, and 4.1. If things don't go so well, it's mostly up to you to figure out why, but drop me a note anyway, and I'll see what I can do. If everything goes well, type "make install". (Oh, yeah, you may want to change the "FILES" section in the man page "conserver.8" first.) You'll probably need to run this as root, depending on where you're putting stuff. This only installs things on the local machine (unless you have a kinky system configuration). You will have to distribute at least the client program to your other machines. "make install" assumes the following: 1. You run it on the machine which will act as the console server. 2. You have a fairly typical man page configuration (i.e. MANDIR/man[1-8]/man_page.[1-8]). 3. You don't need/want the executables to be world readable/executable. 4. You are going to use the names "console" and "conserver" for the client and server executables. "make install" also creates a file called rc.local.add-on which is something you can theoretically use to start the console server automatically by adding it into your /etc/rc files somewhere. Edit /etc/constab (on the machine which will be the console server), and create whatever directories you need for the log files. To start the server you can just run conserver. To use it run console. Reading the man pages first, and the following section here, are highly recommended. If you are going to run more than one console server, you will need to install different /etc/constab files on each console server. ADMINISTRIVIA Permissions The console server does not need to be run as root. As long as it has permissin to write to all the log files, any id will be fine. Keep in mind, though, that log files occasionally end up with sensitive data in them (like root passwords when people don't watch for the password prompt). Console server process management conserver (usually) ends up running several process: one master and several children. Each of the children is responsible for some of the consoles. Occasionally, we've had problems with one of the children becoming "stuck" in one sense or another. To make dealing with this easier the console server does several things: 1. If it is started with an argument, all the child processes will try to change their arguments to say which machines they are serving. It is important to provide an argument that has enough space for all the machine names. Also note that if the damn thing dumps core everytime it starts a child, this is the first piece of code to comment out. 2. If any child dies, the master process will start another one to replace it. So if you have a process which is "stuck" it is now easy to identify, and easy to restart (kill it). 3. If you need to restart everything, killing the master process with a SIGTERM (the default for kill) will tell the master process to kill everything (including itself). (But it can't restart itself once it's dead ;-) Log file time stamping We use a simple script like this, which we start from rc.local, to time-stamp the files from all the machines that don't time-stamp already. Using this script has the advantage that it doesn't write to the console, only the log file, so it doesn't interrupt what is happening on the console, if someone is using it. Here's the script, just for fun. #!/bin/sh #make a vain attempt to line up on the hour min=`date +%M` sec=`date +%S` dt=`echo 3600-\($min\*60+$sec\) | bc` sleep $dt while [ 1 ] do a="`date`" #change this line to suit your needs for file in logfile1 logfile2 do echo \[$a\] >> $file done #sleep for nearly an hour sleep 3598 done Strange bug There is an odd problem involving SunOS 3.5.1 (maybe others), tcsh, and terminals which have meta keys. The symptom is repeated data appearing. The fix is to convince tcsh that your terminal doesn't have a meta key. Strange.