!!! 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
}}}
liefert.

!! 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.


----
[{Tag ServerDienste Virtualisierung ThinClient}]