Bug 30540 - Integration eines JavaScript VNC-Clients in UVMM
Integration eines JavaScript VNC-Clients in UVMM
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Virtualization - UVMM
UCS 3.1
All Linux
: P5 enhancement (vote)
: UCS 3.2
Assigned To: Philipp Hahn
Lukas Walter
http://novnc.com/
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-21 14:09 CET by Malte S. Stretz
Modified: 2013-11-19 06:41 CET (History)
8 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Malte S. Stretz 2013-02-21 14:09:57 CET
+++ This bug was initially created as a clone of Bug #23303 +++

Es wäre schön wenn der Zugriff auf die via UVMM laufenden VMs statt über das Java-Applet (welches bei mir chronisch nicht läuft) oder über native VNC-Clients (für die ich immer die richtigen VNC-Ports für die jeweilige VM raussuchen muss) auch über eine JavaScript Lösung wie noVNC möglich wäre:
http://novnc.com/

Eine Alternative die keine Websockets benötigt wäre Guacamole aber da wird dann serverseitig ein Java-Proxy benötigt:
http://guac-dev.org/

Das Ganze wurde in Bug 23303 bereits andiskutiert.
Comment 1 Liam Schwez univentionstaff 2013-08-21 17:36:40 CEST
In noVNC (Version 0.4) (http://kanaka.github.io/noVNC/) in noVNC/util/launch.sh "websockify" should be called with parameter "--target-config='path_to_config_file'" to allow to define a list of target vnc connections. Config file format has to be:

token1: vnc_Server_host_1:vmc_vm_port_2
token2: vnc_Server_host_2:vmc_vm_port_2
token3: vnc_Server_host_3:vmc_vm_port_3

If using "vnc_auto.html" URL should look like this: "http:/noVNC:6080/vnc_auto.html?path=?token=token1" to pass the WebSocket request path for token1.
If you want to add a VNC-Password for a VM, modify "websockify" parsing algorithm for a config file and place a password into a config file. Then catch the password over URL in vnc_auto.html.


In noVNC web-console some problems with keynotes-shortcuts features were discovered:

In Windows-VM (Windows 7):
- no output for ~,^ and `´

In UCS (ucs 3.2.0):
- no functionality for "ALT", "ALT-F2", "F12", ~, `´ and ^.

In UCS-Installer (3.1):
 - instead of "Backspace" it is "ALT+Backspace"
 - No function for "ALT-F2" "ALT-etc."

To switch between top level windows instead of "ALT-TAB" push "Shift-TAB".
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2013-10-10 15:25:04 CEST
noVnc is currently under heavy development. It should be considered to use the latest git version from github.
Comment 3 Philipp Hahn univentionstaff 2013-10-13 22:14:54 CEST
(In reply to Liam Schwez from comment #1)
> websockify--target-config='path_to_config_file'

websockify is Python code and needs to be modified anyway:
1. Launch the proxy at some un-firewalled port or get it forwarded through Apache.
2. Make sure to keep it running.
3. Provide some mapping from VM to host:port, probably using the UUID by hooking it up to UVMMd. websockify currently already provides a mechanism to get the mapping from files in a directory, which is read freshly on each new connection.

> If using "vnc_auto.html" URL should look like this:
> "http:/noVNC:6080/vnc_auto.html?path=?token=token1" to pass the WebSocket
> request path for token1.

The trick here is to pass "token=XXX" as a additional request parameter, therefore the strange syntax of path='?tocken=XXX'. websockify contains code to get the token from the query-string, while vnc_auto.html contains code to pass the token through a cookie, which only seems to be relevant for the Nova-version.

> In noVNC web-console some problems with keynotes-shortcuts features were
> discovered:

These are the "normal" VNC issues:

> In Windows-VM (Windows 7):
> - no output for ~,^ and `´
> In UCS (ucs 3.2.0):
> - no functionality for "ALT", "ALT-F2", "F12", ~, `´ and ^.
> In UCS-Installer (3.1):
>  - instead of "Backspace" it is "ALT+Backspace"
>  - No function for "ALT-F2" "ALT-etc."

This is caused by a wrong keymap configuration for the VM in libvirt. After adding /domain/devices/graphics/@keymap='de' it worked for me.
But there are still issues, especially with AltGr: It worked with IceWeasel-24.0, but not with Chromium-29.0. There were patches to noVnc like <https://github.com/kanaka/noVNC/pull/191>, but at looks like it's very browser dependent, which is described in <https://github.com/kanaka/noVNC/wiki/KeyEvents>.

See <http://stackoverflow.com/questions/5306132/translate-javascript-keycode-into-charcode-for-non-u-s-keyboard-layout-i-e-az>.
Comment 4 Philipp Hahn univentionstaff 2013-10-13 22:38:30 CEST
The extension to VNC to send keycodes: <https://mail.gnome.org/archives/gtk-vnc-list/2008-January/msg00045.html>
Comment 5 Philipp Hahn univentionstaff 2013-10-15 08:39:09 CEST
(In reply to Philipp Hahn from comment #3)
> But there are still issues, especially with AltGr: It worked with
> IceWeasel-24.0, but not with Chromium-29.0. There were patches to noVnc like
> <https://github.com/kanaka/noVNC/pull/191>, ...

Looking at <http://www.quirksmode.org/js/keys.html> I see that Chromium maps all Alt, Meta, AltGraph to keyCode=18, while IceWeasel-17 distinguishes them as keyCode=18, keyCode=224, and keyCode=225.
Both Ctrl-Shift are always mapped to keycode=16, so they're indistinguishable.
Both Ctrl-Keys are always mapped to keycode=17, so they're indistinguishable.

XF86Back and XF86Forward are detected by Chromium as keyCode=166 and 167, while in Iceweasel they're processed by directly by Iceweasel itself and not capturable by JS.


The patch for AltGr was later reverted without further comment: <https://github.com/kanaka/noVNC/commit/60106f240af35dc6d9565e8431d4f1dee91693fc>
The issue is pending since 8 months: <https://github.com/kanaka/noVNC/pull/212>
<https://github.com/kanaka/noVNC/issues/21>


Possible alternative: Spice-HTML5
<https://github.com/kanaka/noVNC/issues/22>
<http://cgit.freedesktop.org/spice/spice-html5>
<http://www.spice-space.org/page/Html5>


So all-in-all noVNC is probably better then our current Java-based VNC version, but the keyboard issues will remain or get worse, since now it's browser and OS dependent.
Comment 6 Stefan Gohmann univentionstaff 2013-10-15 08:57:47 CEST
(In reply to Philipp Hahn from comment #5)
> So all-in-all noVNC is probably better then our current Java-based VNC
> version, but the keyboard issues will remain or get worse, since now it's
> browser and OS dependent.

I think we should switch to noVNC. We could add a note in the manual for the browser compatibility. We could also show an info message for the admin using UVMM in UMC.
Comment 7 Philipp Hahn univentionstaff 2013-10-15 09:07:54 CEST
A current GIT version of noVNC has been added as virtualization/univention-novnc. It contains a plain noVNC checkout since the current Debian package has too many dependencies <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675850>.
The websockify service is started on port 6080 to forward VNC requests from websocket connections to the real VNC server. A new system user is created to run this network service, since running it as root may be a security risk. Since it needs access to the SSL certificates, ACLs are added to allow the user "novnc" to read them.
The noVNC files are accessible through <http:///univention-novnc/>, which also contains the vnc.html file which can be used to access other websocket enabled VNC servers, for example newer qemu-1.3 VMs.

TightVnc was removed from UVMMd and the package now depends on noVNC. UVMMd writes a mapping from VM UUID to host:vnc-port to /var/caeche/uvmm/novnc.tokens/, which is processed by websockify on each new request.

ChangeLog:
The Java based VNC viewer has been replaced by <ulink ulr="http://novnc.com/">noVNC</ulink>, a JavaScript and HTML5 based VNC client

r45068 | Bug #30540: Replace Java based VNC applet by noVNC
r45067 | Bug #30540: UVMM: Replace TightVnc with noVNC
r45066 | Bug #30540: package noVNC

univention-novnc_0.4+0+20131014+git142aa45-1.2.201310150849
univention-virtual-machine-manager-daemon_3.0.9-1.472.201310150835
Comment 8 Lukas Walter univentionstaff 2013-10-31 18:25:45 CET
Nothing but "Failed to connect to server (code: 1006)" is shown in the browser, same for KVM/XEN with Chrome/Firefox.
Comment 9 Lukas Walter univentionstaff 2013-11-01 11:28:20 CET
Chrome debug console:

New state 'loaded', was 'disconnected'. Msg: noVNC ready: native WebSockets, canvas rendering util.js:110
New state 'connect', was 'loaded'. util.js:110
New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js:110
WebSocket on-close event util.js:110
New state 'failed', was 'ProtocolVersion'. Msg: Failed to connect to server (code: 1006) util.js:111
Util.Error util.js:111
New state 'disconnected', was 'failed'.
Comment 10 Philipp Hahn univentionstaff 2013-11-01 15:12:41 CET
r45810 | Bug #30540: UVMM: Fix change detection for noVNC
univention-virtual-machine-manager-daemon_3.0.17-1.480.201311011510
Comment 11 Lukas Walter univentionstaff 2013-11-01 17:26:42 CET
IE10 - OK
FF24 - OK
Chromium 28 - OK

Tested with KVM and XEN.

Changelog - OK
Comment 12 Stefan Gohmann univentionstaff 2013-11-19 06:41:16 CET
UCS 3.2 has been released:
 http://docs.univention.de/release-notes-3.2-en.html
 http://docs.univention.de/release-notes-3.2-de.html

If this error occurs again, please use "Clone This Bug".