Univention Bugzilla – Bug 11952
Kein VNC Zugang zu Thinclient/Krfb
Last modified: 2010-11-17 15:33:59 CET
Auf einem Thinclient wurde per Krfb der Remote Access freigegeben ("ohne Einladung"), trotzdem kann weder per krdc noch per xtightvncviewer eine Verbindung zum Terminal hergestellt werden (32bit Terminal + Bootserver). Muss hier statt dessen als Ziel der Verbindung der Terminalserver angegeben werden?
Tobias, bitte mal versuchen das Verhalten nachzustellen und nach einer Lösung suchen.
Ich konnte das Verhalten wie beschrieben nachstellen. Nach der Freigabe des Desktops wird kein Server gestartet, weder auf dem Terminalserver noch auf dem ThinClient. Startet man von Hand z.B. einen vncserver, so kann man diesen auf dem Terminalserver erreichen. Dann kann z.B. ein XTerm gestartet werden. Die vollständige Sitzung konnte ich nicht weiterleiten. Ich werde die Situation mal auf der KDE Mailingliste beschreiben und nach einer Lösung fragen.
Auf mein Posting vom 17.08.08 auf der kde-mailingliste gab es bislang keine Anwort.
Arvid, du hattest seinerzeit Bug #10053 bearbeitet. Siehst du noch eine andere Möglichkeit? Für Managed- und Mobile-Clients reicht die krfb-Variante. Das funktioniert für amd64 und für i386. Für die Thin Client-Umgebung benötigen wir nur eine i386-Variante, hier könnten wir ggf. das alte Modul reaktivieren.
x11vnc (http://www.karlrunge.com/x11vnc/) ist noch unter aktiver Entwicklung. http://www.debianadmin.com/remotely-administring-machines-using-x11vnc.html und lässt sich wohl auch auf LTSP-Clients zum Laufen bringen: https://wiki.edubuntu.org/InstallX11VncOnLtspClients. Genrell wären x11vnc oder xf4vnc wohl auch aus Gründen der CPU-Last krfb vorzuziehen, letzteres allerdings wegen X-Server typischer Dependencies und Komplexität des Sourcetrees schwer zu bauen. Es gibt wohl auch aus diesem Grund derzeit kein deb-Paket für xf4vnc (Berichte über segfaults unter 64bit). KDE hat für 4.0 in krfb Support für die "Damage" X-Extension aufgenommen (http://bugs.kde.org/show_bug.cgi?id=79451), wodurch die Performance besser werden könnte (siehe auch http://people.freedesktop.org/~mallum/xdamagevnc.c). FreeNX bietet wohl leider keine Alternative für 64bit. Eine Notiz unter http://wiki.skolelinux.de/FreeNx verweist auf das NX-LTSP Paket des Projekts http://sourceforge.net/projects/symbiont/.
Gut, dann sollte x11vnc mal getestet werden. Janek, bitte teste mal, ob das grundsätzlich im Thinclient-System verwendet werden könnte.
Folgende beiden Möglichkeiten für VNC auf einem Thinclient habe ich mit meinem 2.1 Master und einem VMware-Thinclient erfolgreich getestet. Möglichkeit 1 "x11vnc" ---------------------- root@terminalserver$ univention-thinclient-apt install x11vnc Dann muss man auf dem Thinclient (nicht auf dem Terminal-Server), also per SSH als der angemeldete Benutzer luser@thinclient$ x11vnc ausführen. Danach kann man mit someone@somewhere$ xtightvncviewer "$ThinclientAdresse" eine VNC Sitzung starten. Möglichkeit 2 "krfb" -------------------- root@terminalserver$ univention-thinclient-apt install krfb Installiert relativ viele Pakete (~ 60MiB) Dann muss man auch auf dem Thinclient, also auch per SSH "krfb" starten. Dazu muss noch die "$DIPLAY"-Variable gesetzt werden: luser@terminalserver$ ssh luser@thinclient "DISPLAY='$DISPLAY' krfb" Dann kann man krfb konfigurieren und sich mit "krdc" verbinden: someone@somewhere$ krdc "$ThinclientAdresse" Beide Möglichkeiten erfordern die Ausführung des Programmes lokal auf dem Thinclient. x11vnc ist wohl leichgewichtiger, wohingegen krfb komfortabler ist.
Wir könnten die Programme in einem GDM-Session-Skript starten. Benötigen die Programme viele Ressourcen?
Bei einer Auflösung von 1024x786 benötigt x11vnc ~8MiB RAM und die CPU-Zeit ist ungefähr 10% des Xorg (wobei das natürlich von der Komprimierung abhängt) Mehrere Clients am x11vnc-Server schlagen mit ungefähr 1MiB pro Client zu buche. (Getestet mit Konqueror in /usr/bin und Firefox gleichzeitig) krfb folgt...
Der krfb Konfigurationdialog genehmigt sich 14MiB, und die Sitzung kostet dann nochmal 19MiB. Außerdem ist der Client um einiges langsamer.
Gut, dann ist x11vnc wohl der richtige Weg. Ich würde folgendes vorschlagen: - derzeit ist die VNC-Freigabe Einstellung in der X11 Richtlinie definiert, das sollte aber besser in einer Richtlinie für den Benutzer eingestellt werden - im GDM Pre-Session Skript sollte die Einstellung ausgewertet werden und falls für diesen Benutzer die Einstellung aktiviert ist, sollte ein Passwort generiert werden und der VNC Server gestartet werden. Das Passwort wird dann in einer .-Datei im Heimatverzeichnis des Benutzers gespeichert - Der Benutzer bekommt in dem Fall einen Eintrag im KDE Startmenü, so dass er sich einfach das Passwort anzeigen lassen kann und dem Administrator vorlesen kann Da das etwas aufwendiger ist werden wir das für 2.x vorsehen und nicht schon für 2.1-1.
x11vnc bietet über tcl/tk8.4 auch die Möglichkeit, den Benutzer zu Fragen, ob ein versuchter VNC-Zugriff zugelassen werden soll, sowie ein Popup der über den Disconnect informiert: x11vnc -accept "popupmouse" -gone "popupmouse" Weitere Infos unter http://www.karlrunge.com/x11vnc/ bzw. http://www.karlrunge.com/x11vnc/x11vnc_opts.html
x11vnc kann auch per "remote"-Commands rekonfiguriert werden, so könnte man im Popup den Anwender entscheiden lassen ob der Helpdesk nur zuschauen darf oder auch die Tastatur oder Maus bedienen darf; das kann per "xprop" wohl auch von Client-Seite aus in laufenden Sitzungen gesteuert werden. Insgesamt sehr vielversprechend.
*** Bug 16584 has been marked as a duplicate of this bug. ***
*** Bug 11169 has been marked as a duplicate of this bug. ***
Mit univention-thin-client-vnc und univention-thin-client-vnc-config, die dafür Sorgen, dass wenn (die bereist vorhandene) VNC Richtlinie gesetzt ist, der X11vnc auf dem Thin Client gestartet wird. Es wird ein Zufallspasswort erzeugt und dem Benutzer (am X Display) beim Versuch eines Verbindungaufbaus angezeigt. Außerdem muss der Benutzer die Session bestätigen. Gebaut in UCS 2.4.
Wenn die Pakete Grundlage für die eigentliche Funktionalität der Richtlinie sind, sollten sie per default mit der Thinclient-Umgebung installiert werden.
univention-thin-client-vnc wurde als Dependency von univention-thin-client-x-base hinzugefügt.
> Es wird ein Zufallspasswort erzeugt > und dem Benutzer (am X Display) beim Versuch eines Verbindungaufbaus angezeigt. > Außerdem muss der Benutzer die Session bestätigen. funktioniert so, aber changelogeintrag _nicht_ vorhanden
Changelogeintrag comitted
verified
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".