On 17 Apr 2000, Jens-Eike Jesau wrote:
OT> Die graphische Benutzeroberflaeche von Linux.
Oliver, ich bitte dich !
Ist ja gut, ist ja gut! Ihr habt ja alle recht! Ich wollte nicht derartig ausholen! Ich dachte ja nur, wenn einer noch nicht einmal den Begriff gehoert hat, dann kann er sich darunter am ehesten was vorstellen. X ist natuerlich nicht auf Linux beschraenkt, sondern in jedem Unix-Betriebssystem der Name fuer das graphische Ausgabeprotokoll. Es ist ein netzwerkfaehiges Protokoll (X-Protocol) mit eigenstaendigem Authentifizierungs- und Autorisierungmechanismus und einem eigenen Login-Client (xdm), welche wiederum ueber ein eigenstaendiges netzwerkfaehiges Protokoll (XDMCP) eine hostbasierte Autorisierung anbietet. Die KDE-Umgebung liefert ebenfalls einen eigenen Login-Client (kdm), welcher die Konfigurationsdateien des xdm aber ausliest. Andere Unixe liefern u.a. den CDE mit, der wiederum seinen eigenen Login-Manager mitliefert (dtlogin). Mit dem lokal auf einer Maschine laufenden X-Server kommunizieren X-Clients, z.B. graphisch orientierte Anwendungen eben ueber das X-Protokoll. Die Kommunikation erfolgt hierbei bei lokalen Anwendungen sinnvollerweise ueber Unix Domain Sockets (DISPLAY =:0 o.ae.) oder ueber TCP/IP (DISPLAY = localhost:0.0 o.ae.). Fuer letzteres sollte natuerlich auch TCP/IP laufen. Ueber TCP/IP sind dann auch Host-to-Host-Verbindungen moeglich, weswegen man z.B. Anwendungen, die auf einem remote-Host laufen, auch lokal anzeigen lassen kann. Port-Nr. fuer TCP/IP Sockets ist lokal dann meist 6000+$DISPLAY-Nr. Es gibt verschiedene Methoden, die Zugriffsrechte fuer X-Clients auf den X-Server zu regeln. Die einfachste, aber unsicherste Methode ist, dem "xhost"-Client die Rechnernamen mitzuteilen, welche sich an den X-Server binden koennen: "xhost +rechner" fuegt den Rechner "rechner" an die Liste der erlaubten Hosts an. Besser ist, den MIT-Magic-Cookie-Mechanismus zu verwenden. X_Clients duerfen hierbei nur dann an den Server konnektieren, wenn sie ein "Geheimwort" mitteilen koennen, eben das Magic Cookie. Dieses befindet sich normalerweise in der ".Xauthority" desjenigen Users, der die XSession eroeffnet hat (= der, der sich unter X eingeloggt hat) und muss dem X-Client zugaenglich gemacht werden, entweder indem die Clients das ".Xauthority"-File auslesen koennen, oder explizit durch Verwendung des Kommandos "xauth". Kurz: MIT-Magic-Cookie funktionieren User-basiert, xhost funktioniert Host-basiert. X-Clients kennen sog. "Resources", die z.B. festlegen, wie das aeussere Erscheinungsbild eines X-Programms aussehen soll. Diese koennen entweder dem Client mitgegeben werden (durch Optionen oder Xdefaults bzw. /usr/lib/app-defaults-Dateien) oder direkt in den Server geladen werden (mit dem "xrdb"-Client). Im einen Fall wirken die Resourcen gleich, egal vor welcher Maschine man sitzt, im anderen Fall wirken dioe Resourcen, egal, auf welcher Maschine das Programm laeuft. So, ich denke, das war jetzt aber erst mal ausfuehrlich genug fuer den Anfang, stehe aber fuer weitere Fragen jederzeit gerne zur Verfuegung. Viele Gruesse Oli /********************************************\ * * * Oliver Tennert * * * * +49 -7071 -9457-598 * * * * e-mail: O.Tennert@science-computing.de * * science + computing GmbH * * Hagellocher Weg 71 * * D-72070 Tuebingen * * * \********************************************/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com