Hello,
On Wed 30 Dec 2009 2:07:16 Frank Lin PIAT wrote:
I am curious why ssh+screen can't do the job? It would be much more
secure than telnet. It would be nice to add a note in the package
description.
Also it is much more "à la unix" to use two tools together to do one
job, each one doing one thing well.
Here's a bit of background:
procServ origins as a tool for the open source accelerator and physics
control system software EPICS (http://www.aps.anl.gov/epics). In that
context it is mainly used to run "soft" EPICS I/O processes in the
background, while giving access to the console (stdin/stdout) of the
process through a local telnet port. These soft IOC (input/output
controller) processes are doing real-time (as fas as Linux allows)
stuff, are heavily multi-threaded, doing lots of socket-based IO.
The other, "hard" IOCs in control systems are usually VME-based systems
running a real-time OS, with their serial console wired to a terminal
server, that allows telnet access. (Some with, most without authentication.)
A ssh/screen combination was used to run the soft IOCs in the beginning,
but we had many reports that using nifty features of screen (like
browsing the history buffer) would stall threads and eventually crash
the child process. Also (to provide the rich set of features), screen
always assumes the connecting terminal is interactive and understands
VT100 escape sequences, which is not the case when using a more generic
console access and logging facility like conserver, where connecting to
screen sessions fill up log files with escape sequences that make
viewing the log impossible.
So to make things simpler, a lot more stable, and actually more "à la
unix", procServ was created as a small, simple facility that runs a
child process and connects the console to a telnet server, and that's
it. No history browsing, no authentication, no multiple, named,
individually colored background sessions, no terminal escape sequences.
It adds some system-service level features that screen misses, like
restarting the child manually or automatically (with a grace period),
blocking characters that could kill the child, creating PID files, etc.
To keep things secure, procServ only allows telnet connections from
localhost, so the suggested tool chain is
conserver(/ssh/)telnet/procServ: conserver doing multi-user mode,
authentication/authorization, central logging, etc., either running
locally (connecting by telnet to procServ), or remote (connecting by ssh
then telnet to procServ). Within a control system, the use of conserver
allows to integrate the "hard" and "soft" IOCs in exactly the same
fashion, i.e. access to the console, log files etc. is the same for VME
real-time and Linux soft real-time IOCs.
Ralph
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
