ABSTRACT: das Xerver konzept wird wiederhohlt. xhosts, xauth authorisierung, und die DISPLAY variable werden erklaert. AUDIENCE: advanced users SYSTEM: any unix SECTION: basic unix commands AUTHOR: mond COPYRIGHT: GNU Free Documentation Licence http://www.gnu.org/licenses/fdl.txt eine kurze einfuehrung in die funktionsweise von X11 hatten wir ja schon. zur widerhohlung. das Xwindows system besteht aus folgenden komponenten: * einer (relativ "dummen") anzeigeoberflaeche namens Xserver. ("dumm" hier im sinne von: ohne viel eigene inteligenz. fuehrt nur die zeichenbefehle vom server aus. - was als konzept natuerlich gar nicht "dumm" ist) * Xclient programmen. die via netzwerk (oder lokal) auf dieser anzeigeoberflaeche ihre ausgaben machen. (z.b. xterm, xeyes, gimp, .. ) * einem window manager. ein windowmanager ist ein spezieller Xclient der das verschieben der fenster und aehnliches erledigt. * einem display manager (z.b. xdm) der ein login auf der X11 obeflaeche erlaubt. wichtigs dabei ist zu verstehen dass die anzeigeoberflaeche ("der Xserver") nicht auf der selben maschine laufen muss wie die client programme. die client programme koennen z.b. auf einem oder mehreren zentralen applikationsserver laufen waehrend die anzeigeoberflaeche von einfachen terminals erledigt wird. die meisten freien unixe verwenden als lokalen Xserver den XFree86. dank der mitarbeiter vieler freiwilliger programmierer werden heute fast alle grafikarten von XFree86 unterstuetzt, auch wenn die manche hersteller dieser karten dies nicht immer wirklich unterstuetzen indem sie keien ausreichende dokumentation ueber die karten ausgeben. kurz zur konfiguration von XFree86: sie liegt ueblicherweise in: /etc/X11/XF86Config hat man noch keine laufende XFree86 Configuration so kann man z.b. mit dem programm "xf86config" eine solche erstellen. mehr dazu lernen wir ein andermal. heute sezten wir nochmals einen laufenden Xserver voraus: sind wir auf einem rechner eingelogt und starten wir ein X programm. z.b: xterm & so wird dieses programm versuchen seine ausgabe auf den Xserver zu verbinden der durch die variabel "DISPLAY" angegeben ist: echo $DISPLAY zeigt uns die variable. koennte z.b: blablakiste:1.0 sein. das waere ein rechner namens blablakiste und dort den X bildschirm mit der nummer 1. wenn wir mit ssh -X irgendeinekiste.irgendwo.at einlogen so macht das ssh fuer uns ein X-forwarding. d.h. es setzte die DISPLAY variable am zielrechner auf einen tunnel der die kommunikation der Xclients mit dem Xserver durch den tunnel durchreicht. die kommunikation ist damit verschluesselt und man sieht fuer den lokalen Xserver so aus als wuerde sie vom lokalen ssh programm ausgehen. der hat ohnehin das recht mit dem lokalen Xserver zu kommunizieren und alles funktioniert. will man ohne ssh tunnel direkt eine X ausgabe auf einen anderen rechner leiten so kann man das durch verbiegen der DISPLAY variable tun. z.b: export DISPLAY=testkiste.irgendwo.at:0.0 starten wir danach xterm & wird dies vermutlich fehlschlagen weil nicht jeder dahergelaufende Xclient einfach irgendwo eine verbindung auf einen X-beliebigen Xserver machen darf.. um die verbindung zu erlauben gibt es 2 moeglichkeiten. 1.) xhost damit kann man alle verbindungen erlauben die von einem host (einer IP addresse) ausgehen. machen wir z.b. auf der "testkiste" ein xhost +blechiste.irgendwo.at wuerde auf die testkiste alle X verbindungen von "blechkiste" erlauben. das ist i.a. nicht besonders gut: jeder der einen account auf blechkiste hat kann dann ausgaben auf unseren bildschirm machen. noch schlimmer: spezielle Xclients existieren die das "abhoern" von tastatureingaben erlauben. oder jemand auf bleckiste kann sich einen screenshot abholen und so sehen was wir gerade tun... xhost -blechkiste.irgendwo.at hebt die erlaubniss fuer die blechkiste wieder auf. besser als xhost ist daher: 2.) xauth xauth verwalte einen satz von schluesseln (cookies genannt) im file .Xauthority. fuer jeden rechner auf den wir uns mit X11 verbinden wollen einen. jeder neu gestartete Xserver laesst verbindungen nur mit dem richtigen xauth-cookie zu. (achtung: alte startx scripts starten den Xserver in einem modus ohne den xauth mechanismus. man sollte daher seinen lokalen Xserver am besten mit xdm starten) xauth list gibt die liste aller xauth-cookies aus. hat man ein gemeinsamens homeverzeichniss (z.b. via nfs ) auf verschiedenen rechnern so wird damit das cookie automatisch weitergegeben. ohne gemeinsames homeverzeichniss kann man entweder das .Xauthority file kopieren (brutalmethode) oder man kopiert mit cut&paste ueber eine shell das cookie indem man es auf der einen seite mit "xauth list" auflistet und auf der anderen mit: xauth add testkiste:0 MIT-MAGIC-COOKIE-1 a71323d67f990294a062a7af8899ffa wieder fallen laesst. da das .Xauthority file nur fuer andere benutzer (ausser root) nicht lesbar ist koennen jetz nur noch die eigenen Xclient programme auf unseren bildschirm auf der teskiste connecten. nachteil einer direkten weiterleitung von X11 ohne ssh tunnel ist aber dennoch dass der netzwerkverkehr unverschluesselt erfolgt. EXERCISES: * schau dir deine DISPLAY variable auf verschiedenen rechnern an * versuche X11 weiterleigung via ssh -X tunnel. schau dir dabei die DISPLAY variable an. * versuche eine haendische weiterleitung durch umbiegen der DISPLAY variable. * gib dir dabei probehaler die erlaubniss zum connecten via xhost und danach via xauth. diskutiere die vor und nachteile. wer kann in welchem fall deinen bildschirm abhoeren? REFERENCES: man xauth man xhost man X