SOL Logging

[Ed Tanous]

On 09/04/2018 05:07 PM, Emily Shaffer wrote:
> I wonder if there's a different and more useful way we can provide the 
> console scrollback. Thinking about this, it's not just a GUI issue, 
> right - we deliver our console over TCP to a client elsewhere and would 
> have the same dedupe issues if we needed to start providing backlog.  

Correct, this isn't _just_ a webui issue.  It happens on all the 
available interfaces (SSH, HTML5, and obmc-console-client)

> Speaking with almost no experience implementing server-side sockets, is 
> it possible for us to keep that ring buffer in the console socket as well?

obmc-console already keeps a ring-buffer style log of all the previous 
characters.  The easiest to implement answer, which is probably good 
enough for most cases, would be to simply make obmc-console barf up the 
saved console log ring buffer when any new client connects.  This will 
have problems if your control characters have run off the end of the 
buffer, and the console would appear to quickly replay your last X 
characters worth of interactions, which isn't desired.

I could also imagine a case where this isn't the desired behavior if 
you're using automation to interact with SSH/SOL, so it might need to be 
selectable by the client or have some kind of reasonable workaround.

I'm fairly certain there's some buffering routines we can steal from 
screen and/or tmux that would just track the screen state, and blast the 
minimum character sets to each client on reconnect, but I haven't looked 
into it too deeply.

> 
> I'm also interested in how you all are getting the console over to 
> webui.  Is it delivered via Redfish? (This is totally different from 
> what we are doing, so apologies if that's a fundamental question, but 
> I'm certainly keen to know now :) )
> 

Today the console is being dumped to a dumb websocket that just mirrors, 
encodes, and encrypts the traffic to the browser using websocket frames. 
  On the browser side, we pipe that console into hterm, which turns the 
raw characters into a reasonably correct console.

https://chromium.googlesource.com/apps/libapps/+/master/hterm

At some point there was talk of moving the html5 stuff over to xterm, to 
support more encoding styles, but I don't think anyone has started that 
work.