![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||
|
Hi Maren, Have a look at conserver [1]. This is - yes, another layer that needs to be configured. Still, its most important ability is to unify access to different kinds of console connections. On the console-connection side, it supports everything from serial line over telnet, plain TCP to ssh, while providing a single TCP based access interface to clients, i.e. operators and controls people. If configured correctly, the "console <iocname>" command anywhere in the controls network will put you on the IOC console, no matter if it is a soft IOC under procServ or screen, a VME CPU through a console switch or a local USB to a RaspberryPi. All the client needs to know is the IOC name. Only one user will have write access to a console, but others can see what's happening (read-only), who is using the line with write access and - most importantly - bump that blocking user out of the connection grabbing write access. Other goodies include unified logging/timestamping of all connections, security (SSL) for the client connection and PAM support for authentication/authorization. It adds complexity, needs configuration, is somewhat outdated - but it is pretty much exactly what you want for IOC console access in a large heterogeneous system. Test it and decide if the additional maintenance effort pays for the advantages you get. Cheers, ~Ralph On Thu, 26 Jan 2023 at 02:19, Maren Purves via Tech-talk <tech-talk at aps.anl.gov> wrote:
| ||||||||||||||
ANJ, 27 Jan 2023 |
![]() · Download · Search · IRMIS · Talk · Documents · Links · Licensing · |