Packaging of noVNC and Websockets

[Adam Young]

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.

[Shawn Starr]

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.

[Daniel P. Berrange]

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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Daniel P. Berrange]

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:
>  
>  1. 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.

>  2. 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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Adam Young]

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.

[Matthew Miller]

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. :)

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences

[Adam Young]

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.