© Ildi Papp, 123RF

Den VNC-Client auf den Desktops kann sich sparen, wer einen Server mit Guacamole füttert. Die Tomcat-App bringt entfernte Anwendungen beliebiger Betriebssysteme in den Browser. Dank HTML 5 und Javascript funktionieren auch die eingebauten Erweiterungen wie die Zwischenablage oder eine On-Screen-Tastatur.

Persea americana zerdrücken und mit Zitronen- oder Limettensaft verfeinern. Dazu Tomatenstücke, Eier, Salz, Pfeffer, Tabasco und Koriander. Schon die Vorfahren der Azteken bauten Avocados an, doch wer wann auf die Idee kam, das Lorbeergewächs zum Dip Guacamole zu zerstampfen, ist nicht überliefert.

Avocado-Dip

Eine Schüssel grünen Breis hat sich das Guacamole-Projekt [1] als Logo für seine Software auserkoren. Deren Köche entwickeln einen VNC-Client, der als Webserver die Bildschirminhalte des Servers zerstampft und die Bitmaps für Canvas und Javascript aufbereitet.

Dem Benutzer reicht fortan ein halbwegs moderner Browser, um auf seinen VNC-Server zuzugreifen: Guacamole läuft als Webapplikation in einer Apache-Tomcat-Umgebung, verbindet sich mit einem vordefinierten VNC-Server und mischt dessen Ausgabe für HTML-5-taugliche Browser auf. Version 0.5 von Guacamole kommt ausschließlich mit VNC zurecht, künftige Ausgaben sollen jedoch auch RDP sowie die SSH-Bibliotheken beherrschen. Der Kasten “Guacamole-Eigenschaften” zeigt einen Überblick über die Funktionen der Software.

IETF-Standard

Der typische Anwendungsfall von VNC ist die Fernwartung. Das Standardprotokoll punktet bei Admins, weil es sich problemlos über (fast) alle Grenzen der üblichen Betriebssysteme nutzen lässt. Beim Einsatz von VNC ist es egal, ob der Server nur einzelne Anwendungen oder eine vollständige Desktopumgebung über das Netzwerk bereitstellt. Der VNC-Server liest in diesem Fall die grafische Ausgabe mit und sendet sie an einen lokalen VNC-Client. Im Gegenzug schickt der Client die lokale Eingabe von Maus und Tastatur zurück.

Technisch gesehen kommunizieren die Teilnehmer mit dem Protokoll “Remote framebuffer” (RFB), das in einem offenen IETF-Standard spezifiziert ist [2], weshalb viele Hersteller es betriebssystemübergreifend integriert haben, auch in der Firmware verschiedener Appliances. Neben der Administration taugt VNC auch für die unkomplizierte Aus- und Weiterbildung: Ein Vortragender arbeitet aktiv an seinem Gerät mit einem Programm und gibt den Inhalt seines Bildschirms an eine Gruppe von Teilnehmenden frei, die unterdessen auf ihren Geräten allein das Geschehen verfolgen, aber aktiv nicht eingreifen können, wenn auf dem Server die Steuerung durch Eingabegeräte deaktiviert ist.

Abbildung 1: Nur wenige Einstellungen bietet der Menüpunkt Entfernter Bildschirm unter Gnome 2.

VNC – kompatibel, aber nicht unbedingt performant

Entwickler haben VNC-Programme über die Jahre hinweg kontinuierlich verbessert. Das Protokoll ist ausgereift, sodass VNC-Verbindungen neben ihrer einfachen Konfiguration in stabilen Netzwerken als sehr zuverlässig gelten. Gegenüber der Konkurrenz hat VNC aber auch Nachteile, vor allem bei der Performance über schmale Bandbreiten.

Der Ansatz von Nomachines NX [3] bietet bessere Kompressionsmechanismen bei der Datenübertragung. Seine effizienten Proxyfunktionen gleichen schwankende Latenzzeiten von Netzwerkverbindungen überraschend gut aus. X2go [4] ist weniger für die Fernwartung gedacht, sondern bringt als Terminalserver entfernte Anwendungen auf einen lokalen Computer und zeigt diese auf Wunsch nahtlos (seamless) am lokalen Desktop an. Auch Soundausgaben oder lokale Geräte wie USB-Sticks reicht X2go an den Server weiter.

In Microsoft-Umgebungen dominiert das RDP-Protokoll, das Betriebssysteme aus Redmond auch für die Fernwartung nutzen. Entwickelt hat es einst Citrix und mit ICA einen kompletten Enterprise-Stack oben draufgesetzt. Newcomer in dem Feld sind Projekte wie Red Hats Spice, das vor allem aufs Cloud Computing und Virtual-Desktop-Infrastrukturen abzielt. Einen Überblick über mit VNC konkurrierenden Technologien bietet [5].

Die meisten Desktops bringen VNC-Server mit

Die meisten Linux-Desktopumgebungen bringen unter der Haube ohnehin einen VNC-Server mit, der sich über eine grafische Oberfläche einfach konfigurieren lässt. Da Guacamole als Client mit dem VNC-Server kommuniziert, sind die Fähigkeiten und Einschränkungen des Servers für die Kommunikation mit der Webapplikation bestimmend.

Die Einstellungsdialoge von Gnome und Konsorten fallen dabei in der Regel bescheiden aus: Im System-Menü von Gnome 2 findet der Benutzer unter »Einstellungen« den Punkt »Entfernter Bildschirm« , wo er die Anzeige des eigenen Desktops über das VNC-Protokoll sehr einfach freigeben kann (Abbildung  1). Viel mehr, als ein Passwort zu setzen oder die Eingabegeräte auszuschalten, ist dem Anwender nicht erlaubt. Aber wer den Bildschirm so freigibt, kann mit jedem VNC-Client auf Port 5900 (je nach X-Display auch 5901 oder 5902) eine Verbindung aufbauen und erhält den Inhalt des gesamten Desktops.

Besser: Der eigene Server mit Vnc4server

Sollen dagegen nur einzelne Anwendungen über das VNC-Protokoll nach außen gelangen oder möchte ein Admin mehrere Benutzer gleichzeitig an ein und demselben System bedienen, dann ist ein eigener VNC-Server sinnvoll, der den Prozessen der einzelnen Benutzer explizit einzelne Ports zuweist. Im Repository eines Ubuntu-Systems finden sich dazu mehrere geeignete Projekte, die beispielsweise ein »apt-cache search vnc-server« ausgibt:

• »linuxvnc« , ein eher einfach gehaltener VNC-Server,
• »tightvncserver« , etwas komfortabler,
• »vnc4server« , der freie Nachfolger des Real-VNC-Servers, und
• »x11vnc« , ein VNC-Server speziell für X11-Displays, analog zu Win VNC auf Windows.

Die Frage, welcher VNC-Server empfehlenswert ist, sorgt immer wieder für Diskussionen im Umfeld von Guacamole. Die Entscheidung scheint im Wesentlichen wohl von den eigenen Vorlieben und Erfahrungen abhängig zu sein. Die Entwickler selbst äußern sich in dieser Sache zurückhaltend; schließlich sollten sich alle VNC-Server gleich oder sehr ähnlich verhalten.

Für das folgende Beispiel dient das Paket »vnc4server« als Basis. Es war unter dem Namen Real VNC [6] bekannt geworden, und immer noch pflegen Entwickler der gleichnamigen Firma seinen Code. Der Serverprozess lässt sich zwar einfach auf der Kommandozeile starten, trotzdem sind in den meisten Fällen aber kleine Skripte zum Starten und Stoppen (Listing 1) sinnvoll.

01 #!/bin/bash
02 DIS=2
03 rm -f /tmp/.X${DIS}-lock
04 rm -f /tmp/.X11-unix/X${DIS}
05 unset XAUTHORITY
06 unset DISPLAY
07 killall ssh-agent
08 # start ssh-agent
09 ssh-agent > $HOME/ssh-agent.sh
10 source      $HOME/ssh-agent.sh
11 rm -f       $HOME/ssh-agent.sh
12 vncserver -geometry 1024x768 -depth 24 :$DIS

Das Skript »vncserver-start.sh« startet mit dem Kommando in der letzten Zeile einen VNC-Serverprozess, dessen grafische Ausgabe eine Geometrie von 1024 mal 768 Bildpunkten mit einer Farbtiefe von 24  Bit abbildet und diese auf Port 5902 (Display  2) leitet. Nebenbei entfernt es eventuell verbliebene Lockfiles und startet den »ssh-agent« für die Authentifizierung weiterer SSH-Verbindungen. Das Stoppen des Serverprozesses kann der Admin beispielsweise mit »vncserver-stop.sh« erzwingen:

#!/bin/bash
DP=2
vncserver -kill :$DP

Beim ersten Start des Servers legt dieser – nach einer Passwortabfrage – im Homeverzeichnis des Benutzers ein Verzeichnis ».vnc« an. Dort findet sich neben einem PID-, einem Log- und einem Passwortfile auch das Startup-Skript »xstartup« (Listing 2), das zunächst nur mit Standardwerten versehen ist.

01 #!/bin/sh
02
03 # This is $HOME/.vnc/xstartup
04 # Uncomment the following two lines for normal
05 # desktop:
06 # unset SESSION_MANAGER
07 # exec /etc/X11/xinit/xinitrc
08
09 [ -x /etc/vnc/xstartup ] &&
10     exec /etc/vnc/xstartup
11 [ -r $HOME/.Xresources ] &&
12     xrdb $HOME/.Xresources
13 fvwm2 &
14 vncconfig -iconic &
15 gedit &
16 $HOME/musil2012/musil_start.sh &

Schlanker Remote-Desktop mit Fvwm2, Gedit, Wine

Für das folgende Beispiel sollen beim Start einer VNC-Verbindung der einfache Windowmanager »fvwm2« , zwei Anwendungen (der Editor »gedit« und das Skript »musil_start.sh« für die Fachanwendung aus [7]) sowie das Hilfsprogramm »vncconfig« (für das reibungslose Arbeiten mit der Zwischenablage) automatisch anlaufen.

Ein einfacher Test in Abbildung 2 mit einem VNC-Client wie »gvncviewer Rechnername:2« zeigt den Erfolg. Das rechts oben als Icon angezeigte »vncconfig« (gestartet in Zeile 14 von Listing 2) ermöglicht das Netzwerk-transparente Arbeiten mit dem Clipboard in Guacamole.

Abbildung 2: Hier zeigt der VNC-Client eine Fachanwendung.

Hauptspeise: Guacamole

Ist das Unterfangen bis hierher geglückt, sind die nächsten Schritte vergleichsweise einfach. In den üblichen Software-Repositories fehlt Guacamole leider. Pakete für Debian, Ubuntu und Fedora finden sich aber neben Anweisungen zur Installation im Downloadbereich der Homepage [1]. Die Entwickler bieten für Canonicals Linux beispielsweise »tar.gz« -Dateien an, die die zur Ubuntu-Version passenden Pakete enthalten. Bei Redaktionsschluss war dies »guacamole-0.5.0-ubuntu-11.10-i586.tar.gz« mit folgenden Paketen:

guacamole_0.5.0_all.deb
guacd_0.5.0_i386.deb
libguac2_0.5.0_i386.deb
libguac2-dev_0.5.0_i386.deb
libguac-client-vnc0_0.5.0_i386.deb

Guacamole läuft als Applikation in einer Apache-Tomcat-Umgebung, daher muss der Admin zunächst den Kater installieren und konfigurieren. Für die Kommunikation mit dem VNC-Server benötigt er zusätzlich die entsprechende VNC-Library:

apt-get install tomcat6 libvncserver0

Auch die notwendigen symbolischen Links der Applikation für die Tomcat-Umgebung legt die Installationsroutine nicht selbst an, der Admin holt das mit diesen Befehlen nach:

sudo ln -s /var/lib/guacamole/guacamole.war/var/lib/tomcat6/webapps
sudo ln -s /etc/guacamole/guacamole.proper-ties /usr/share/tomcat6/lib

Nach einem Neustart des Tomcat-Servers mit »/etc/init.d/tomcat6 restart« liest dieser die gelinkten Files neu ein.

Avocado-Rezept

Im Prinzip steht jetzt schon die grafische Ausgabe des VNC-Servers der Guacamole-Anwendung zur Verfügung, nur die Zugangsdaten fehlen noch. Fürs Anmelden an der Webapplikation verwaltet Guacamole Benutzernamen-Passwort-Kombinationen in dem einfach strukturierten XML-File »/etc/guacamole/user-mapping.xml« . In Blöcken beschreibt diese Datei Kombinationen aus Username, Passwort, Host und Ports:

<authorize username="<i class="replaceable">Name" password="Passwort">
 <protocol>vnc</protocol>
 <param name="hostname">localhost</param>
 <param name="port">5902</param>
 <param name="password">VNCpasswort</param>
</authorize>

Dieser Eintrag erlaubt es einem Benutzer mit dem Namen »Name« und dem zugehörigen Passwort, mit seinem Browser über Port 8080 die grafische Ausgabe seines VNC-Serverprozesses anzusehen. Vom Port 5902 auf »localhost« – mit dem VNC-Passwort »VNCpasswort« – bringt Guacamole den Desktop auf die URL »http://Guacamole-Server:8080/guacamo- le/« . Für den Mehrbenutzerbetrieb legt der Admin einfach mehrere solcher Blöcke an. Die hier vorzufindenden Defaulteinträge sollte er aus Sicherheitsgründen auskommentieren oder löschen.

Spartanisch: Die Anmeldung am Web-GUI

Der Guacamole-Anmeldebildschirm ist sehr einfach gehalten (Abbildung 3), nach erfolgreicher Anmeldung liefert der Browser im günstigen Fall das gleiche Bild, das der Anwender sonst aus seinem VNC-Client kennt. Abbildung 4 zeigt einen Ubuntu-Desktop, Abbildung 5 die Robert-Musil-Windows-Anwendung der Uni Klagenfurt aus dem Artikel über Wine im Linux-Magazin [7].

Abbildung 3: Der Anmeldebildschirm von Guacamole bietet keine Optionen.

Abbildung 4: Ubuntus Desktop im Browser – bereitgestellt vom Real-VNC-Nachfolger Vnc4server und dargestellt von Guacamole.

Abbildung 5: Auch Wine-Anwendungen wie die Robert-Musil-Werkschau aus dem vorigen Linux-Magazin lassen sich im Browser bedienen.

Durch das Editieren des Eintrags »<param name=”hostname”>localhost</param>« in »user-mapping.xml« kann der Admin Tomcat und den VNC-Server auf verschiedenen Rechnern betreiben. Dabei muss er nur sicherstellen, dass Guacamole den VNC-Server im Netz auch erreichen kann (Abbildung  6).

Abbildung 6: Apples Rechner bringen einen VNC-Server mit und lassen sich dank VNC übers Web steuern. Allerdings funktionieren dann nicht alle Tasten.

Die Installationsroutine von Guacamole legt alle Dateien im Verzeichnis »/etc/guacamole« mit dem Owner und der Gruppenzugehörigkeit »root« an und vergibt die Dateirechte so, dass der Guacamole-Prozess, der mit den Rechten des Users »tomcat6« läuft, die Dateien lesen darf. Diese Konfiguration erlaubt jedoch auch angemeldeten Benutzern, diese Dateien zu lesen und aus »user-mapping.xml« die Anmeldedaten sowohl für Guacamole als auch für den VNC-Server zu entnehmen. Daher sollte der Admin die Rechte sowie die Gruppenzugehörigkeit anpassen:

sudo chown tomcat6.tomcat6 user-mapping.xml
sudo chmod 640 user-mapping.xml

Wer aus Sicherheitsgründen HTTPS-Verbindungen einsetzen will, muss Tomcat für den SSL-Zugriff einrichten. Eine Anleitung findet sich in [8]. Das wird spätestens im Mehrbenutzerbetrieb empfehlenswert und bei Verbindungen übers Internet Pflicht. Guacamole erbt die SSL-Fähigkeiten von Tomcat über Includes im Java-Quelltext und ist danach unter der URL »https://Guacamole-Server:8443/guacamole/« erreichbar.

Lokale Geräte und virtuelle Tastaturen

Wer sich dafür entscheidet, Anwendungen von einem entfernten Rechner im Unternehmen zu nutzen, muss sich auch über lokale Geräte Gedanken machen, die der Anwender für seine Arbeit braucht. Fürs Drucken können die Netzwerkfähigkeiten von Cups herhalten, Freigaben von Verzeichnissen, die sowohl dem lokalen als auch dem entfernten System zugänglich sind, erlauben es, in den einzelnen Anwendungen Dateien zu importieren und zu speichern.

Viele Eingabegeräte wie Barcode-Leser sind häufig in der Lage, ihre Datenausgabe über die Tastatur abzuwickeln und lassen sich daher auch in solchen Umgebungen einsetzen. Die Integration von USB-Devices dagegen bereitet in so manchem Szenario Schwierigkeiten. Da hilft derzeit nur der Griff zu anderen Remote-Desktop-Lösungen.

Als einfache Hilfsmittel bringt Guacamole zudem eine Bildschirmtastatur sowie ein eigenes Clipboard mit (Abbildung 7). Diese erweisen sich als praktisch, wenn beispielsweise die Tastaturbelegung des VNC-Servers Probleme bereitet, so wie das im Zusammenspiel zwischen Apple und Linux die Regel ist. Leider gibt es im Moment offenbar keine Möglichkeit, die Tastatur für den deutschen Sprachraum einzustellen. Im Code von »guacamole-common-js/oskeyboard.js« findet sich jedoch der Hinweis, dass Guacamole für das Tastaturlayout via HTTP ein XML-File lädt, das die entsprechenden Tasten-Codes enthält:

Abbildung 7: Das eingeblendete Clipboard sowie die Bildschirmtastatur von Guacamole auf einem Linux-Host.

// Retrieve keyboard XML
var xmlhttprequest = new XMLHttpRequest();
xmlhttprequest.open("GET", url, false);
xmlhttprequest.send(null);
var xml = xmlhttprequest.responseXML;

Sobald genügend deutschsprachige Anwender nachfragen, dürfte sich hier sicherlich etwas verändern.

Fazit

Guacamole erweist sich im täglichen Einsatz als ein sehr interessantes Open-Source-Projekt, das bereits in einer frühen Version das Potenzial zeigt, die Administration ganzer Desktopumgebungen – aber auch einzelner Anwendungen – in ein Fenster eines Browsers zu verlagern. Die Vorzüge liegen in der einfachen Installation und Konfiguration sowie im gelungenen Ausnutzen vorhandener Übertragungskanäle.

Eine Kompression der zu übertragenden Daten wäre vor allem dann ein großer Vorteil, wenn Admins die Anwendung zur Fernwartung einsetzen. Das On-the-fly-Dekomprimieren der Daten im Browser scheint dank moderner Verfahren, Code im Browser auszuführen, durchaus realistisch.