FS Display Server

Traditional FS

eRemoteCtrl fixes some of these but...

• Main display views the log
• But not all errors go into the log, especially critical errors
• Silenced messages do go into the log
• FS is still attached to an X server — it crashes or you logout, the FS goes with you
• no fs.prompt and autoftp support

Field System display server

Design goals

• Prevent unintentionally exits of FS by making the core part in the background
• Multiplex the display rather than the log
• Simple interface — ideally operators won't even notice the difference
• Maintain compatibility for stations code
• Possibility different types of clients — text-only and browser based clients in mind
• fs.prompt and autoftp support

Non-goals

• Authentication + Access control — leave to be handled by OS or clients
• Special clients — first client is like any other

Display Server FS

Implementation

• fsserver acts like a terminal multiplexer (eg screen or tmux)
• fsserver runs the core FS programs in a "window": a pseudoterminal with the output streamed to the client(s)
• fsclient instances run the GUI FS programs
• other programs opened in xterm, eg autoftp, can be opened in separate windows and streamed to the clients
• all communication is performed via the nng library, which can transparently use websockets, unix, or tcp sockets.
• current implementation is using unix sockets for local only access
• JSON-RPC over a nng socket is used for commands
• Shipped in 9.13.0, disabled by default

Handling fs.prompt

When fs.prompt called from a child of FS in server mode

1. an fs.prompt shim is called rather than real fs.prompt (by adding to PATH)
2. fs.prompt shim messages fsserver with message string and whether to inject "cont" to fs
3. fsserver broadcasts the prompt properties to all clients with a unique ID
   interpretation is left up to client; reference client uses real fs.prompt
   future clients may handle differently
4. when one client fsserver broadcasts the prompt properties to all clients with a unique ID

Handling fs.prompt

autoftp and other terminal programs

• autoftp is started by boss in an xterm
• similar to fs.prompt, an xterm shim is adding to PATH by children fsserver
• this then starts the arguments to xterm in an fsserver window
• fsserver windows are non-interactive, and we don't (like to) break station code
• so we whitelist only known safe programs. Items not on the whitelist get the real xterm

• Shipped in 9.13.0, and 9.12.12!
• Plans for web and TUI clients
• Please give it a go!

End!