Serial Over Lan in the webui

[Deepak Kodihalli]

On 13/04/18 10:30 pm, Tanous, Ed wrote:
> I sent you a few replies on IRC, not sure if you saw any of them.  Some ideas are below.

Seem to have missed them.

>> -----Original Message-----
>> From: Deepak Kodihalli [mailto:dkodihal at linux.vnet.ibm.com]
>> Sent: Friday, April 13, 2018 2:59 AM
>> To: geissonator at gmail.com; Tanous, Ed <ed.tanous at intel.com>;
>> gmills at linux.vnet.ibm.com; jayashankar.padath at in.ibm.com; Brad Bishop
>> <bradleyb at fuzziesquirrel.com>
>> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
>> Subject: Serial Over Lan in the webui
>>
>> Based on my investigation, it might not be possible to get the SOL working in
>> the UI via the latter scenario. This is because it doesn't seem to be possible to
>> implement an ssh client with client-side html and javascript that a browser
>> can run by itself, and that's because javascript running in the browser doesn't
>> have raw tcp/ip socket support.
> 
> To my understanding, there is no way to implement browser WebUI based SSH in either scenario without a separate conversion to websockets, as I do not believe there is any browser support for the low level socket access you need to directly connect to an SSH socket.  As you said, you are running an intermediary on your development system to do this now, which doesn't work when deploying to the platform.
> 
>>
>> So the question is how do we solve this when the webui code is served by
>> the BMC?
> 
> You will need some way to transfer events (text) to the browser.  In order, my personal preference would be:
> 
> 1. Build a daemon that is capable of forwarding socket-like information over an authenticated websocket.  There are several examples of how to do this, Bmcweb has an example of sending VNC-like protocols over an authenticated websocket.  Rest-dbus has a websocket for transferring dbus eventing info.  You could use either of these as an example of how to build your own.

I implemented that websocket for the alerts, but you're right that I 
should be able to leverage/refer to that implementation. I was going to 
try that first, but will look at the other ideas that you've suggested 
as well.

> 2. Use something like SSE to transfer the buffers and forward the events.
> https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
> 3. Use long polling on a rest api to transfer buffers.
> https://www.pubnub.com/blog/2014-12-01-http-long-polling/
> 
>> Is anyone aware of a pure client-side javascript based ssh client? If
>> not, we'd have to run Node or something equivalent on the BMC
> You are free to do what you want, but I wouldn’t recommend this route, and would resist any attempts to put it in an upstream component patchset.  NodeJS is very heavyweight for running on the BMC hardware, in both flash usage and startup time, as it's jit compiling its sources using V8.  For something relatively simple (forwarding a serial interface to a websocket) I do not believe the infrastructure cost of maintaining nodejs on the BMC is warranted.

I agree, I just put that into perspective to stress the need of some 
server side work.

>> , or have
>> the REST server act as a proxy server between the terminal writing to a
>> socket that the rest server can intercept and convert to ssh packets. Any
>> other thoughts on how this can be achieved?
> 
> I would recommend going a level deeper, and avoid SSH altogether.  Directly connect the websocket to the interface that the SSH daemon is sourcing serial from.`

That sounds like a good idea, thanks!

Regards,
Deepak