I'm a casual user of Foreman and appreciate the VNC console support you've
created. Thank you! However, I consistently run into the "insecure
websocket" issue and have to modify Firefox and Chrome to allow the
insecure connection.  I'd like to know if there are any plans to
change this, so that a browser with a default configuration /
security-profile can access the console. Or, perhaps my deployment is
incomplete, and some additional setup / configuration would secure this…
> insecure connection.  I'd like to know if there are any plans to
> change this, so that a browser with a default configuration /
> security-profile can access the console. Or, perhaps my deployment is
> incomplete, and some additional setup / configuration would secure this…
The issue is every single websocket connection resides on a different
port, because there are multiple people accessing multiple VMs at the
same time. For security reasons, browsers do not allow other origins or
the same origin but different (nonstandard) ports. It's a good practice.
We currently spawn websockify  process per each user attempting to
access VNC/Spice via Foreman. And each of those opens up new port. If we
are able to replace this with a single process running on a single
(standard HTTP) port and allowing dynamically reconfigure endpoints
somehow, then we might be able to workaround it.
Sorry to reply to such an old topic but, I’m running into the same issue, even more, running into the issue that my IT department is very hesitant to opening up such a “big” port-range (5900-5999) and as such I would like to volunteer to work on this topic. However, for my understanding:
Are there any requirements already listed somewhere?
Is somebody allready working on it? Perhaps we can join hands?
Currently I’m (roughly) thinking about doing the following:
Connect to single endpoint and use WSS if applicable
Add information to which port we would connect in the backend
Proxy data (or encapsulate) websockify and connect to hyper-visor from there
Am I missing something important? Am I going to tackle this to naively?
I understand the issue where the network team doesn’t want to open 100 ports. Here’s what I know
I don’t think any of the core devs is working on it, it is an important feature we all want to keep but it’s been a long while since we have made anything to improve it since we added WSS.
That wiki article looks like the way to go. Notice, though, that httpd + passenger does not handle websockets very well. (https://github.com/phusion/passenger/issues/1202). This means you’ll need a separate process to run these WSS connections, which is what we do now (we do a process per VM instead of 1 for all VMs though).
Currently we run websockify as a standalone process launched by Foreman. httpd + passenger is not involved since it opens its own socket. As I read it with this token based target selection we would actually run just 1 websockify process.
The token selection was not possible before but it looks like a good solution. I think it should be doable to always run a websockify process and have Foreman write token files for clients (or write a plugin to dynamically query Foremans API).
I’d also look into systemd socket activation to lazily start the websockify process but that’s an optimization.
It’s probably best to open a new RFC. I’ll gladly help you with the design and review the implementation.
Hi, thanks everyone for this input so far.
I’ve been on a (IMO) well-deserved holiday so I didn’t manage to follow up on this one.
I’ll create the RFC and will definitely take up the offer on teaming up on designing and reviewing this thing.
I’ll try to write down what I think is needed and file the RFC, I’ll aim to have some discussion material (in the form of the RFC) within 2 weeks from now.