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

Unixian 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 matü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 erstetzt 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:

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.

 1FROM debian
 2
 3# update download repository
 4RUN apt update
 5
 6# install some system utilities
 7RUN apt install -y sudo mc nano wget curl
 8
 9# install build tool chain
10RUN apt install -y build-essential gdb cmake cmake-curses-gui git subversion
11
12# install GUI environment
13RUN DEBIAN_FRONTEND=noninteractive apt install -y xrdp lxde kdevelop mousepad
14
15# create user "coder" with password "secret"
16RUN useradd -ms /bin/bash coder 
17RUN echo "coder:secret" | chpasswd 
18
19# allow user "coder" to run "sudo"
20RUN adduser coder sudo
21RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
22
23# switch to user account "coder" in container session
24USER coder
25WORKDIR /home/coder
26
27# on container startup -> load xrdp service
28EXPOSE 3389
29ENTRYPOINT 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”


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!