After playing with this for a while, I’ve finally decided to share with the community a service that provide tokens for the websocketproxy used by Sunstone to serve the VM console via noVNC.
In the current OpenNebula implementation the VNC console is tightly linked to the Sunstone interface and it is the only way to access it due to the fact that only Sunstone generates the access tokens for the websocketproxy.
The proposed addon, written as a Ruby’s Sinatra application provide a single XML-RPC method that can generate websocketproxy tokens and provide them in the method response. There are hints in the README file how to configure Nginx to proxy both OpenNebula’s API and this addon API via a single SSL protected port. A complete example nginx configuration file is included in the repository too.
This way any external billing/management system could have access to all needed details to build a VNC session for a given VM without the need to create a user in OpenNebula/Sunstone.
Please note that this service works in parallel with Sunstone so only the last generated token will be valid. A running Sunstone service is needed anyway because it is managing the novnc service that provide the websocketproxy.
As I am not native Ruby programmer any feedback is welcome.
Hi Anton Todorov,
I’m didn’t installing it.
The issue I am having is in order to access the VNC URL the user must be authenticated via sunstone however I am trying to avoid this as the user is logging in twice.
Just to clarify - the end user communicate with the billing interface only, right? And the billing communicates with OpenNebula XML-RPC2 API.
This addon creates an additional XML-RPC2 API endpoint, that is working with the same credentials as the OpenNebula XML-RPC2 API and there is a method to request a vnctoken for a given VM that you should provide on the vnc URL.
Please take a thorough look at the addon and the provided examples.
With OpenNebula, the process of establishing a VNC session is as follow
User requests a VNC session to the /vnc URL in sunstone
Sunstone generates a VNC token and return a page that has the noVNC javascripts and instruct them to connect to the opennebula-novnc service which actually is websockify listening by default on port 29876.
You could access directly the websockify service on port 29876 using noVNC scripts from the noVNC project instead of the one served by sunstone. All needed credentials but the vnctoken could be obtained via OpenNebula’s API. addon-vnctoken provide an API to request the missing vnctoken needed to complete the request to websockify.
This way sunstone is not used at all - the noVNC code on the billing communicate directly with the websockify service.
I did manage to get this working, setup websockify on my web server which then used the tokens generated by opennebula , the host that websockify connects to is pulled from opennebula api XML.
Secured with ssl using fortigate firewall as the reverse proxy and installing cert on there .
The tokens are generated by Sunstone only when a VNC session is requested via Sunstone. So the VMs created by an external billing that work only with the OpenNebula API has no VNC tokens generated. The addon-vnctoken solves this case by providing API to get a generated token when sunstone is not used at all.
Also, in your case the VNC tokens are same, not rotated unless VNC session is requested via sunstone regularly.
Hi @Endry_J! Now that you mention WHMCS… that’s an integration we’ve been thinking about for a while, as several users have shown interest in connecting OpenNebula with a billing platform. We were considering launching a community-led initiative for that. Is this something you would be happy to contribute to? It sounds your experience would be really helpful
I’m happy to see, opennebula team gonna launching community integration whmcs. And wishing i can share all my knowledge.
But as you can see, i’m in early stage.