VNC Server#

VNC ist ein Server und Client, um eine komplette Desktop-Session auf einen anderen Rechner umzulenken. Für Linux gibt es eine ganze Reihe von Implementationen. Sehr interessant ist jedoch, daß VNC komplett plattformunabhängig ist, daß man also auch von Linux aus einen Windows-Rechner fernsteuern kann und umgekehrt. Wer damit herumspielen will, sollte sich mal die Pakete ansehen, die

  aptitude search vnc

dauernden Eingang#

Hier stelle ich eine einfache Lösung vor, die einen permanenten Zugang auf einem Rechner installiert. Man kann sich dann jederzeit in den laufenden X-Server dieses Rechners einklinken, sehen, was dort gemacht wird und auch selber tippen und klicken.

Eine einfache und sehr schöne Lösung für dieses Problem ist krfb, das man im KDE-Menü unter "System / Arbeitsfläche freigeben" finden kann. Will man jedoch eine permanente Möglichkeit, sich einzuloggen, so muss man anders ansetzen. Um einen Rechner komplett aus der Ferne warten zu können und sich z.B. auch einloggen zu können, muss man den VNC-Server schon im kdm starten. Hierzu mache ich folgendes:

  aptitude install x11vnc
  echo "x11vnc -o /var/log/x11vnc.log -forever -bg -passwdfile /etc/x11vnc.passwd" >>/etc/kde3/kdm/Xsetup
  echo "meinpasswort" >/etc/x11vnc.passwd

dauernder Eingang für LinuxTerminalServer-Clients#

Bei meiner LinuxTerminalServer-Installation war es in der Anfangszeit zum Testen des Systems oftmals sehr nützlich, die Clients fernsteuern zu können. Im laufenden Betrieb kann man das auch sehr schön (mit graphischer Oberfläche einzeln für jeden Benutzer einstellbar) über krfb machen. Leider hatte ich hier das gleiche Problem: krfb startet erst, wenn der Benutzer sich eingeloggt hat. Die oben angegebene Lösung musste für dieses Setup leicht verändert werden. Ich habe ein LTSP-Paket aus dem x11vnc-Paket gebaut (siehe DosEmuAufLTSPClient wie sowas geht) und dann folgendes in die Datei /etc/kde3/kdm/Xsetup auf dem Terminalserver gesetzt:

  logger Display $DISPLAY gestartet
  CLIENT=${DISPLAY/:*/}
  LOGIN="root@$CLIENT"
  DISPNO=${DISPLAY/*:/}
  DISPNO=${DISPNO/\.*/}
  xhost $CLIENT
  ssh "$LOGIN" "sleep 10; x11vnc -o /var/log/x11vnc.log -forever -bg -passwdfile /etc/x11vnc.passwd -display $DISPLAY -rfbport $((5900+$DISPNO))" &

Dazu muss noch eine passwortlose Authentifizierung per OpenSSH von root auf dem Terminalserver zu root auf den Clients eingerichtet werden. Dies ist IMHO gefahrlos. Wer root auf dem Terminalserver ist, kann eh die Clients manipulieren, soviel er will.

Der x11vnc muss (wegen direkter Speicherzugriffe) auf dem Client laufen. Außerdem schon das die Ressourcen des Servers und verhindert zusätzlichen Netzwerkverkehr, weil man von aussen direkt auf den Client zugreift.

Die logdatei von x11vnc liegt "nur" im RAM des Clients, was aber zum Debuggen reicht. Hat man mehrere virtuelle X-Konsolen an dem Client eingerichtet (um es in LTSP-Slang zu sagen: mehrere Screen-Skripts als startx eingerichtet), sind diese alle auf verschiedenen VNC-Ports aufrufbar.

Probleme mit KDE4#

Auf meinem System sieht die Ausgabe grauenhaft aus. Farben stimmen nicht, Fensterränder haben die falsche Farbe und sind voller Pixel, die ich da nicht bestellt habe und das PAnel (die Leiste am unteren Rand) ist überhaupt nicht zu erkennen. Laut http://www.pubbs.net/200910/archlinux/41112-arch-general-why-does-kde4-over-vnc-look-bad-if-host-is-archlooks-fine-if-suse.html passiert das immer, wenn ein X-Server QT4 benutzt und die RENDER-Extension nicht unterstützt. Das bestätigt meine negative Meinung von QT4 bzw. KDE4, hilft aber auch nix. :-(

Nach obiger Seite sollte der VNC-Server xf4vnc-xvnc gehen. Ich selber habe tightvncserver im Einsatz, womit die Probleme auftreten.