It looks like a couple of projects are interested in using the noVNC viewer as a way of talking to machines from a web browser. I've made a first stab at packageing them, and, in doing so, learned a little bit.
The noVNC code is designed around a proxy that, under the Debian deploy, lives in /usr/share/noVNC/utils/. This directory contains shell scripts, a shared object complete with Makefile, and lots of python code. Needless to say, it does not match Fedora packaging standards.
It uses the Websocket protocol, which is not quite HTTP. Apache HTTPD does not support Websocket natively, although there is apparently a path to do so via http://code.google.com/p/pywebsocket/. However, the noVNC approach is to bundle a simple web server and websocket implementation. In addition, a python script called websockify handles SSL.
When deployed, the web proxy does not lock down browsing of sub dirs. When run from an init script that did not set cwd, it exposes the entire directory tree underneath. The normal usage is better: devstack runs $ cd /opt/stack/noVNC && ./utils/nova-novncproxy --config-file /etc/nova/nova.conf --web . Run this way, it only exposes the /usr/share/noVNC directory as read only, but really should not allow directory indexing. However, our current init script runs:
daemon --user nova --pidfile $pidfile "$exec --flagfile $config --logfile $logfile &>/dev/null & echo $! > $pidfile"
where $exec is /usr/bin/nova-vncproxy.
In my spec file, in order to match this, I moved the executables from /opt/stack/noVNC/utils to /usr/bin, but that does not seem like a good long term solution: they are generically named and should have novnc as part of their name as well.
I've also and renamed /opt/stack/noVNC/utils/nova-novncproxy to /usr/bin/nova-vncproxy which seems like it should not be necessary.
Currently, the Openstack specific code is in the upstream git repo for noVNC, but it really should be moved to the Nova git repository. I'll talk to the original author to find out his rationale, and to see if we can get it moved over.
I've posted my current work here http://admiyo.fedorapeople.org/noVNC/
But would not suggest that people use it yet. I am certainly willing to take feed back on the spec file:
http://admiyo.fedorapeople.org/noVNC/novnc.spec
Dan B suggested a few things that I'd like to record here:
1. Is there a need to create a novnc user with an empty home dir to run in? 2. The python code should be made into a site-package.
On Wednesday, April 25, 2012 04:08:41 PM Adam Young wrote:
It looks like a couple of projects are interested in using the noVNC viewer as a way of talking to machines from a web browser. I've made a first stab at packageing them, and, in doing so, learned a little bit.
The noVNC code is designed around a proxy that, under the Debian deploy, lives in /usr/share/noVNC/utils/. This directory contains shell scripts, a shared object complete with Makefile, and lots of python code. Needless to say, it does not match Fedora packaging standards.
Hello,
OpenNebula optionally uses noVNC but it downloads it with a script to /tmp and creates a symlink to /usr/share/one/noVNC vs packaging it. So I wonder how this would work in packaging.
On Wed, Apr 25, 2012 at 10:39:05PM -0400, Shawn Starr wrote:
On Wednesday, April 25, 2012 04:08:41 PM Adam Young wrote:
It looks like a couple of projects are interested in using the noVNC viewer as a way of talking to machines from a web browser. I've made a first stab at packageing them, and, in doing so, learned a little bit.
The noVNC code is designed around a proxy that, under the Debian deploy, lives in /usr/share/noVNC/utils/. This directory contains shell scripts, a shared object complete with Makefile, and lots of python code. Needless to say, it does not match Fedora packaging standards.
Hello,
OpenNebula optionally uses noVNC but it downloads it with a script to /tmp and creates a symlink to /usr/share/one/noVNC vs packaging it. So I wonder how this would work in packaging.
Well OpenNebula would just need to be changed to note download anything if it finds it already installed in /usr/bin
Daniel
On Wed, Apr 25, 2012 at 04:08:41PM -0400, Adam Young wrote:
Dan B suggested a few things that I'd like to record here:
- Is there a need to create a novnc user with an empty home dir to run in?
Unless there's a compelling reason for it to run as root, then I'd say this is a must-have - particularly given the horrible behaviour you describe wrt browsability of arbitrary filesystem paths.
- The python code should be made into a site-package.
More completely my suggestions would be
- Anything in /usr/bin must have a 'novnc-' prefix - names like 'web.py' 'rebind', etc are faaaaaar too generic to be going in /usr/bin. - Some of the python is both a command line tool & library module. The latter should really go into python site-lib - The entire thing needs integrating with autotools, or python distutils, so that upstream defines the correct install procedure. Without this everyone just reinvents installation in a different way. - As you say if nova-vncproxy is truely nova specific, it has no business being here - it should be in the openstack nova GIT repo and RPMs. If it is not nova specific, then it should be renamed to remove the 'nova-' name prefix
In terms of code bugs, rebind.c needs to be fixed to work with IPv6 too
Daniel
Trying to get the noVNC package into something that matches the Fedora Python pakcage specificiation.
1. Create a bin directory, and all shell scripts and executable python files go in there. These will get installed into /usr/bin. All the files in here will be prefixed by novnc-. nova-novncproxy is the exception ,as it will eventually move back to Nova. These are img2js.py, json2graph.py, launch.sh, u2x11, u2x11, websockify, rebind.
2. websocket.py. is a Python file that is both an execuatble and a module. It will get split into two parts. The module websocket.py will stay in the top level directory with a .py extension. The executable portion will go into bin as websockify. The module code will get installed into /usr/lib/python2.7/site-packages/.
3. All client side Javascript and html files will go into an html subfile. This includes the html and ico files in the top dir, and the subdirectories 'include' and 'images'.
4. rebind.so needs libtool support. It will get moved into a subdir name rebind. It will get installed into /usr/lib[64] as a versioned .so, probably 0.1.0
This will likely conflict with a future websocket RPM, but we'll burn that bridge when we get there.
For our purposes, we don't really need rebind, as we are not using it. I'm almost tempted to leave it out of the RPM. Dan B mentioned that it needs IPv6 support, but I don't think it is worth doing that right now.
The Init script for the VNC code is in Nova. Since daemon runs with --user nova, it should be run as a non-priveledged user, which means that it only has the problem of running in the wrong CWD. I suggest that we put
os.chdir(os.path.dirname(sys.argv[0]))
into nova-novncproxy.
On Wed, Apr 25, 2012 at 04:08:41PM -0400, Adam Young wrote:
It looks like a couple of projects are interested in using the noVNC viewer as a way of talking to machines from a web browser. I've made a first stab at packageing them, and, in doing so, learned a little bit.
Hi Adam. Any update on this? Your work is appreciated and eagerly anticipated. :)
On 06/07/2012 12:50 PM, Matthew Miller wrote:
On Wed, Apr 25, 2012 at 04:08:41PM -0400, Adam Young wrote:
It looks like a couple of projects are interested in using the noVNC viewer as a way of talking to machines from a web browser. I've made a first stab at packageing them, and, in doing so, learned a little bit.
Hi Adam. Any update on this? Your work is appreciated and eagerly anticipated. :)
I'll have an update tongiht/tomorrowish. I just took this back over (was supposed to hand it off, but the other engineer got other tasks) so it has been neglected for a couple of weeks.
-
Adam Young -
Daniel P. Berrange -
Matthew Miller -
Shawn Starr