Schlanke Terminalservices – davon konnten Linux-Benutzer lange nur träumen. Erst seit Nomachines NX und Free NX damit anfingen, die verfügbaren Tools in der richtigen Kombination und mit gehöriger Optimierung einzusetzen, gibt es Linux-Desktops auch über GPRS, Modem und ISDN. Auf Wunsch auch im Browser.

Ein alter Hut sind schnelle, schlanke Terminalservices für Windows-Benutzer. Bereits für NT 4.0 gab es die Terminal Server Edition, spätestens ab Windows 2000 fand der Remote Desktop Einzug in viele Unternehmen. Dabei reicht in der Regel schon eine einfache ISDN-Verbindung, um fließend zu arbeiten. Die Linux-Benutzer konnten zwar dank RDP-Clients wie Rdesktop (siehe eigenen Artikel) auch auf die Microsoft-Welt zugreifen, aber eine vergleichbar schlanke Lösung für den Export von Linux-Desktops gab es nicht.

Dann änderte sich die Lage. Die römische Firma Nomachine [1] hatte das schlummernde Potenzial entdeckt und entwickelte seit dem Jahr 2000 an einer performanten Terminalserver-Lösung für Linux-Desktops. Großes Aufsehen erregte im März 2003 die Ankündigung, die eigenen Libraries unter der GPL freizugegeben, vor allem weil Nomachines Software NX die wichtigsten Protokolle wie RDP (Microsofts Remote Desktop Protocol), VNC (Virtual Network Computing) und X11 unterstützt. Darüber hinaus bleibt damit jede KDE-, Gnome- oder Windows-Sitzung auch über langsame Modemverbindungen bedienbar. Das ist umso erstaunlicher, da NX im Gegensatz zu Windows-Terminalservern (maximale Schlüssellänge von 128 Bit) die RSA- oder DSA-Standardmethoden der SSH verwendet.

Funktionsumfang

Mit NX verbinden sich Linux-Benutzer von Linux, Windows, Mac oder vom Browser aus auf den Linux- oder Windows-Terminalserver. Dort starten sie einzelne Anwendungen, die der Client nahtlos als Fenster darstellt. Der Linux-Admin, der auch auf Windows arbeiten muss, freut sich über seine Lieblingsterminals wie Gterm, Xterm oder die Konsole auf dem Windows-Desktop.

Lokale Soundausgabe, Drucker (Abbildung 1) und Speichermedien sind ebenso enthalten wie der Zugriff auf VNC-Sitzungen und über einen Proxy. Die Benutzer bedienen den Client über ein intuitives grafisches Interface, für den Admin stehen Kommandozeilen-Tools zur Verfügung.

Abbildung 1: Ein lokaler HP Laserjet steht in der Terminalserver-Sitzung zur Verfügung. Über Cups bindet NX die Drucker des Clients automatisch auf dem Server ein und erlaubt auf Wunsch auch anderen Benutzern zu drucken.

Suspend und Resume der Sessions gibt\’s ebenfalls und ab Version 3 können sich dank Shadowing und Desktop-Sharing mehrere Benutzer denselben Desktop teilen. Für all dies braucht der Admin nur den Port 22 in der Firewall zu öffnen, die gesamte Verbindung läuft über SSH. Besonders schön: Den Server gibt es in zwei kostenlosen Versionen, eine davon, Free NX [2], unterliegt vollständig der GPL. Die zugrunde liegenden Technologien basieren komplett auf X-Window, SSH, Rdesktop, VNC und anderen freien Projekten und sind auf Nomachines Webseite vollständig offengelegt.

Hexerei?

Dass die Sitzungen viel schneller als konventionelles X-Forwarding über Kommandos wie »ssh -X -C User@Host X-Programm« sind, liegt an der geschickten Mischung aus Caching, einem intelligenten Proxy und angepasster Optimierung mit Bibliotheken wie Zlib und JPG. NX komprimiert nicht nur alle Daten, die es zwischen Client und Server austauscht, sondern auch alles, was es im lokalen Cache vorhält.

Den Großteil des Dopings macht dabei das Know-how über die Arbeitsweise von X-Window [3] aus. Schuld an der schlechten Performance klassischer X-Anwendungen über schmale Bandbreiten ist im Wesentlichen die interne Struktur der Unix-Standardoberfläche X11, die mit ihren vielen Roundtrips traditionell für schnelle, dicke Leitungen ausgelegt ist. Bei langsamen Verbindungen bricht die Performance ein (siehe Kasten “Roundtrips”).

NX statt X

Anstelle der Datenübertragung über X11 mit seinem vielen Roundtrips tritt bei Nomachines Entwicklung das NX-Protokoll. Das Programm »nxserver« kommuniziert mit dem auf dem Client installierten »nxclient«. Der »nxagent« auf dem Server bedient die Anfragen der Anwendung, der »nxclient« übernimmt die Darstellung auf dem Client und »nxproxy« komprimiert und optimiert.

Weil sowohl Client als auch Server X-Window-Daten zwischenspeichern, vermeidet NX zahlreiche Roundtrips. Die Anwendung erhält im Optimalfall die benötigten Antworten direkt vom lokalen Prozess, der nur Änderungen (Deltas) zum Server überträgt. Durchschnittlich 60 bis 80 Prozent der Daten kann NX direkt aus dem Cache laden, indem es das X-Protokoll analysiert, bei Bildern wie Icons und Pixmaps erreicht es Cache-Hit-Raten von fast 100 Prozent.

All das war so neu nicht, denn auch der Differential X Protocol Compressor (DXPC, [5]) arbeitet ähnlich. Dessen Ansätze inspirierten die Programmierer von Nomachine und sie übernahmen die Analysen und Tools zum Differential Encoding der annähernd 160 verschiedenen Nachrichtentypen des X-Protokolls. Auch DXPC gibt es noch, allerdings erreicht die aktuelle Version gerade mal Performance-Werte, die nach Informationen auf der Webseite ein Xterm über ein Modem erlauben. Ein Browser ist mit einem 28,8-KBit/s-Modem allerdings praktisch unbedienbar.

Message Store Based X Protocol Encoding

Also doch Hexerei? Nein, die Innovation ist komplex und geichzeitig einfach. Zunächst prüft NX, ob es einen Request direkt aus seinem Cache beantworten kann. Wenn nicht, ist das “Message Store Based X Protocol Encoding” zuständig. Dabei analysiert NX das X-Protokoll und zerlegt dessen Nachrichten in zwei Teile: einen Datenteil (Data) und einen Fingerabdruck (Identity, Fingerprint).

Während Letzterer meist nur wenige Byte umfasst, machen die Daten den Hauptteil des Traffic aus. Die Fingerprints zweier Nachrichten unterscheiden sich meist, aber die Wahrscheinlichkeit, dass der Datenteil vorher schon einmal übertragen wurde, steigt, je länger die X-Sitzung dauert. NX referenziert und speichert daher alle übertragenen Datenblöcke in seinem Message Store. Angepasste MD-5-Checksummen beschleunigen dabei die Suche. Weil NX nur für das Enkodieren die Checksummen berechnen muss und die dekodierende Seite nur die Payload speichert, ist der Speicherbedarf vergleichsweise gering. Der Message Store kann deshalb bis zu 3000 Nachrichten vorhalten.

Ruft ein Benutzer ein Anwendungsmenü zum ersten Mal auf, fragt der NX-Client alle Daten vom Server an. Dieser komprimiert sie und schickt sie verschlüsselt an den Client. Aber bereits beim zweiten Mal kommen fast alle Daten, beispielsweise die Pixmap eines Hintergrundbildes oder die Schriftarten, aus dem lokalen Arbeitsspeicher. So vermeidet der Client die tatsächliche Datenübertragung und beantwortet die X-Requests aus dem lokalen Cache.

Der Message Store ist persistent, er steht also dem Benutzer auch nach der Trennung (Suspend) und der Wiederaufnahme (Resume) einer Sitzung weiterhin zur Verfügung. Weil NX ihn nach Sitzungsende auf der Festplatte speichert, steht er für eine zweite, identische Sitzung auch nach einem Reboot des Clients bereit. Diese Methode ist zwar sehr effektiv, wirft aber auch Sicherheitsfragen auf. Kann ein Angreifer aus einem gestohlenen oder kompromittierten Laptop kritische Sitzungsdaten aus dem NX-Cache herausziehen? Dieses Feld scheint bisher noch nicht gründlich beackert zu sein.

Differential X Protocol Encoding

Die wenigen verbleibenden Daten, die Server und Client austauschen, komprimiert NX mit einem an das X-Protokoll angepassten Verfahren, dem so genannten Differential X Protocol Encoding. Weil die zur Verfügung stehenden X-Messages so unterschiedliche Informationen wie Bilder, Fonts, Texte und andere Informationen beinhalten und NX neben dem X-Protokoll auch RDP und VNC spricht, verwendet es individuelle Komprimierungsverfahren, je nach Objekt und Verbindungstyp JPG-, PNG-, RDP-, Tight oder Zlib-Komprimierungsalgorithmen. Durch geschickte Kombinationen erreicht es auf diese Weise Raten zwischen 20:1 und 2000:1.

Unbekannte Daten, für die keine angepasste Methode verfügbar ist, komprimiert die Zlib- Bibliothek mit Raten von 4:1. Mit der gleichen Software verdichtet NX abschließend den gesamten Traffic zwischen Client und Server noch einmal, wobei die Einstellungen im Client den Komprimierungsgrad bestimmen, er reicht von 1 (»WAN«) bis 9 (»MODEM«) (siehe Abbildung 2). Laut Nomachine bewirkt diese letzte Stufe noch einmal 30 Prozent weniger Daten.

Abbildung 2: Der Schieberegler bestimmt die Komprimierung. Von »MODEM« (stark verdichtet) bis »LAN« (fast unkomprimiert) reicht die Spanne. Hier hat der Anwender im Bereich Desktop über den Eintrag »Custom« eine einzelne Anwendung im Seamless Mode ausgewählt. Den Pfad trägt er über den »Settings«-Dialog ein.

Streaming und Priorisierung

Damit noch nicht genug. Weil über eine schmale Bandbreite, zum Beispiel GSM mit nur 4 KBit/s, auch die Übertragung eines Bildes von ganzen 12 KByte (nach NX-Komprimierung) etwas länger dauert, kommt Streaming zum Einsatz. Der Server unterteilt das Bild in einzelne Chunks, die er mit niedriger Priorität und JPG-komprimiert überträgt.Eine Anwendung reagiert so weiter auf Benutzereingaben, während NX das Hintergrundbild gemütlich aufbaut.

Generell priorisiert Nomachine interaktive Anwendungen gegenüber bildlastigen Programmen, indem es den Datenstrom analysiert und die Vorgaben dynamisch anpasst. Darüber hinaus verwendet es interne Bandbreitenkontrolle, Quoten und Stream Compression, um die tatsächlich übertragenen Daten zu reduzieren. Details zur NX-X-Protokoll-Komprimierung finden sich in [6].

Der Aufwand lohnt sich. Für NX reichen je nach Anwendung Bandbreiten von 10 bis 20 KBit/s mit Latenzzeiten im Zehntelsekundenbereich für (einigermaßen) fließenden Arbeitsablauf. Ab 30 bis 40 KBit/s und Latenzen um 0,01 Sekunden erscheint der dargestellte KDE- oder Gnome-Arbeitsplatz schon so flott, als wäre er lokal. Von den für den ersten KDE-Start erforderlichen mehreren MByte bleiben schon beim zweiten Mal nur wenige KByte übrig. Derart Ressourcen-schonend mit der Bandbreite spart NX auch im LAN bis zu 60 Prozent der übertragenen Daten ein.

Der Client legt die Daten komprimiert ab und entpackt sie on the Fly, wodurch sich teilweise unglaubliche Effekte ergeben. Der Start von Open Office von einem NX-Server erfolgt ab dem zweiten Anlauf meist deutlich schneller als von der lokalen Festplatte oder deren Cache. Im Gegensatz zu den überladenen, verkonfgurierten Windows-PCs typischer Büroarbeitsplätze erfahren die Benutzer einen richtigen Geschwindigkeitsrausch, wie zahlreiche begeisterte Anwenderberichte im Internet zeigen.

Weil die typischen Desktop-Sitzungen in der Regel aus immer wiederkehrenden Abläufen bestehen (Menü aufklappen, Dialog Öffnen, Fenster verschieben), ergibt sich mit längerer Laufzeit auch eine zunehmend bessere Performance, also praktisch umgekehrt wie beim klassischen Windows.

Free NX oder NX?

NX gibt es in mehreren Versionen, die wichtigsten davon sind die Free Edition von Nomachine [7] selbst und die Pakete des Free-NX-Projekts [2]. Beide verwenden die gleichen Libraries als Basis, aber die Software aus Italien ist meist aktueller, stabiler, schneller und beherrscht mehr Features. Von Nomachine gibt es Clients für Windows, RPM- und Debian-Pakete, Quelltextarchive und Software für Mac und Solaris.

Außerdem gibt es noch einen Server Manager und den Web Companion. Mit Letzterem haben die Clients dank eines NX-Java-Applets einfach über den Browser, also ohne Software-Installation, Zugriff auf einen Linux- oder Windows-Desktop. Ein embedded Client ermöglicht den Zugriff auf NX-Server von mobilen Geräten, gegenwärtig von Linux-Ipaqs oder dem Zaurus.

Passend dazu gibt\’s von Free NX die RPMs, Debs und Tar.gz-Archive in der aktuellen Version 0.7.0. Debian und Ubuntu brauchen die passenden Repositories von [8], dann installiert »apt-get install freenx nxclient« die Version 0.6 und den »nxclient« in Version 2.1.0-17 (Ubuntu Feisty, August 2007). Open Suse und Fedora liefern teilweise noch die älteren Versionen 0.4 oder 0.5 mit.

Free NX und NX sind weitgehend kompatibel zueinander, laut Mailingliste [9] funktionieren auch das Java-Applet und der Web Companion mit Free NX. Allerdings zeigen sich auch schnell die Unterschiede. Free NX ist leider um Längen langsamer und läuft bei Weitem nicht so stabil wie die freie Version der kommerziellen Variante. Trotzdem funktioniert der Nxclient von beiden Installationen auch mit dem jeweils anderen Server, wie Abbildung 3 zeigt. Selbst derart verschachtelte NX-Sitzungen laufen performant und reagieren prompt auf die Benutzerinteraktion.

Abbildung 3: Eine verschachtelte Free-NX-Sitzung zeigt die Flexibilität und Kompatibilität von NX und Free NX. Der Session-Administrator listet drei laufende Sitzungen, in zweien davon fungiert der lokale Rechner als Client, in einer als Server. Lokal ist Nomachines NX installiert, der entfernte Rechner betreibt Free NX. In der NX-Sitzung hat der Benutzer eine Free-NX-Session geöffnet.

Weil die Installation von Free NX oft nicht rund läuft, müssen Administratoren in der Regel selbst Hand anlegen. Howtos, zum Beispiel für Ubuntu [10], helfen hier weiter. Nomachines Software läuft dagegen sofort nach der Installation und der Client ist in der Firmware von vielen Thin Clients integriert.

Funktionsumfang und Preise

Während Free NX komplett der GPL unterliegt, beschränkt Nomachine die Free Edition auf zwei User bei zwei gleichzeitige Sitzungen. Die kostenpflichtigen Versionen erlauben zehn Benutzer (NX Enterprise Desktop) oder zehn gleichzeitige Sitzungen (Small Business Server). Der Enterprise Server kennt für gut 1500 Dollar netto keine solchen Begrenzungen und beherrscht auch LDAP- und Active-Directory-Integration, einen Kiosk-Modus und Benutzerprofile.

Ebenfalls unbegrenzte Sessions stellt der Advanced Server zur Verfügung, der für viel Geld (knapp 3500 Dollar) über die Fähigkeiten von Enterprise Server hinaus noch simples Clustering und Load-Balancing beherrscht. Als Betriebssysteme empfiehlt der Hersteller Suse, Red Hat, Mandriva, Debian oder Solaris. Auch Xandros, Univention und andere Distributoren integrieren Nomachine in ihre Produkte.

Pfade zur Konfiguration

Der Admin konfiguriert den Free-NX-Server über die Dateien in »/etc/nxserver«, die Binaries landen bei der Installation schön ordentlich in »/usr/bin« und in »/usr/sbin«, die Libraries in »/usr/lib/nx« und die Dokumentation in »/usr/share/doc/freenx«. Nomachine hingegen hält sich leider nicht an die Empfehlungen der FSB und installiert sich komplett unter »/usr/NX«, nicht untypisch für kommerzielle Software.

Hier findet der Admin Konfiguration, Binaries, Bibliotheken, Skripte und Dokumentation. Im Verzeichnis »/usr/NX/etc/« liegen neben den ».cfg«-Dateien auch Vorlagen und die Datenbankdateien für Benutzer und Passwörter. Nomachine nutzt nach der Installation PAM als Quelle für die Authentifizierung, es kann aber auch eine eigene Datenbank mit Benutzern vorhalten, die völlig unabhängig vom Betriebssystem des Servers ist. Diese Einstellung lässt sich auf Wunsch mit den Einträgen in »/usr/NX/etc/server.cfg« ändern (Listing 1).

01 [...]
02 # Enable or disable NX users DB:
03 #
04 # 1: Enabled. Only users listed in NX 
05 # users DB can login to the NX server.
06 #
07 # 0: Disabled. All the authenticated 
08 # users can login.
09 # If the NX user DB is disabled, any user
10 # providing a valid password from
11 # local DB or through SSHD authentication, 
12 # can connect to the NX system. 
13 # This is likely to be the default when 
14 # SSHD authentication with PAM is enabled.
15 # 
16 EnableUserDB = "1"
17 [...]
18 EnablePasswordDB = "1"
19 [...]

Auch fürs File- und Desktop-Sharing und die Multimedia-Unterstützung finden sich hier die Server-seitigen Optionen. Die Konfigurationsdateien sind bei beiden Varianten vorbildlich dokumentiert und enthalten alle Einstellungen, die die Server beherrschen.

Windows, Server Manager, Web Companion

Die Abbildung 4 und 5 zeigen, wie ein Benutzer den NX-Client auch für den RDP-Zugriff auf einen Windows-Terminalserver einsetzen kann. Weil hier ebenfalls der Export einzelner Anwendungen möglich ist, zeigt NX speziell die eine, jeweils branchenspezifische Fachanwendung auf den Linux-Desktop an, was sich vor allem bei Migrationen als hilfreich erweist.

Intern startet NX dabei das Programm »rdesktop« und öffnet die Sitzung. Wichtig ist also, dass der NX-Server – nicht der Client – eine Verbindung mit dem Microsoft Server öffnen kann. Vom Client zum NX-Server ist nur die verschlüsselte SSH-Verbindung über Port 22 nötig.

Abbildung 4: Die Konfiguration des Nomachine-Clients für den Zugriff auf einen Windows-Terminalserver. Linux-Sitzungen kann der Benutzer on the Fly resizen, aber für Windows-Sessions sollte er vorher die passende Auflösung wählen. Im Settings-Dialog gibt er die Authentifizierungsmethode ein.

Abbildung 5: Ein Windows-Client hat sich über einen (NX-)Linux-Server sicher auf einen Windows-Terminalserver verbunden.

Der Server Manager (Abbildung 6) verwaltet ein Netzwerk aus NX-Servern, zum Beispiel wenn mehrere Advanced Server in einem Load-Balancing-Cluster verbunden sind. Echte HA gibt\’s dabei nicht: Laufende Sitzungen gehen verloren, wenn ein Server abraucht. Im Gegensatz dazu ist der Web Companion (Abbildung 7) fast schon ein Muss. Der Admin installiert auf dem NX-Server einen Standard-Apache, befolgt ein paar Hinweise aus der Doku – schon kann jeder Benutzer eines Java-fähigen Webbrowsers eine Sitzung auf dem NX-Server starten, sofern er die passenden Credentials vorweisen kann.

Abbildung 6: Die Verwaltung mehrerer NX-Server in Firefox. Admins großer Netze mit mehreren Terminalservern administrieren hier die Benutzerdatenbanken und Servereinstellungen.

Abbildung 7: Zugriff auf den Linux-Desktop vom Browser aus: Dank eines Java-Applets ist auf dem Client keine Software-Installation erforderlich. Der Nomachine Web Companion funktioniert laut Mailingliste auch mit Free NX.

Das Java-Plugin hat Nomachine allerdings in der »tar.gz«-Version versteckt, den RPMs und Debian-Paketen des Web Companion fehlt die Datei »nxapplet.jar«. Also: »nxplugin-Version.tar.gz« runterladen, auspacken und die Datei nach »/var/www/plugin/Java/nxapplet.jar« speichern, dann klappt der Browser-basierte Zugriff wie in der Dokumentation.

Fazit

NX definiert Linux-Terminalservices neu. Die Optimierung bis ins Detail, mit viel Know-how vorgenommen, ermöglicht erstaunliche Performance bei relativ hoher Sicherheit. Clients gibt\’s für alle gängigen Betriebssysteme, sie können sowohl auf Linux- als auch auf Windows-Terminalserver zugreifen.

Deshalb hat sich NX zu einem kaum verzichtbaren Werkzeug bei Migrationen und im Server-based Computing entwickelt. Im Seamless Mode schieben geschickte Admins ihren Windows-Benutzern Linux-Anwendungen wie Firefox, Thunderbird oder Open Office unter, ohne dass diese etwas davon bemerken, abgesehen von der höheren Geschwindigkeit. Mit dem Web Companion brauchen Client-Arbeitsplätze nur noch einen Browser, ein mobiler Client steht auch schon bereit. Seit NX 3 greifen Trainer und Support-Mitarbeiter direkt auf den Desktop der User zu.

Nomachine zeigt, wie ein erfolgreiches Konzept auf der Basis von Open Source aussehen kann. Zu den unter der GPL freigegebenen Basisbibliotheken sind enterprisefähige Serverprodukte, Hotlines und Support erhältlich. Wer sich von NX überzeugen will: Auf der Webseite [1] stehen zwei Testserver bereit.