Re: Serial port access and loging services for IOCs?

[Ralph Lange <Ralph.Lange@bessy.de>]

Have a look at conserver (a free tool available at www.conserver.com):

--- snip ---
Conserver is an application that allows multiple users to watch a serial 
console at the same time. It can log the data, allows users to take 
write-access of a console (one at a time), and has a variety of bells 
and whistles to accentuate that basic functionality. The idea is that 
conserver will log all your serial traffic so you can go back and review 
why something crashed, look at changes (if done on the console), or tie 
the console logs into a monitoring system (just watch the logfiles it 
creates). With multi-user capabilities you can work on equipment with 
others, mentor, train, etc. It also does all that client-server stuff so 
that, assuming you have a network connection, you can interact with any 
of the equipment from home or wherever.
--- snip ---

So its basic functionality is similar to iocConsole, but it offers:

   * write access only to one client, others get a read-only
     connection, but may force a takeover
   * ssh/ssl access from the client program (running on your office
     machine) to the console-server (that provides the access to IOCs)
   * access control configuration that allows definition of users
     (groups) that may be assigned a password to get specified access
     (r/o or r/w) to specified groups of serial lines
   * for each serial: configurable commands how to re-connect to it, in
     case the connection is down or the console-server was restarted
   * rotated log files, either per serial line or combined
   * you can configure multiple console-servers to accept all
     connections and forward connections to serials that are not local
     to the "real" host of that serial line.

We use it for over a year now, and it's just marvelous.

vxWorks IOCs are connected to through terminal servers (via telnet to 
the terminal server), soft IOCs are started with screen and connected to 
using ssh: one pseudo user per IOC on the soft IOC host machine, the 
authorized_keys file restricts access to the console-server and starts 
the screen client (in your case probably "cu"), so that the 
console-server just has to ssh to the soft IOC host with the right user 
name.

We keep daily per-IOC logs for a month, plus a weekly combined log of 
all IOCs (actually one for each group, such as controls, diagnostics, 
beamlines). All log files are accessible through a web server (just a 
regular one with trivial configuration).

There are matching tools available that grep through the log files, and 
may execute commands (as writing mails, send SMS ...) when they "see" 
certain things in a log file. We didn't start using these, though. Yet, 
maybe.

Hope this helps,
Ralph

ps. This tool could also be very interesting for your IT guys 
(monitoring server farms, switch hardware and such) - in our case that's 
where I got the idea and lots of support from.


Thompson, David H. wrote:
> Here at SNS we have lately had problems with IOCs crashing without 
> leaving any trail for analyzing what the problem was.  We have our own 
> home grown procServe and we are looking into the iocConsole/screen 
> software that SLAC is using.  We are different from SLAC in that we 
> use Digi port servers with a driver on one of the linux servers that 
> maps port server ports into local /dev/ttyXXNNN devices.  We just use 
> 'cu' to open a serial port.  IocConsole does not support that but 
> making it do so would not be hard I don't think.
>  
> Looks like a modified iocConsole is our best option but before we 
> commit to it we thought we out to see what others are doing to capture 
> the last few lines of terminal activity from running and crashed hard 
> IOCs.
>  
> Any ideas?
>