Auf der Suche nach einer performanteren Alterantive zu X2Go bin ich durch den Beitrag von Heinrich Boers auf Xpra aufmerksam geworden. Leider muss ich an dieser Stelle gleich sagen, das es bei mir trotz stundenlanger Versuche und Recherche leider nicht läuft. Feedback und Hilfe sind also in diesem Fall besonders Willkommen. Siehe Update vom 08.09.2017 – 20:59 Uhr.

Warum nicht X2Go?

X2Go ist eine feine Sache und imho auf Server- als auch Client-Seite leicht zu Handhaben. Zumindest bei den hier üblichen Szenarien, d.h. Debian-Server und Windows 7.x oder 8.x-Client läuft das gut. Einzig die Performance bei der Bildübertragung, beispielsweise Scrollen, könnte etwas besser sein. Was nicht bedeutet das sie generell schlecht wäre, aber klar, YouTube-Videos schauen macht keinen Spass.

Bisherige Xpra-Versuche

Schaut man sich diverse Anleitungen im Netz an, sollte die Sache eigentlich relativ einfach sein. Die Testumgebung besteht aus Debian 9.1 Stretch 64-bit auf der Server-seite, frisch installiert, sowohl mit als auch ohne Xfce-Desktop (mehrere virtuelle Maschinen). Der Client ist ein Windows 8.1 Pro ebenfalls 64-bit.

Zunächst wurde mir Xpra aus dem Debian-Repo getestet. Das führte zu folgender Meldung in den Protokollen unter “/home/andy/.xpra/”:

2017-09-08 12:26:26,668 Error starting Xvfb:
2017-09-08 12:26:26,669 Xorg did not provide a display number using -displayfd

Aus “purer Verzweiflung” dann die aktuellere Version aus dem Window Switch (winswitch)-Repo installiert. Läuft ebenfalls nicht, die Logs sind richtig schweigsam, soll heissen: Leer. Auch unter “/var/log” hat sich nichts finden lassen.Einzig unter “/var/log/messages” fand sich

Sep 8 12:38:31 debian03 xpra: Warning: cannot use the system proxy for 'start' subcommand,#012 FAILURE

Was wiederum vom Client aus mittels Angabe von “–start-via-proxy=no” unterbunden werden konnte. Ein “–debug=all” half auch nicht, es wird nichts protokolliert. Es tut einfach nicht.

Das ist soweit nur die Kurzfassung der vergangenen sechs Stunden. Dazwischen wurden diverse Konfiguration und Befehle versucht, Pakete installiert, deinstalliert usw.

Nun wäre es interessant zu erfahren, ob es jemand zum Laufen bekommen hat und welche Erfahrungen damit gemacht wurden.

Update 08.09.2017 – 16:31 Uhr

So langsam wird das Chaos perfekt: Mit einem vServer bei KAMP klappt’s, mit den lokalen Debian-Servern leider nicht. Verwendet wird jeweils das winswitch-Repo und der gleiche Client.

Update 08.09.2017 – 20:59 Uhr

So, schätzungsweise ist es geschafft, zumindest für das gesetzte Ziel, entfernte Anwendungen ausführen zu können. Anbei die Schritte:

• Die Ausgangslage ist ein frisch installiertes Debian 9.1 Stretch (netinstall) ohne Desktop-Umgebung.
• Window Switch (winswitch)-Repository hinzufügen und Xpra installieren:

  apt-get install curl
  curl http://winswitch.org/gpg.asc | apt-key add -
  echo "deb http://winswitch.org/ stretch main" > /etc/apt/sources.list.d/winswitch.list
  apt-get update
  apt-get install xpra

• Fehlende Abhängigkeit installieren:

  apt-get install dbus-x11

• Z.B. Firefox-ESR installieren:

  apt-get install firefox-esr firefox-esr-l10n-de pulseaudio

Warum nicht Chromium?

Chromium wurde ebenfalls getestet, allerdings funktioniert die Fenster-Skalierung nicht richtig, so das es Überschneidungen mit der Taskleiste kommt. Ferner stürzte mehrmals der Xpra-Client unter Windows ab. Die Performance, wenn es denn mal lief, war gefühlt nicht besser als mit Firefox.

Client

Wie weiter oben erwähnt, kommt ein Windows-Client zum Einsatz. Für die Tests wurde direkt in einer Eingabeaufforderung gearbeitet:

• cd “C:\Program Files\Xpra”
• xpra start ssh/<username>:<password>@<ip-or-hostname> –start-child=f
  irefox-esr –speaker=on –av-sync=yes –window-close=shutdown

Troubleshooting:

Hardware-sizing

Je nachdem was man für Anwendungen remote ausführt bzw. was für einen Ressourcenbedarf diese haben, kann es zu Schwierigkeiten kommen. Im Verlauf des Tages zeigte sich mehrfach, das Schwache vServer, virtuelle Maschinen oder generell schwache Hardware zumindest mit Firefox und ein wenig Surfen nicht “klar kommen”. So gab es z.B. schon zu Beginn, d.h. nach dem Ausführen von “xpra start …” zum Verbindungsabbruch, so das die sichtbare Verbindung dann erst  mit “xpra attach …” aufgebaut werden musste. Ferner kann das Verhalten der “RemoteApp” hakelig sein.

Xpra-Prozesse server-seitig finden und beenden

Auf dem Server muss man ggf. nach Fehlversuchen oder Client-Abstürzen sozusagen hängen gebliebene Xpra-Prozesse beenden. Diese lassen sich mit

ps -fC xpra

identifizieren und dann mittels

kill <PID>

beenden.

Tipp: Da der Verbindungsaufbau durchaus einen Moment dauert, kann man gut mit dem “ps”-Befehl die einzelnen Abschnitte beobachten (man achte dabei auf das “CMD”).

Protokollierung (Logging)

Wenn’s nicht klappt, hilft evtl. ein Blick ins Protokoll. Falls ab Werk keines erstellt wird, dann kann man dieses in der Benutzer-Konfiguration “forcieren”:

• “/home/<Benutzername>/.xpra/xpra.conf” editieren und folgende Zeilen einfügen:

  log-dir=/home/<username>/.xpra
  log-file=xpra.log

Als problematisch kann sich erweisen, das mitunter eine Menge Warnungen und Fehler, die ignoriert werden können, erfasst werden.

(Vorläufige) Abschluss-Bemerkung

Wie es um den Rest der Möglichkeiten von Xpra bestellt ist, vermag ich aktuell (noch) nicht zu sagen. Das gewünschte Ziel einzelne Anwendungen remote nutzen zu können ist auf jeden Fall erstmal erreicht.

Quellen:

Window Switch – Repository for Ubuntu and Debian

Xpra Bug tracker and wiki – Fresh Fedora 23 install of 0.18.0 xpra getting Error setting up dbus server

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.