Univention Bugzilla – Bug 30540
Last modified: 2013-11-19 06:41:16 CET
+++ This bug was initially created as a clone of Bug #23303 +++
Eine Alternative die keine Websockets benötigt wäre Guacamole aber da wird dann serverseitig ein Java-Proxy benötigt:
Das Ganze wurde in Bug 23303 bereits andiskutiert.
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:
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".
noVnc is currently under heavy development. It should be considered to use the latest git version from github.
(In reply to Liam Schwez from comment #1)
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
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>.
The extension to VNC to send keycodes: <https://mail.gnome.org/archives/gtk-vnc-list/2008-January/msg00045.html>
(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>
Possible alternative: Spice-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.
(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.
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.
r45068 | Bug #30540: Replace Java based VNC applet by noVNC
r45067 | Bug #30540: UVMM: Replace TightVnc with noVNC
r45066 | Bug #30540: package noVNC
Nothing but "Failed to connect to server (code: 1006)" is shown in the browser, same for KVM/XEN with Chrome/Firefox.
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
New state 'disconnected', was 'failed'.
r45810 | Bug #30540: UVMM: Fix change detection for noVNC
IE10 - OK
FF24 - OK
Chromium 28 - OK
Tested with KVM and XEN.
Changelog - OK
UCS 3.2 has been released:
If this error occurs again, please use "Clone This Bug".