Anstatt einem externen VNC Viewer wäre es auch nett, wenn man einen VNC-Viewer im Browser verwenden kann, beispielsweise: http://guacamole.sourceforge.net/
Siehe auch mozilla-gtk-vnc (Bug #18085), daß aber wegen 32 Bit Firefox auf amd64 nicht einfach zu bauen ist.
Zur Dokumentation, wie man unter Firefox einen externen VNC-Viewer nach http://kb.mozillazine.org/Register_protocol unter "about:config" konfiguriert: String network.protocol-handler.app.vnc;/usr/bin/krdc Boolean network.protocol-handler.expose.vnc;false Boolean network.protocol-handler.external.vnc;true Boolean network.protocol-handler.warn-external.vnc;false Für das Format von vnc://-URIs scheint es keinen offiziellen Standard zu geben, siehe dazu den Kommentar unter http://www.realvnc.com/pipermail/vnc-list/2004-June/045703.html . krdc akzeptiert derzeit URIs der Form "vnc://HOSTNAME:DISPLAY_NUMMER" und "vnc://HOSTNAME:TCP_PORT", wobei "DISPLAY_NUMMER + 5900 == TCP_PORT" ist.
Über "expose" wird kontrolliert, ob Firefox erst noch ein neues Fenster oder einen neuen Tabulator erzeugt, bevor dann doch der externe VNC-Viewer aufgerufen wird. Empfohlene Einstellung: false Über "external" wird kontrolliert, ob das Protokoll überhaupt an einen ggf. externen Viewer weitergeleitet wird. Empfohlene Einstellung: true "warn-external" und "app" scheinen zumindest unter KDE keinen Einfluss zu haben.
Der VNC-Server von Xen lauscht per Default nur auf localhost und sollte für die Verwendung aus dem UVMM-UMC-Modul heraus vermutlich per "ucr set xen/vnc/listen=0.0.0.0" geöffnet werden.
(In reply to comment #4) > Der VNC-Server von Xen lauscht per Default nur auf localhost und sollte für die > Verwendung aus dem UVMM-UMC-Modul heraus vermutlich per "ucr set > xen/vnc/listen=0.0.0.0" geöffnet werden. Geht auch pro Instanz über libvirt.xml /domain/devices/graphics/@listen='0.0.0.0'.
Hier sollten wir nochmal den Aufwand prüfen, ob wir dies nicht für UCS 2.4 integrieren können. Der externe VNC-Link sollte vorhanden bleiben.
http://lists.xensource.com/archives/html/xen-users/2007-06/msg00368.html
http://www.tightvnc.com/ssh-java-vnc-viewer.php
Zwei Beispiele: http://xen1/vnc/test.html http://xen1/vnc/test2.html Die Integration in UMC am besten mit Andreas absprechen.
univention-virtual-machine-manager-daemon (0.9.44-1) unstable; urgency=low * add VNC java client capability (Bug #18346) Es muss noch geklärt werden, ob beide VNC-Links angezeigt werden sollen.
(In reply to comment #10) > Es muss noch geklärt werden, ob beide VNC-Links angezeigt werden sollen. Der Name des Links (JavaVNC) gefällt mir noch nicht so gut. Ich habe allerdings auch gerade keinen kreativen Vorschlag. Wenn beide angezeigt werden können, muss aus der Bezeichnug klar werden, was der jeweilige Link auslöst.
(In reply to comment #10) > Es muss noch geklärt werden, ob beide VNC-Links angezeigt werden sollen. Wenn es mit allen Browsern soweit funktioniert, dann sollte dieser VNC-Link zum Default werden. Wenn man per UCR Variable das alte Verhalten wiederherstellen kann, dann reicht das.
Es tut zumindest nicht mit der Java-Version aus der Thin-Client-Umgebung von mammut.
univention-virtual-machine-manager-daemon (0.9.58-1) unstable; urgency=low * add UCR variable uvmm/umc/vnc to select VNC type (Bug #18346)
Das sollte mit den unterstützen Browser Versionen getestet werden: * Firefox * IE 6 * IE 7 * IE 8
Ich habe einige Browser mit der aktuellen UMC Version (3.0.56-1.377.201008090656) getestet - funktioniert einwandfrei. Auf meinem Thin-Client gab's jedoch auch Probleme, aus diesem Grund habe ich es in einer VM getestet. * Firefox --> funktioniert! * IE 6 --> funktioniert! * IE 7 --> funktioniert! * IE 8 --> funktioniert! (beim IE musste manuell noch Java installiert werden. In meinem Fall 1.6.0_21) Ich habe bei der Gelegenheit auch gleich Opera getestet --> funktioniert! Google Chrome wollte den VNC-Viewer jedoch nicht anzeigen. Verified!
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".