Univention Bugzilla – Bug 19953
xrdp als RDP Proxy
Last modified: 2023-03-25 06:50:57 CET
> Der direkte Zugriff über Micorsofts Remote Desktop Protocol (RDP) ist möglich. > Die mit dem Client über virtuelle Kanäle verbundenen Infrastrukturen sind als > RDP-Proxy realisiert und Drucker, Sound und USB werden unterstützt und > angesprochen. Dafür sollte die aktuelle xrdp-Version importiert und gebaut werden. Zusätzlich sind einige Patches bzgl. Sound / Drucker Unterstützung über die Mailingliste geschickt worden. Ggf. ist eine Integration sinnvoll.
Laut <http://xrdp.sourceforge.net/> ist das letzte Release 0.4.1 von 2008-07-18, im git-Tree ist 0.5.0 in Arbeit. Anscheinend keine USB-Unterstützung. Soundimplementierung ist vorgesehen, aber Datei ist leer.
Dort sind mal einige Patches über die Liste gegangen, beispielsweise: http://www.mail-archive.com/xrdp-devel@lists.sourceforge.net/msg00055.html Auch gibt es andere Planungen: http://www.mail-archive.com/xrdp-devel@lists.sourceforge.net/msg00241.html
Das Paket xrdp wurde jetzt aus Debian Squeeze importiert ist jetzt im Scope opendvdi verfügbar.
Der Zugriff mit Windows 7 clients ist laut dem Bugtracker vom xrpd Projekt nicht möglich
Der ist gefixt: * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572764 Der ältere Bug-Report ist ohne Details und scheint upstream keine Beachtung zu finden: * http://sourceforge.net/tracker/index.php?func=detail&aid=2714392&group_id=112022&atid=665246
Ryan Rafferty hat im Juni seine Anpassungen für die an Comment 2 erwähnte Planung an die Liste geschickt. http://www.mail-archive.com/xrdp-devel@lists.sourceforge.net/msg00325.html Seinen aktuellen Code kann man aus dem https://launchpad.net/posixrdp Projekt ziehen. Ganz stabil scheint das zwar noch nicht zu sein, könnte man mal compilieren testen.
Es ist jetzt ein Snapshot aus dem upstream bzr repository als Debian Paket in ucs_2.4-0-experimental importiert, das baut aber so noch nicht direkt: ./configure: line 19931: syntax error near unexpected token `PULSE,' ./configure: line 19931: ` PKG_CHECK_MODULES(PULSE, libpulse >= 0.9.11,' make[1]: *** [override_dh_auto_configure] Error 2 make[1]: Leaving directory `/tmp/buildd/xrdp-0.5.0~20101104bzr'
Der xrdp (In reply to comment #6) > Ryan Rafferty hat im Juni seine Anpassungen für die an Comment 2 erwähnte > Planung an die Liste geschickt. > http://www.mail-archive.com/xrdp-devel@lists.sourceforge.net/msg00325.html > > Seinen aktuellen Code kann man aus dem https://launchpad.net/posixrdp Projekt > ziehen. Ganz stabil scheint das zwar noch nicht zu sein, könnte man mal > compilieren testen. Der Code kompiliert nicht richtig, aufgrund von groben Fehlern. Ich musste teilweise Stellen auskommentieren um das überhaupt zum laufen zu bringen. Die RDP Sessions haben alle einen Grünstich.
Created attachment 2805 [details] Der Patch um version aus dem Bazaarrepository zum Kompilieren zu bringen.
Created attachment 2809 [details] Die Veränderungen von xrpd zu posixrdp
Ein bisschen mehr Doku zu XRDP ist jetzt im Wiki festgehalten unter https://hutten.knut.univention.de/mediawiki/index.php/XRDP Die Sound und Print-Channel Erweiterungen von Ryan Rafferty (Comment 6 und Comment 10) scheinen nur Variante 3 und 4 der vier Betriebs-Modi von XRDP zu betreffen. Was wir hier versuchen, ist Variante 1, RDP-Proxy Mode: http://xrdp.sourceforge.net/documents/xrdpdesign/index.html sagt dazu: * "Librdp, an RDP module for xrdp. Librdp provides a connection to RDP servers. It only supports RDP4 connections currently." Wikipedia sagt über RDP-Protokol-Level: * Sound Support ab RDP 5.1 * "printing to local printers" ab RDP 5.0 Bei librdp scheint es sich um einen recht frühen Fork von rdesktop zu handeln. Wenn man Sound über XRDP haben will, sind folgende Varianten "denkbar": * XRDP in Variante 4 konfigurieren (siehe oben) und dann rdesktop auf dem XRDP-Host statt Windowmanager starten. Theoretisch möglich, aber ggf. auch ziemlich aufwendig, Erfolg ungewiss. * Frischzellenkur für librdp aus aktuellem rdesktop-Gewebe. Vermutlich sehr aufwendig.
Der 'rdpproxy' aus dem rdesktop-Repository ist in diesem Zusammenhang interessant, aber leider zur Zeit nur eine Entwicklertool. Es lauscht auf dem RDP-Port und connected zu einem Server, der auf der Kommandozeile angegeben wird: * http://rdesktop.svn.sourceforge.net/viewvc/rdesktop/rdpproxy/trunk/README?revision=1488
Seit 2009/Q3 gibt es einen Fork des rdesktop Projekts, an dem Jay Sorg (xrdp) von Anfang an mitarbeitet: http://freerdp.com/. Primäre Ziele des Forks sind: * Aufteilung des rdesktop-Codes in eine Bibliothek und mehrere Clients * beschleunigte Weiterentwicklung Richtung RDP6 Ein kurzer Test, libfreerdp in xrdp zu laden, schlug fehl. Ich habe dazu eine Anfrage an xrdp-devel geschickt (http://sourceforge.net/mailarchive/forum.php?forum_name=xrdp-devel&viewmonth=201011&viewday=16).
Es gibt jetzt ein Quellpaket univention-xrdp, das ein Binärpaket univention-dvs-xrdp-config baut, welches die Datei /etc/xrdp/xrdp.ini aus den univentionDVSWindowsDomain Attributen der univentionPolicyDVS Objekte erzeugt. Da nach Änderung der Konfigurationsdatei xrdp neu gestartet werden muss (xrdp kennt bisher keinen cfg-reload), ist das Skript zum Erzeugen der Datei jetzt erstmal als UCR-Skript realisiert, das einmalig im postinst aufgerufen wird. Wenn Attribute univentionDVSWindowsDomain verändert wurden, muss es händisch neu aufgerufen werden (z.B. einfach per --reinstall von univention-dvs-xrdp-config). Warum das Ganze? Damit xrdp mit "rdesktop -d DVSDOMAIN" klarkommt, muss in der xrdp.ini je eine Sektion "[DVSDOMAIN]" existieren. Das Standard xrdp 0.5.0~20100303cvs Debian-Paket mit dem Sessionbroker-Patch (Bug 20525) sollte sich dann einfach per univention-dvs-xrdp-config installieren lassen. Ich mache diesen Bug jetzt erstmal zu, für die Sound/Channel Erweiterung gibt es jetzt Bug 20717, das dauert aber wohl noch ein bisschen, da der Upstream-Entwickler heute erst bekundet hat, dass er da nun erste Schritte für die Integration umsetzen will.
Der Ansatz für die Übergabe von univentionDVSWindowsDomain ist nicht korrekt, das muss von xrdp dynamisch aus dem Session-Broker ermittelt werden, dafür ist Bug 20525, Comment 7 wieder offen. An diesem Bug muss das Template für die xrdp.ini angepasst werden.
Ist jetzt angepasst, Bug 20525, Comment 9 muss daraufhin jetzt noch umgesetzt werden.
Die Kommunikation mit univention-dvs-sessionbroker-client funktioniert nicht.
Das Problem war, das der xrdp nicht mit der Anpassung für das base64-Encoding der Passwortdatei aus UCS TCS 3.1 klarkam. Ich habe jetzt im univention-dvs-sessionbroker-client eine neue Option '--base64'/'-b' eingebaut, über die in UCS TCS 4.1 im gdm Sessionskript 'DVS' das base64-Decoding aktiviert wird und im '--xrdp' Mode wird per default weiter ohne base64 gearbeitet. Zusätzlich wurde xrdp so angepasst, der der returncode von lib_mod_connect (in rdp.c) durch den call-stack wieder bis zum xrdp_process_main_loop hochgereicht wird. Dadurch wird bei einem Fehlschlag des DVS-Session-Aufbaus durch den univention-dvs-sessionbroker-client (z.B. falsches Passwort) die RDP-Verbindung beendet, statt ewig hängen zu bleiben.
Der XRDPd läuft jetzt wieder wie gewünscht.
Beim Booten eines neu eingerichteten TCs erschien ein XMessage-Dialog mit der Aufforderung, einen Windows-Terminal-Server für den TC einzurichten. In der Auswahlliste im UDM fehlt allerdings der Rechner, auf dem der xrdp-Proxy läuft. Das DoJo-Element hat sich auch hartnäckig geweigert, das ich das einen eigenen Hostnamen eintragen surfte. Per CLI hat es allerdings funktioniert: udm policies/thinclient modify --dn cn=default-settings,cn=thinclient,cn=policies,dc=opendvdi,dc=local --set windowsTerminalServer=xen2.opendvdi.local