XRDP zum Debuggen

Seitdem mir vor einigen Jahren xrdp gezeigt wurde, wusste ich, dass ich damit glücklich werden kann.
Diese Implementierung des Microsoft Remote-Desktop-Protocols für Linux verwandelt jede Installation in einen Terminalserver, den man grafisch über das Netzwerk fernsteuern kann.

Ganz besonders hilfreich ist diese Lösung für das Debuggen, wenn man eine vollständige IDE aus der Ferne bedienen kann.

xrdp vs. X11-Forwarding

Unixianer belächeln den xrdp Ansatz, weil sie seit Jahrzehnten die Möglichkeit kennen, dass X11 Protokoll über eine SSH Session zu tunneln und somit auf dem lokalen PC grafische Programme nutzen können, die auf einer anderen Maschine ausgeführt werden.

Diese Variante habe ich öfters auch unter Microsoft Windows genutzt, vor allem in Verbindung mit dem Programm MobaXterm.

Dennoch haben RDP Sitzung zu einem Linux-System für mich mehr Vorteile als die Weiterleitung des X11 Protokolls:

• Der RDP Client (mstsc) ist seit Windows XP out-of-the-box dabei und man braucht nichts weiteres am Client installieren.
• Anzeigeelemente funktionieren im RDP-Sandkasten besser, z.B.: bedeuten “Vollbild” oder “zentrieren” bei Mehr-Bildschirm-Systemen über X11 immer nur Probleme.
• RDP ist schneller.
  Die “Bildschirmfotos” werden zwar mit geringerer Framerate übertragen, aber werden meist ohne Verzögerung angezeigt. X11 Grafikelemente übertragen jede Zeichenoperation separat und man kann bei langsamerer Netzwerkverbindung gelangweilt zusehen, wie sich Linie für Linie gemächlich aufbaut.
• Kontextmenüs erkennen in X11 oft den Bildschirmrand nicht.
  Man öffnet ein Menü und dieses ragt über die Bildschirmkante hinaus. Womit man nie die unteren Menüpunkte sehen oder auswählen kann. In RDP (also innerhalb der Linux-Umgebung), wird das erkannt und das Menü entsprechend verschoben.

xrdp, K-Develop und mehr

Innerhalb einer xrdp Session nutze ich dann gerne K-Develop aus dem KDE Projekt, um Sourcen zu bauen und zu Debuggen. Syntaxhighlighting und IntelliSense funktionieren dort recht gut und man kann Breakpoints einfach und bequem per Mauszeiger setzen.
Jeder, der sich schon mal per gdb durch Exceptionhandler quälen musste, lernt eine solche grafische IDE sehr zu schätzen.

Am besten ist, dass K-Develop CMake Projekte unterstützt und somit das GATE Projekt ohne Umschweife verwalten kann.

Und natürlich kann man auch jede andere IDE und auch Visual Studio Code auf diese Weise zum Laufen bringen.

Installation

Die Installation läuft über das Paket-Management System der Distribution. Unterschiedlich ist, ob man etwas nachkonfigurieren muss. Meistens muss man die Datei /etc/xrdp/startwm.sh anpassen und den gewünschten Window-Manager dort starten (ansonsten sieht man nur ein Konsolenfenster um Kommandos einzugeben). Man ersetzt dort am Ende die Zeile, die mit exec beginnt.

• Debian / Ubuntu:
  • xrdp Installation apt install xrdp
  • Service starten: /etc/init.d/xrdp start
  • xfce Installation: apt install xfce4
  • Konfigurationsdatei: /etc/xrdp/startwm.sh
• SuSE:
  • xrdp Installation zypper install xrdp
  • Service starten: systemctl start xrdp
  • xfce Installation: zypper in -t pattern xfce
  • Konfigurationsdatei: /etc/xrdp/startwm.sh
• FreeBSD:
  • xrdp Installation pkg install xrdp
  • Service aktivieren:
    • echo xrdp_enable="YES" >> /etc/rc.conf
    • echo xrdp_sesman_enable="YES" >> /etc/rc.conf
  • xfce Installation: pkg install xfce
  • Konfigurationsdatei: /usr/local/etc/xrdp/startwm.sh

NetBSD und OpenBSD haben xrdp leider nicht in ihren Repositories.

Die Window-Manager Start-Scripts am Ende von startwm.sh lauten wie folgt:

• GNOME Desktop: exec gnome-session
• KDE: exec startkde
• MATE: exec mate-session
• Cinnamon: exec cinnamon
• Xfce4: exec startxfce4
• LXDE: exec startlxde

Installation unter Docker

Ja, auch das funktioniert. Man kann xrdp und einen Window Manager auch in einem Docker Image installieren und dann den RDP-Port am Container freigeben. So kann man sich dann per Remote Desktop in den laufenden Container verbinden und arbeiten.

Hier kann man also ohne eigene VM “mal schnell” ein Projekt in Docker auschecken, debuggen und das Ergebnis wieder zurückschreiben.
Es gibt zwei Spezialitäten:

1. Man muss einen User-Account anlegen oder ein Root Passwort setzten, damit man sich per RDP auch einloggen kann.
2. Die Installation der GUI kann manchmal Eingaben verlangen, die man wegen Docker deaktivieren muss. Unter Debian ruft man hierfür jeden apt Befehl mit der Environment Variable DEBIAN_FRONTEND=noninteractive auf.

Mein Dockerfile hierfür sie so aus.

 FROM debian
 
 # update download repository
 RUN apt update
 
 # install some system utilities
 RUN apt install -y sudo mc nano wget curl
 
 # install build tool chain
RUN apt install -y build-essential gdb cmake cmake-curses-gui git subversion

# install GUI environment
RUN DEBIAN_FRONTEND=noninteractive apt install -y xrdp lxde kdevelop mousepad

# create user "coder" with password "secret"
RUN useradd -ms /bin/bash coder 
RUN echo "coder:secret" | chpasswd 

# allow user "coder" to run "sudo"
RUN adduser coder sudo
RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

# switch to user account "coder" in container session
USER coder
WORKDIR /home/coder

# on container startup -> load xrdp service
EXPOSE 3389
ENTRYPOINT sudo /etc/init.d/xrdp start && /bin/bash

Fazit

xrdp ist einfach ein super Werkzeug für Menschen wie mich, die mit grafischen IDEs einfach besser auskommen als mit einer primitiven Konsole.

Und die Idee, dass man sehr einfach einen Terminal-Server aufsetzen kann, auf dem mehrere Leute arbeiten können, ist ja auch nicht schlecht.

Ich habe dieses Tool leider viel zu spät kennengelernt. Vor 15 Jahren hätte es das geben sollen!

Der Punkt geht also an: “Früher war eben NICHT alles besser”