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