Univention Bugzilla – Bug 30540
Integration eines JavaScript VNC-Clients in UVMM
Last modified: 2013-11-19 06:41:16 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.
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".
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--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>.
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> <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.
(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. 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
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 Util.Error util.js:111 New state 'disconnected', was 'failed'.
r45810 | Bug #30540: UVMM: Fix change detection for noVNC univention-virtual-machine-manager-daemon_3.0.17-1.480.201311011510
IE10 - OK FF24 - OK Chromium 28 - OK Tested with KVM and XEN. Changelog - OK
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".