 |
Vorlesung "UNIX"von Prof. Jürgen Plate |
|
Vorlesung "UNIX"von Prof. Jürgen Plate |
Als Ken Thompson 1969 bei Bell Laboratories, die Entwicklung eines neuen Betriebssystems begann, waren die meisten der vorhandenen Systeme ausgesprochene Batch-Systeme. Der Programmierer gab seine Lochkarten oder Lochstreifen beim Operator ab, diese wurden in den Rechner eingelesen und ein Rechenauftrag nach dem anderen abgearbeitet. Der Programmierer konnte dann nach einiger Zeit seine Ergebnisse abholen.
Ziel von Ken Thompsons Entwicklung war es deshalb, ein System zu schaffen, auf welchem mehrere Programmierer im Team und im Dialog mit dem Rechner arbeiten, Programme entwickeln, korrigieren und dokumentieren konnten, ohne von einem Großrechner mit allen seinen Restriktionen abhängig zu sein. Dabei standen Funktionalität, strukturelle Einfachheit und Transparenz sowie leichte Bedienbarkeit im Vordergrund der Entwicklung. Dieses erste System mit dem Namen UNIX lief auf einer DEC PDP-7. Die erste Version von UNIX war dabei in der Assemblersprache der PDP-7 geschrieben. Um bei künftigen Projekten die Maschinenabhängigkeit durch eine maschinennahe Sprache zu umgehen, entwarf Thompson die Programmiersprache B, aus der dann Dennis Ritchie die Sprache C entwickelte.
UNIX wurde 1971 in C umgeschrieben und auf die PDP-11 übertragen. Von nun an erfolgte die Weiterentwicklung des Systemkerns sowie der meisten Dienstprogramme in dieser Sprache. Die Kompaktheit und strukturelle Einfachheit des Systems ermunterte viele Benutzer zur eigenen Aktivität und Weiterentwicklung des Systems, so daß UNIX recht schnell einen relativ hohen Reifegrad erreichte. Dies ist deshalb bemerkenswert, da kein Entwicklungsauftrag hinter diesem Prozeß stand und die starke Verbreitung von UNIX nicht auf den Vertrieb oder die Werbung eines Herstellers, sondern primär auf das Benutzerinteresse zurückzuführen ist. Eine ähnliche Entwicklung zeigt sich seit einigen Jahren bei den freien UNIX-Varianten.
Im Lauf der Zeit sind zwei Entwicklungszweige entstanden, da UNIX sowohl bei Bell Labs (AT&T) als auch an der Universität von Berkley weiterentwickelt wurde: "BSD" und "System V". Daneben gibt es zahlreiche weitere UNIX-Derivate, z. B. die frei erhältlichen Systeme "Free BSD" und "Linux" für PCs.
Die Dialogschnittstelle zur Kommunikation mit dem Benutzer (zeichenorientiert) wird dabei als Shell bezeichnen. Diese Shells unter UNIX haben dabei zwei Funktionen, sie werden
Kommandointerpreter = Shell:
Damit jeder dieser Benutzer seine Daten vor dem Zugriff der anderen Benutzer schützen kann, muß man sich, bevor man mit einem Unix-System arbeiten kann, erst einmal anmelden, das heißt, einen speziellen Benutzernamen und ein Passwort eingeben. Dadurch erfährt das System, welcher Benutzer da gerade die Arbeit aufnehmen möchte, und kann diesem Benutzer seine persönliche Arbeitsumgebung (inclusive aller privater Daten) zur Verfügung stellen.
Nach dem Einschalten des Terminals bzw. nach Aufnahme der Verbindung mit dem UNIX-Rechner meldet sich das BS mit der Aufforderung, sich zu identifizieren:
login:
Der Benutzer gibt darauf den ihm zugewiesenen Login-Namen ein. Dann erscheint die Abfrage des Paßwortes:
password:
Nun muß der Benutzer sein Passwort eingeben. Das Passwort wird im Gegensatz zu den üblichen Eingaben nicht auf dem Bildschirm ausgegeben. Wenn alles gutgeht, sind Sie jetzt beim System angemeldet (man sagt auch: eingeloggt). Sie erkennen die erfolgreiche Anmeldung daran, daß die Eingabeaufforderung des Systems, der sog. Prompt erscheint. Der Prompt sieht etwa so aus:
benutzername@sun1-lbs$
und dahinter ist ein Cursor sichtbar (die Texteinfügemarkierung) und das System erwartet nun die Eingabe eines Kommandos.
Hat sich der Benutzer vertippt, erscheint die Meldung:
login incorrect
und die o. g. Prozedur muß wiederholt werden. Neue Benutzer haben noch kein Passwort, sie drücken nur die RETURN-Taste bei der Frage nach dem Passwort. Bei vielen Systemen wird der Benutzer beim ersten Login zur Eingabe des Passwortes aufgefordert. Zum Ändern und Eingeben des Passworts gibt es ein eigenes Kommando:
passwd
Das Passwort muß einigen Bedingungen genügen:
Beim Einschalten des Rechners werden zunächst Systeminitialisierungsroutinen durchlaufen und die einzelnen Platten des Systems in das Dateisystem eingebunden ("mount"). Je nach BS-Version gelangt das BS dann gleich in den Mehrbenutzerbetrieb oder in den Einzelbenutzerbetrieb (single user mode). Dieser Modus ist speziell für die Systemwartung notwendig, wenn kein anderer Benutzer den Rechner verwenden darf (z. B. Generieren einern neuen Systemversion, Benutzerverwaltung, Datensicherung, etc.). Vom Einzelbenutzerbetrieb wird dann der normale Mehrbenutzerbetrieb gestartet. Beim Abschalten des Systems wird umgekehrt verfahren. Alle noch laufenden Prozesse werden gestoppt (normalerweise mit vorheriger Warnung der noch aktiven Benutzer, damit diese ihre Arbeit in Ruhe beenden können), das Dateisystem aktualisiert (Schließen offener Dateien, Wegschreiben von Pufferbereichen) und in den Einzelbenutzerbetrieb übergegangen. Danach kann abgeschaltet werden.
Fast jedem Kommando kann eine Liste von Dateien mitgegeben werden, auf die das Kommando dann angewendet wird. Fehlt die Dateiliste, wird in der Regel die Standardeingabe - normalerweise die Tastatur - als Eingabedatei verwendet. Wie spater noch genauer gezeigt wird, verwendet UNIX die Jokerzeichen (Wildcards) Stern (*) und Fragezeichen (?), um beliebige Zeichen innerhalb eines Dateinamens zu kennzeichnen. DOS und Windows haben diese Methode übernommen. Im Gegensatz zu DOS und Windows werden diese Wildcards jedoch nicht vom Programm, sondern von der Shell zu Dateinamen expandiert. Deshalb "sieht" jedes UNIX-Programm nur eine mehr oder weniger lange Dateiliste.
Nahezu jedes Fenster hat unter X einen Rahmen. Mit Hilfe dieses Rahmens kann man die Dimensionen und die Position des Fensters verändern. Zunächst kann man durch "Klicken und Ziehen" auf die Titelleiste des Fensters das Fenster als Ganzes bewegen und an einer anderen Stelle des Bildschirms "loslassen". "Klicken und Ziehen" bedeutet, daß man mit dem Mauspfeil auf die Titelleiste zeigt, dann die linke Maustaste drückt, festhält, und bei gedrückter Taste die Maus bewegt. Wenn das Fenster die erwünschte Position erreicht hat, läßt man die linke Maustaste wieder los.
Wenn man jetzt mit der Maus die untere rechte Ecke des Fensters ansteuert, verwandelt sich der Mauspfeil selber in eine "Ecke" (ausprobieren!). Wenn der Mauspfeil so aussieht, dann kann man durch klicken+ziehen (s.o.) die Fenstergröße verändern. Es ist nicht ratsam, die Größe der zwei Textfenster zu ändern, die gleich am Anfang erscheinen, weil viele Programme davon ausgehen, daß diese Fenster eine feste Größe haben (nämlich 80 Zeichen Breite und 25 Zeilen Höhe).
Weiterhin sind am oberen Rand des Fensters, direkt rechts neben der Titelleiste, zwei Knöpfe zu sehen: einer enthält ein großes und einer ein kleines Quadrat. Durch einmaliges, kurzes Klicken auf den Knopf mit dem großen Quadrat bewirkt man, daß das Fenster seine volle Größe annimmt, d.h. es wird in der Regel über den ganzen Bildschirm vergrößert. Ein weiteres Klicken auf diesen Knopf setzt die Fenstergröße wieder auf die Normalgröße zurück.
Der zweite Knopf, der mit dem kleinen Quadrat, bewirkt, daß das Fenster zum Symbol verkleinert wird. Das Symbol landet dann in der "Icon-Box", die in der Abbildung des gesamten X-Window-Bildschirms (oben) in der linken unteren Ecke zu sehen ist. Ein Doppelklick auf ein Icon führt dazu, daß das entsprechende Fenster wieder geöffnet und im Vordergrund angezeigt wird (d.h. ohne daß es durch andere Fenster überdeckt wird). Man kann also diese Icons auch dazu benutzen, unsichtbare (weil verdeckte) Fenster wieder in den Vordergrund zu holen.
Den Inhalt einiger Fenster (xterm) kann man mit Hilfe der Rollbalken auf der rechten Seite bewegen, und so auch bereits nach oben weggerollte Zeilen wieder sichtbar machen. Dazu plaziert man den Mauszeiger auf den schwarzen Bereich des Rollbalkens und hält die mittlere Maustaste gedrückt, während man die Maus nach oben oder unten bewegt.
Das X-Window-System wird verlassen, indem man mit der Maus auf den Hintergrund des Bildschirms klickt, dabei die linke Maustaste aber nicht losläßt, sondern bei gedrückter Taste die Maus nach unten zieht. Es erscheint ein Menü und man kann den Punkt "Exit" oder "Quit" ansteuern und dann die Maustaste loslassen. Nach einer weiteren Abfrage ("OK") ist man dann wieder auf der grünen Kommandozeile und kann mit dem Kommando "exit" die Sitzung beenden. Bei Linux geht das auch durch Drücken von Ctrl-Alt-Backspace.
Da Unix ein Multiuser-System ist, muß der Zugriff auf einzelne Dateien und Verzeichnisse vom System schon so geregelt werden, daß kein Benutzer die Daten der anderen Benutzer manipulieren oder vertrauliche Daten unbefugterweise einsehen kann. Das wird dadurch gewährleistet, daß jede Datei und jedes Verzeichnis einen Besitzer (Owner) hat, und dieser Besitzer kann mit Hilfe bestimmter Befehle festlegen, welcher der anderen Benutzer auf welche Weise auf seine Dateien zugreifen darf. Die meisten Dateien und Verzeichnisse in einem Unix-System gehören natuergemäß dem Systemverwalter (der den Usernamen "root" trägt) und jeder Benutzer kann auf diese Dateien lesend zugreifen, sie aber nicht verändern (zu dieser Art von Dateien gehören zum Beispiel alle Anwendungsprogramme, die das System zur Verfügung stellt).
Man unterscheidet grob drei Dateitypen (weitere Typen weiter unten):
Unix arbeitet mit einem Filesystem, das auf den ersten Blick dem von DOS sehr ähnlich ist (nur auf den ersten). Also gibt es eine Baumstruktur von verschiedenen Verzeichnissen (Directories), in der sich jede Datei irgendwo befindet. Beachten Sie aber, daß ein Directory beim Anzeigen zunächst genauso aussieht, wie eine Datei!. Die einzelnen Verzeichnisnamen werden durch normale Schrägstriche ('/') getrennt, NICHT durch Backslashes ('\') wie bei DOS/Windows!
Nach dem Einloggen landen Sie in Ihrem sogenannten Homedirectory (Meist '/home/username'). Es gehört Ihnen ganz alleine, damit können Sie machen, was Sie wollen. Zum Beispiel können Sie dort Dateien oder weitere Verzeichnisse anlegen. An dieser Stelle gleich einige wichtige Punkte:
/usr/projekt1/meier/test/steuerung
| steuerung | (akt. Verz.: /usr/projekt1/meier/test) |
| test/steuerung | (akt. Verz.: /usr/projekt1/meier) |
Das aktuelle Verzeichnis ist immer jenes, dessen Inhalt wir gerade bearbeiten. Das aktuelle Verzeichnis läßt sich jederzeit wechseln, aber ein Verzeichnis ist zu einem bestimmten Zeitpunkt immer das aktuelle und alle unsere Kommandos beziehen sich dann auf dieses eine, aktuelle, Verzeichnis.
Eine besondere Erwähnung verdienen die beiden Verzeichnis-Einträge "." und "..". Das sind Stellvertreter für Verzeichnisnamen, die man statt der realen Namen (abkürzend) benutzen kann. Und zwar bezeichnet "." das jeweils aktuelle Verzeichnis, und ".." das dem aktuellen Verzeichnis übergeordnete Verzeichnis.
Alle Benutzer sind in einer speziellen Datei gespeichert,
die nur der Superuser ändern darf - sonst könnte ja jeder einen neuen
Benutzer eintragen.
Jeder Benutzer kann aber sein Passwort ändern, das auch in dieser
Datei steht. Dazu muß er schreibend auf die Datei zugreifen - obwohl
er dazu keine Berechtigung besitzt. Das Programm "passwd" gehört dem
Superuser, hat das SUID-Bit gesetzt und kann so auf die User-Datei schreibend
zugreifen.
Wenn das SGID-Bit (Set Group ID) gesetzt ist, hat das Programm die Rechte
der Gruppe, zu der es gehört. Dieses Feature wird z. B. beim Drucker-Spooling
verwendet. Bei Dateien ohne Ausführungsrecht sorgt dieses Bit
dafür, daß die Datei nur von einem Prozeß geöffnet werden
kann (Vermeiden von Verklemmungen).
Bei Verzeichnissen hat das SGID-Bit eine andere Aufgabe. Dateien, die in ein
SGID-Verzeichnis kopiert werden, erhalten automatisch die Gruppe des Verzeichnisses
(man muß also nicht mehr explizit die Gruppe setzen, um den Mitgliedern einer
Gruppe Zugriff zu ermöglichen). Setzen durch das Kommando: "chmod g+s datei".
Anzeige: "s" statt "x" bei den Gruppen-Rechten ("l" bei Daten-Dateien).
Das STICKY-Bit sollte früher den Systemdurchsatz verbessern. Programme, bei denen
dieses Bit gesetzt ist, verbleiben nach dem ersten Aufruf im Speicher und
starten bei den folgenden Aufrufen schneller. Heute ist das nicht mehr nötig.
Bei Verzeichnissen dient dieses Bit der Systemsicherheit.
Auch wenn im Verzeichnis für alle User Schreibrecht existiert (= Löschen
und Anlegen von Dateien), können bei gesetztem Sticky-Bit nur Dateien
gelöscht werden, die einer folgenden Bedingungen genügen:
Schaut man sich ein physisches Dateisystem genauer an, so erkennt man den Betriebssytemblock als kleinste Einheit (im Bereich von 512 Byte bis 16 kByte). Das physische Dateisystem wird in in vier Bereiche aufgespalten:
Die Größe der einzelnen Bereiche wird bei der Initialisierung eines physischen Dateisystems festgelegt und kann im nachhinein nicht mehr dynamisch verändert werden (außer im UNIX-System AIX von IBM). Das dazu notwendige Kommando ist 'mkfs' (make file system). Die Bereiche eines physischen Dateisystems sind auf die Kapazität eines logisch Datenträgers und damit maximal auf die Gesamtkapazität eines Festplattenlaufwerks beschränkt, d. h. festplattenübergreifende physische Dateisysteme sind nicht möglich.
Die Verwaltungsinformation über Dateien steht also nicht wie bei DOS oder Windows in den Dateien selbst, sondern in den Inodes. Jede Datei besitzt einen eigenen Inode (eine eigene Datei-Nummer). Der Zugriff erfolgt entweder sequentiell (Datei ist ein Strom von Bytes ohne weitere Strukturierung) oder wahlfrei (random access) durch Positionierung auf ein bestimmtes Byte in der Datei. Das BS hat einen Cache-Mechanismus implementiert, der einen Teil der Datei im Speicher hält. Ziel: Reduzierung der Plattenzugriffe.
Problem: Dateien müssen regelmäßig aktualisiert werden (Cache-Inhalt auf die Platte schreiben), Gefahr der Inkonsistenz von Daten bei Prozeß-Abbruch oder Stromausfall.
Zu beachten ist, daß der Name der Datei nicht aufgeführt wird. Diese Systemarchitektur ermöglicht es, unter mehreren (verschiedenen) Namen als Einträge von Verzeichnissen die gleiche Datei (genauer gesagt Inode und Dateiinhalt) anzusprechen. Der Inode fungiert somit als Bindeglied zwischen dem Namen und dem Inhalt einer Datei. Für die Adressierung der Inhalte einer Datei ergibt sich eine bestimmte Verweisstruktur.
Eine Datei mit bis zu 10 Plattenblöcken (Blockgröße 512 oder 1024 Bytes) kann also direkt angesprochen werden. Größere Dateien haben zusätzlich einen Verweis (einfach indirekt) auf einen Datenblock, der seinerseits 128 Verweisfelder enthält. Reicht das noch nicht, wird zweimal (128 Blöcke mit je 128 Verweisen) oder dreimal indiziert (Dateigröße bis 2 GByte bei 512-Byte-Blöcken, bis 16 GByte bei 1KByte-Blöcken).
Das System der Links wird generell verwendet. So gibt es unter UNIX keinen Systemaufruf zum Löschen einer Datei, sondern lediglich einen Unlink-Call. Wenn der Link-Zähler einer Datei auf Null gesunken ist (durch entsprechend viele Unlink-Aufrufe), wird deren Inode und der durch die Datei belegte Plattenplatz freigegeben.
Gerätedateien dienen zur Abwicklung des Datenverkehrs zwischen den Programmen und der Peripherie. Da sie, wie die abstrakten Komponenten (normale Dateien, Verzeichnisse, usw.) einheitlich in den Systembaum integriert werden, sind auch für sie die Zugriffsschutzmechanismen und Ein- /Ausgabeumleitung gültig. Die Geräte werden durch logische Namen angesprochen, die die Gerätetreiber der Peripheriegeräte bezeichnen. Intern wird jedes Gerät durch eine Treiber-Nummer (major device number) und eine Geräte-Nummer (minor device number) markiert. Diese Nummern sind im ls -l Eintrag in dem Feld enthalten, das die Dateigröße angibt.
Es gibt bei UNIX prinzipiell zwei Typen von Treibern:
Stimmt, das Bild war weiter oben schon zu sehen. Wenn wir uns ein Verzeichnis mit dem Kommando "ls -l" ansehen, erhalten wir eine solche Liste:
total 1093 -rw-r--r-- 1 root root 116547 May 25 1997 System.map drwxr-xr-x 2 root root 1024 Sep 23 1996 bin/ drwxr-xr-x 2 root root 1024 May 25 1997 boot/ drwxr-xr-x 2 root root 1024 Oct 27 1996 cdrom/ drwxr-xr-x 3 root root 20480 May 4 15:28 dev/ drwxr-xr-x 7 root root 2048 May 4 16:05 etc/ drwxr-xr-x 5 root root 1024 Dec 7 1997 home/ drwxr-xr-x 3 root root 1024 Sep 23 1996 lib/ drwxr-xr-x 5 root root 1024 Sep 23 1996 local/ drwxr-xr-x 2 root root 12288 Sep 23 1996 lost+found/ drwxr-xr-x 2 root root 1024 Sep 23 1996 mnt/ dr-xr-xr-x 5 root root 0 May 4 1999 proc/ drwx------ 5 root root 1024 Sep 21 1997 root/ drwxr-xr-x 4 root root 2048 Sep 23 1996 sbin/ drwxrwxrwx 4 root root 1024 Apr 6 09:18 tmp/ drwxr-xr-x 18 root root 1024 Apr 25 1997 usr/ drwxr-xr-x 14 root root 1024 Apr 25 1997 var/ -rw-r--r-- 1 root root 407793 May 25 1997 vmlinuz
Betrachten wir diese Ausgabe von rechts nach links. Ganz rechts in jeder Zeile steht der Dateiname, jede Zeile ist der Eintrag für eine Datei. Links davon steht in drei Feldern Datum und Uhrzeit der letzten Modifikation der Datei. Im fünften Feld (links vom Monat) steht die Größe der Datei in Bytes (1 Byte entspricht einem Zeichen, also z.B. einem Buchstaben). Die weiteren zwei Felder links von der Dateigröße geben den Besitzer der Datei und dessen Gruppe an. Alle Dateien in diesem Verzeichnis gehören dem Benutzer "root", der Mitglied der Gruppe "root" ist. Schließlich stehen ganz links (in der ersten Spalte) die Zugriffsrechte. Das erste Zeichen dieser ersten Spalte zeigt an, ob es sich beim entsprechenden Eintrag um eine normale Datei ("-"), um ein Verzeichnis ("d"), um ein Character-Device ("c"), um ein Blockdevice ("b") oder um einen Link ("l") handelt.
| Verzeichnis | Beschreibung / Funktion |
| / | Hier sollte mit Ausnahme des Default-Kernels und der zugehörigen System-Map keine Dateien liegen |
| /bin | Systemverwaltungsprogramme, die nicht spezifisch für den Superuser sind (cp, ls oder more) |
| /boot | Lilo-Dateien, die nicht ausführbar und keine Konfigurationsdateien sind; hier liegen auch alternative Kernel |
| /dev | Gerätedateien |
| /etc | Konfigurationsdateien des Basissystems und von Lilo sowie die Benutzerdatenbank |
| /home | Heimatverzeichnisse der Benutzer |
| /lib | Shared Libraries des Basissystems |
| /lost+found | Nimmt Dateien auf, die beim Plattencheck anfallen |
| /mnt | Hier mountet man Laufwerke wie CD-ROM (/mnt/cdrom) und Diskette (/mnt/floppy) |
| /opt | Erweiterungspakete (in Unterverzeichnissen); hier sollte beispielsweise KDE oder Netscape Communicator installiert sein |
| /proc | Dateien des proc-Dateisystems - ein virtuelles Dateisystem, über das Informationen über die Hardware ermittelt werden können |
| /root | Home-Verzeichnis des Superusers (root) |
| /sbin | Die ausführbaren Dateien für Systemadministation und Startskripten |
| /tmp | Temporäre Dateien |
| /usr | Zweites Hauptverzeichnis für Prgramme (Unix System Resources) |
| /usr/X11R6 | X-Window-System |
| /usr/dict | Wörterbücher zu ispell |
| /usr/doc | Doku |
| /usr/include | Header-Dateien für den Präprozessor |
| /usr/local | Lokale Anwendungen + Dateien (analog /usr) |
| /usr/info | Textdateien des Textinfo-Dokumentationssystems |
| /usr/man | Manuals (Online-Hilfe) |
| /usr/share | Architekturunabhängige Daten in verteilten Systemen mit verschiedenen Rechnerarchitekturen (Sparc, RS 6000 ...) |
| /usr/src | Quellcode für die Programme des Standardsystems |
| /usr/src/linux | Kernel-Sourcen; meist handelt es sich hier nur um einen symbolischen Link auf ein aussagekräftigeres Verzeichnis |
| /usr/spool | Wird aus Kompatibilitätsgründen als symbolischer Link auf /var/spool beibehalten |
| /var | Verzeichnis für die variablen Daten, falls /usr über NFS readonly gemountet ist; in /var/log liegen System-Logfiles |
| Funktion | Standard UNIX | Berkely UNIX |
| Zeilenende | Return-Taste | Return-Taste |
| Lösche Zeichen | # | Backspace |
| Lösche Zeile | @ | Ctrl-U |
| Programm abbrechen | Delete | Ctrl-C |
| Dateiende Eingabeende | Ctrl-D | Ctrl-D |
| Ausgabe anhalten | Ctrl-S | Ctrl-S |
| Ausgabe fortsetzen | Ctrl-Q | Ctrl-Q |
| Bildschirm wiederherstellen | Ctrl-L | Ctrl-L |
Ctrl-S und Ctrl-Q waren früher bei langsamen, seriellen Terminals noch als Reaktionstest brauchbar. Heute sind sie nicht mehr zum Steuern der Ausgabe verwendbar, weil die Bildschirmanzeige zu schnell durchläft. Trotzdem kann Ctrl-S Ärger machen, wenn Sie versehentlich auf die Taste kommen. Dann bleibt die Ausgabe stehen und man hat das Gefühl, der Rechner reagiert nicht mehr. Also erstmal versuchsweise Ctrl-Q drücken.
pwd (Print Working Directory)
Gibt das aktuelle Verzeichnis aus - damit man weiß, wo man überhaupt
rumpfuscht.
cd (Change Directory)
Navigieren im Dateibaum - Wechsel des aktuellen Verzeichnisses. Wechsel
nur in Verzeichnisse mit Execute-Permission möglich. Es gibt zwei
Aufrufformen:
ls (List)
ls [-Parameter] [pfadname]
Auflisten von Dateien und Verzeichnissen mit der zugehörigen Information
(Eselsbrücke: "laß sehen"). Durch Parameter wird die Ausgabe
gesteuert. ls ohne Dateispezifikation listet das aktuellen Verzeichnis,
sonst muß der Pfad angegeben werden. ls / listet z. B. das
Wurzelverzeichnis auf Parameter: ls kennt sehr viele Parameter,
die wichtigsten sind:
ls -al listet z. B. alle wichtige Informationen
ls -CF liefert eine übersichtliche Kurzliste
man (Manual)
Brauchen Sie zu einem Befehl eine Erläuterung, geben Sie
'man Befehl' ein, statt 'Befehl' natürlich den Namen des zu erklärenden
Befehls. Diese Manual-Seiten sind für fast alle Kommandos vorhanden.
Je nach Implementierung ist seitenweises Blättern mit der Leertaste
möglich - oder ein Reaktionstest mit CTRL-S und CTRL-Q. Sehen Sie
sich z. B. einmal die Infos über den Befehl 'ps'
('Prozess Status') an. Der ist auch sehr nützlich. Auch die hier
vorgestellten Befehle können noch viel mehr - alles steht in dem
Manual-Seiten.
Es ist auch unmöglich, in diesem Skript bei jedem Kommando
alle Parameter aufzuzählen. Auch werden sicher nicht alle wichtigen
Kommandos besprochen. Aus diesem Grund ist für den Anfänger wie für den Profi
das man-Kommando wichtig und Voraussetzung für die Arbeit.
passwd (Password)
Interaktives Ändern des Paßworts. Zunächst muß
das bisherige Paßwort eingegeben werden.Bei der Eingabe der Paßwörter
werden diese auf dem Bildschirm nicht angezeigt. Damit Eingabefehler abgefangen
werden können, ist das neue Passwort zweimal einzugeben. Programmamblauf:
$ passwd
old passwd: Josef1
newpasswd: Maria2
retype new passwd: Maria2
who (Who)
Das Kommando gibt aus, wer alles im System aktiv ist. Es werden Login-Name,
Terminal und Datum/Uhrzeit der Anmeldung angezeigt. Zum Beispiel:
$ who hans tty11 Juli 15 09:15 karl tty12 Juli 15 09:55 kathi tty18 Juli 15 10:03
Wer nur wissen will, an welchem Terminal er sitzt, tippt: who am i Das Kommando kennt etliche Parameter, die wichtigsten sind: -p Anzeige der Prozesse, die gerade laufen -T Terminal-Status (mit "write" erreichbar?)
tty (Teletype)
gibt den Namen des aktuellen Terminals (eigentlich jenen des Device-Treibers)
aus. Direkte Ausgabe auf dem Bildschirm können auf dieses Device geleitet
werden. Sie gelangen dann auf jeden Fall aus den Bildschirm, auch wenn
die Eingabe umgeleitet wird (näheres später).
finger Info über User
Informationen über einen User erhält man mit
'finger user' - einfach mal ausprobieren. Unter der Idle-Time versteht man
übrigens die Zeit, seit der der Mensch nichts gemacht hat.
write (Write Message)
Mit diesem Kommando kann man einem anderen Benutzer, der gerade am
Rechner arbeitet, eine Nachricht auf den Bildschirm schicken (Nachrichten
an nicht eingeloggte Benutzer später). Die Nachricht erscheint sofort
auf dem Bildschirm des Partners. Als Parameter wird der Benutzername des
Partners angegeben. Anschließend kann der Text zeilenweise eingegeben
werden. Abgeschlossen wird die Eingaben mit den EOF-Zeichen CTRL-D.
Zum Beispiel:
$ write karl Lieber Karl, dieGeburtstagsfeier für den Boss fängt schon in einer halben Stunde an! Mach Dich rechtzeitig auf die Socken! Gruss, Markus <CTRL-D-Taste>
Bei Karl erscheint dann auf dem Bildschirm:
Message from markus tty16 [Tue Jul 23 14:05:00] Lieber Karl, die Geburtstagsfeier für den Boss fängt schon in einer halben Stunde an! Mach Dich rechtzeitig auf die Socken! Gruss,Markus
mesg (Message) Solche Nachrichten sind zwar recht nützlich, können aber auch stören - wenn man z. B. gerade Texte schreibt. Denn die Nachricht zerstört ja das Bild auf dem Schirm. Mit dem mesg-Kommando kann man das Terminal gegen Nachrichten von außen sperren.mesg n sperrt das Terminal mesg y gibt das Terminal frei.
Ein neuer Prozeß kann nur von einem bereits laufenden Prozeß erzeugt werden. Dadurch werden, ähnlich wie beim Dateibaum, die einzelnen Prozesse im Betriebssystemkern in einer baumartigen, hierarchischen Struktur verwaltet. Jeder Kind-Prozeß ist genau einem Eltern-Prozeß untergeordnet. Ein Eltern-Prozeß kann jedoch beliebig viele Kind-Prozesse besitzen. Die Wurzel der Prozeßstruktur wird durch den Systemstart geschaffen und als init-Prozeß (PID 1) bezeichnet.
In der Regel wartet der Eltern-Prozeß auf die Beendigung seiner Kind-Prozesse. Diese Art der Prozeßsynchronisation wird als synchrone Ausführung bezeichnet, der Kind-Prozeß wird als Vordergrundprozeß ausgeführt. Bezogen auf einen Benutzer ist die Shell (Login-Shell) der Eltern-Prozeß. Alle Kommandos, die der Benutzer startet, sind Kind-Prozesse. Während diese abgearbeitet werden ruht der Eltern-Prozeß. Als asynchroner Prozeß oder Hintergrundprozeß werden solche Prozesse bezeichnet, bei denen der Eltern-Prozeß nicht auf das Ende seines Kind-Prozesses wartet, sondern parallel (quasiparallel auf einer Ein-Prozessor-Maschine) asynchron weiterläuft. Auf der Shell-Ebene kann jeder Prozeß durch Anfügen von '&' (kaufm. UND) in der Kommandozeile als Hintergrundprozeß gestartet werden.
Über einen Scheduling-Algorithmus zur Berechnung der Priorität erhält jeder einzelne Prozeß einen bestimmten Teil der Rechenzeit zugewiesen. D.h. der Prozeß mit der zur Zeit höchsten Priorität erhalt die CPU, wird nach einen Zeitintervall suspendiert und, falls noch nicht beendet, zu einem späteren Zeitpunkt wieder reaktiviert. Die aktuelle Priorität eines Prozesses setzt sich aus dem Produkt des CPU-Faktors und der Grundpriorität zusammen.
Die Prozeßverwaltung und Prioritätssteuerung ist recht komplex. In Stichpunkten:
fork() erzeugt einen Kindprozeß, der ein vollständiges Abbild des Elternprozesses ist und der beim gleichen Stand des Befehlszählers fortgesetzt wird. Eltern- und Kindprozeß wird jedoch die Möglichkeit geboten, festzustellen, ob es sich um Eltern- oder Kindprozeß handelt: Der Kindprozeß bekommt als Rückgabewert 0, der Elternprozeß die PID des Kindprozesses. Durch bedingte Verzweigung nach dem Schema (".. if Elternprozeß then ... else ...") können beide Prozesse dann unterschiedlich weiterarbeiten.
wait() ermöglicht dem Elternprozeß das Warten auf die Beendigung des/der Kindprozess(e). Der Elternprozeß wird verdrängt und erst durch das Ende eines Kindprozesses wieder "aufgeweckt". Zur Unterscheidung mehrerer Kindprozesse liefert die Funktion wait() die PID des "gestorbenen" Kindprozesses zurück.
Gibt es keinen Kindprozeß, ist das Ergebnis -1. Beheben des Waisenkind/Zombie-Problems:
Beim Wait-Aufruf wird zuerst die Prozeßtabelle nach terminierten Kindprozessen durchsucht und diese dann gelöscht.
Beim Terminieren des Elternprozesses werden dessen Kindprozesse zu Kindprozessen des Systemprozesses Init.
Bei exec() wird der ursprüngliche Prozeß durch einen neuen Prozeß ersetzt (eine Rückkehr zum aufrufenden Prozeß ist daher logischerweise nicht möglich). exec() ist der komplizierteste Aufruf, da der komplette Prozeßadreßraum ersetzt werden muß. Dieser Aufruf ist auch als Kommando verfügbar (exec [Programmname]). Der Ablauf im Schema:
Schließlich gibt es noch eine Systemfunktion, welche die zeitweise Blockierung eines Prozesses erzwingt: Mit sleep() kann ein Prozeß für eine definierte Zeit "eingeschläfert" werden. Nach Ablauf der vorgegebenen Zeit, wird der Prozeß wieder auf "bereit" gesetzt und kann weiterlaufen. Auch sleep() ist als Kommando verfügbar (sleep [Zeit in Sekunden]).
Alle Prozesse, die auf dem Rechner laufen sind Kindprozesse von init (wobei "Kind" hier auch für alle weiteren Nachkömmlinge steht). Im Single-User-Modus werden von init nur noch einige Prozesse gestartet, im Multi-User-Modus sind wesentlich mehr Prozesse zu aktivieren (z. B. der Drucker-Spooler, die Abrechnung, etc.). Alle zu startenden Prozesse sind in der Datei /etc/inittab aufgeführt. init holt sich die Informationen über zu startende Prozesse aus der Datei /etc/inittab. Für uns ist eigentlich nur das Programm getty interessant, den dieses Programm sorgt für den Kontakt mit den Terminals. Was geschieht nun weiter?
Beim Login (und beim Wechsel des Benutzerkennzeichens während einer Terminalsitzung) wird auf diese Dateien zugegriffen - sie sind übrigens für alle Benutzer lesbar. Schreiben darf jedoch nur der Superuser und das Programm passwd. Da passwd von jedem Benutzer aufgerufen werden kann, ergibt sich hier eigentlich ein Widerspruch. Gelöst wird das Problem durch das UID-Bit von passwd: während das Programm läuft, nimmt der Prozeß die Identität seines Eigentümers an - und der darf schreiben. Anmerkung: Ab der UNIX-Version System V, Version 3 steht das Paßwort nicht mehr in /etc/passwd, sondern in einer eigenen Datei /etc/shadow. Da /etc/passwd für alle lesbar sein muß (z. B. für die Anzeige des Benutzernamens im ls-Kommando), kann man mit entsprechenden Programmen versuchen, die Paßwörter zu 'knacken'. Durch die Verlagerung der Paßwortinfo in /etc/shadow, die nur von Superuser-Prozessen gelesen werden kann, wird diese Sicherheitslücke geschlossen.
Wichtig: Das Paßwort ist in der Datei /etc/passwd verschlüsselt gespeichert. Die Verschlüsselung erfolgt beim Ändern des Passworts mit dem Programm passwd oder bei der Eingabe im Login-Programm. Verglichen werden immer nur die verschlüsselten Passwörter. Auch der Superuser kann das Paßwort nicht entschlüsseln. Wenn Sie Ihr Paßwort vergessen haben, kann er nur ihr altes Paßwort löschen, damit Sie dann ein neues eintragen können. Um das "knacken" von Login-Name und Paßwort zu erschweren, fragt das Login-Programm auch dann das Paßwort ab, wenn schon der Benutzername falsch war. Außerdem wird beim Eingeben des Passworts nichts auf dem Bildschirm angezeigt.
Login-Name:Paßwort:UID:GID:Kommentar:Home-Directory:Programm
Beispiel für einen Eintrag in /etc/passwd:
karl:,..:235:100:Karl Müller:/usr/karl:/bin/sh
Die Zeitdauer wird in Wochen gezählt; der Punkt "." bedeutet 0 Wochen, der Schrägstrich "/" 1 Woche, dann folgen Ziffern und Buchstaben:
Sonderfälle:
Gruppenname:Paßwort:GID:Benutzernamen
Beispiel für einen Eintrag in /etc/group:
dozenten::200:kristl,plate,rother,ries,thomas
Name:Paßwort:letzte Änderung:Min:Max:Vorwarnzeit:Inaktiv:Verfall:Kennzeichen
/etc/default/passwd:
Standardwerte für das Paßwort
und seine Gültigkeitsdauer. Einige wichtige Werte sind:
Um alle Dateien (nicht Directories) eines Benutzers zu löschen, kann das Kommando find (siehe später) verwendet werden (für UID wird die User-ID des Benutzers eingesetzt):
find / -user UID -type f -exec rm -f {} ";"
Probleme können durch Dateien des zu löschenden Benutzers verursacht werden, auf die andere Benutzer ein Link gesetzt haben. Man kann diese Dateien z. B. den betroffenen Benutzern zuordnen.
| 0 | Power-Down: Ausschalten des Rechners |
| 1 | Administrativer Level: z. B. Einrichten neu eingebauter Platten oder andere Hardware-Initialisierungen. Oft auch "s" oder "S" (Singleuser = Einzelbenutzer-Modus). |
| 2 | Multiuser-Modus ohne Netzwerkanbindung |
| 3 | 3 Multiuser-Modus mit Netzwerkanbindung (Normal-Level) |
| 4 | Frei für benutzerdefinierten Modus |
| 5 | Firmware-Modus: z. B. Diagnose und Wartung; oft nur mit spezieller Floppy zu starten |
| 6 | Shutdown und Reboot: Wechsel zu Level 0 und dann sofortiges Hochlaufen |
Die Zuordnung der Level kann auch von der oben angeführten abweichen. Der Wechsel des Levels wird durch spezielle Kommandos erreicht, z. B. shutdown, telinit, (re)boot oder halt. So ist beispielsweise auch ein Bootstrap von einem bestimmten Datenträger (Floppy, CD-ROM, ...) möglich.
Beispiel: Reboot des Systems nach 2 Minuten (Solaris): shutdown -g120 -i6 -y Shutdown sendet eine Nachricht an alle eingeloggten Benutzer, bevor der eigentliche Prozess beginnt. Egal, ob der Reboot-Vorgang durch shutdown oder durch Einschalten des Rechners ausgelöst wurde, sind die Systemaktivitäten im Prinzip immer gleich:
Diese doch relativ komplexen Aktionen werden wieder über spezielle Shell-Scripts gesteuert. Bei BSD-Unix war der Aufbau dieser Scripts relativ einfach. Die Datei /etc/rc enthält alle beim Systemstart auszuführenden Kommandos. Innerhalb von rc werden eventuell weitere rc-Dateien aufgerufen, z. B.:
| /etc/rc.local | Start lokaler Software |
| /etc/rc.net | Start der Netzwerksoftware |
| /etc/rc.single | Start im Single-User-Modus |
Später wurde das System dahingehend erweitert, daß es für jeden Runlevel eine eigene rc-Datei gab (rc0, rc1, rc2, usw.). Ab System V ist das System der rc-Dateien vereinheitlicht worden. Für jeden Runlevel exisitiert eine rc-Datei (rc0, rc1, rc2, etc.) und ein Verzeichnis unter /etc, wobei der Name der Verzeichnisse einheitlich /etc/rcü.d ist (ü steht für den Runlevel, es gibt also rc0.d, rcs.d, rc2.d, usw.). Im Verzeichnis /etc/init.d (manchmal auch /sbin/init.d) sind alle Programme (oder Shell-Scripts) gespeichert, die beim System-Boot aufgerufen werden könnten. In den Verzeichnissen rc.d sind nun nur noch Links auf diese Programme enthalten. Alle Links folgen ebenfalls einer festen Namenskonvention:
Die so entstandenen rc-Scripts werden in lexikalischer Reihenfolge aufgerufen und zwar zuerst die K-Dateien, dann die S-Dateien. Die Zahl im Namen legt also die Reihenfolge innerhalb der K- oder S-Gruppe fest. Die K-Dateien dienen zum Löschen (Kill) von Prozessen, die S-Dateien zum Starten von Prozessen. Angenommen, es existieren folgende Dateien in /etc/rc.d:
Dann ist die Aufruf-Reihenfolge:
K30tcp K40nfs S20sysetup S30tcp S40nfs S75cron S85lp
Dabei sind K-und S-Dateien mit ansonsten gleichem Namen lediglich Hinweise darauf, dasselbe Programm aufzurufen. So wird z. B. bei den Dateien K30tcp und S30tcp das Programm oder Script /etc/init.d/tcp einmal mit dem Parameter "stop" und einmal mit dem Parameter "start" aufgerufen. Man kann also durch Anlegen von Links das Hochfahren des Systems sehr gezielt steuern. Das entsprechende rc-Script wird dann auch sehr einfach, es läßt sich folgendermaßen skizzieren:
#!/bin/sh # Wenn Directory /etc/rc2.d vorhanden ist if [ -d /etc/rc2.d] ; then # K-Files bearbeiten for f in /etc/rc2.d/K* ; do if [ -s $f ]; then /bin/sh $f stop fi done # S-Files bearbeiten for f in /etc/rc2.d/S*; do if [ -s $f ] ; then /bin/sh $f start fi done fi
Ein von der rc-Datei aufgerufenens Script in /etc/init.d könnte dann z. B. so aussehen:
#!/bin/sh
case $1 in
'start')
# aufgerufen als "Kxxcron"
# Lockfilelöschen
rm -f /var/spool/cron/FIFO
if [ -x /etc/cron ] ; then
/etc/cron
fi
;;
'stop')
# aufgerufen als "Sxxcron"
pid=`/bin/ps -e | grep 'cron$' | sed -e 's/^ *//' -e 's/ .*//'`
if [ "$pid" != "" ] ; then
/bin/kill -9 $pid
fi
;;
esac
Da das Protokoll allerdings recht aufwendig war - es teilt sich der Klarheit wegen in mehrere streng getrennte Schichten - waren die anfänglichen Implementierungen relativ langsam. Wesentlich langsamer jedenfalls als solche Windowsysteme, die direkt auf das Bitmap-Display zugreifen. Es folgten dann immer mehr Programme, die auf dem X Window System aufbauen.
Das X Window System ist jedoch keine einheitliche Benutzeroberfläche, die ein bestimmtes "Look-and-Feel" bietet. X könnte aussehen wie der Macintosh Finder oder wie Microsoft Windows. Dieses deshalb, weil das X-Protokoll sehr einfach ist. Man kann lediglich grafische Elemente (Linien, Kreise, etc.) und Buchstaben auf dem Bildschirm anzeigen. Das Protokoll enthält keine komplexeren Grafikelemente wie Buttons oder Menus. Deshalb gibt es auch keine Aussagen über Aussehen von Anwendungsprogrammen (Style Guide), so daß sich mehrere Standards gebildet haben.
Möchte man zum Beispiel einen Knopf (Button) mit einer Aufschrift, so muß dieser aus Linien und Text selbst zusammengesetzt werden. Dies kann dem Programmierer aber auch durch ein Toolkit abgenommen werden. Diese Toolkits bestimmen dann hauptsächlich das Look-and-Feel.
Das Pointing-Device muß nur zum Zeigen auf Punkte fähig sein. Es könnte zum Beispiel auch ein Touch-Screen sein. Oder eine Maus mit nur einer Taste. Soll ein Programm konform zur X-Spezifikation sein, müssen alle Funktionen mit nur einer Maustaste ausführbar sein. Dies kann man z. B. erreichen, indem man beim Drücken der Maustaste auch noch gleichzeitig gedrückte Tasten (Control, Meta, etc.) abfragt.
Softwareseitig gibt es folgende Prozesse:
| X Server |
Der X-Server ist das Programm, das alle Bildschirmausgaben übernimmt und
alle Eingaben von der Tastatur und der Maus verarbeitet. Daher ist ein Teil des
X-Servers sehr an die Hardware des Rechners gebunden (Farb- oder
Schwarzweiß-Bildschirm, Art der Tastatur, Anzahl der Maustasten,
Bildschirmgröße ...). Ein Programm, das etwas auf dem Bildschirm
ausgeben will, schickt einen diesbezüglichen Auftrag an den X-Server, der
daraufhin eine Linie zeichnet, einen Text ausgibt oder tut, was immer das
Programm von ihm verlangt. In der anderen Richtung gibt der X-Server Meldungen
an die X-Clients, wann immer der Benutzer eine Eingabe getätigt hat, sei es
das Bewegen der Maus, das Drücken einer Maustaste oder eine Eingabe
über die Tastatur. Die Programme können dann entscheiden, was sie mit
dieser Eingabe anfangen und wie (oder ob überhaupt) sie darauf reagieren.
Vorteil dieser Konfiguration ist, daß nur der X-Server über die
Möglichkeiten der vorhandenen Hardware informiert sein muß. Die Clients
können diese Information vom Server erfragen, wenn sie sie brauchen,
müssen sich ansonsten aber nicht darum kümmern.
Zur Verdeutlichung noch ein Hinweis: bei den meisten anderen Client-Server Systemen (beispielsweise Datenbanksystem, Mailsystem usw.) befindet sich der Client näher am Benutzer als der Server. Bei X ist das naturgemäß umgekehrt, da der Server Tastatur und Bildschirm verwaltet und den Clients zur Verfügung stellt.
| ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| X Clients | Jedes Programm, das auf einem X-Bildschirm ein Fenster darstellen will, ist ein X-Client. Der X-Client bittet den Server, gewisse Aufgaben (eben das Zeichnen des Fensters) für ihn zu übernehmen. Sie müssen dazu Aufträge im X Protokoll an den Server schicken. | ||||||||||
| Window-Manager |
Ein Client hat den anderen gegenüber einen gewissen Sonderstatus: der
Window-Manager, hier heißt er ctwm. Er stellt dem Benutzer Mittel
zur Verfügung, mit deren Hilfe dieser das Aussehen seiner
Benutzeroberfläche bestimmen kann. Insbesondere kann der Window-Manager die
Größe und die Position der Fenster anderer Clients beeinflussen. Die
Clients können dem Window-Manager Hinweise geben, wo und in welcher
Größe sie ihre Fenster plaziert haben wollen. Der Window-Manager
muß diese Hinweise zwar nicht berücksichtigen, die meisten gängigen
Systeme tun dies aber. Durch die Funktion des Window-Managers ergibt sich,
daß es zumindest problematisch ist, zwei Window-Manager für einen
Bildschirm zu starten. Daher prüfen Window-Manager beim Start in der Regel,
ob bereits ein anderer Window-Manager für den Bildschirm existiert und
brechen in diesem Fall die Arbeit ab.
Die Rahmen und Titelbalken, die die einzelnen Fenster verzieren, sind nicht Teil des jeweiligen Clients, sondern werden vom Windowmanager um die Fenster herumgezeichnet, damit durch ihre Betätigung Funktionen des Windowmanagers ausgelöst werden können. Der Windowmanager bestimmt somit auch "look-and-feel" der Benutzeroberfläche. Beachten Sie aber, daß der Window-Manager aber auch nur ein Clientprozeß ist. Es gibt alle möglichen Window-Manager:
|
X ist netzwerkfähig. Clients können ihre Grafikausgabe auch auf Server machen, die auf anderen Rechnern im Netz laufen. Als Netzwerkprotokolle können dabei verschiedene Protokolle eingesetzt werden. Bei Unix ist dies meist TCP/IP.
Auf dem Zielrechner muß dem Server mitgeteilt werden, daß er Requests vom Senderechner zulassen darf. Das geschieht mit dem Kommando:
xhost +senderechnerAuf dem Senderechner muß man dem Client mitteilen, daß die Ausgabe nicht auf dem eigenen Display erscheinen soll, sondern beim Zielrechner. Dazu setzt man entweder die Environment-Variable
export DISPLAY=zielrechner:0oder man schreibt beim Aufruf des Programms
clientprogramm -display zielrechner:0Die Zahl hinter dem Rechnernamen gibt die Nummer des Displays an. Sie kann auch eine Nachkommastelle haben, z.B. 0.1. Normalerweise haben aber die Rechner nur ein Display mit der Nummer 0.
Der Mechanismus funktioniert folgendermaßen: von Systemprozessen wird eine Prozedur aufgerufen, welche die Session steuert. Wenn sich die Prozedur beendet, übernehmen wieder die Systemprozesse die Steuerung.
process xdm is
while (true)
do
xlogin;
if (Benutzer hat eigene Session-Prozedur)
then fuehre Benutzer-Session-Prozedur aus
else if (Benutzer hat zusätzliche Session-Prozedur)
then fuehre zusätzliche Session-Prozedur im Hintergrund aus
fi;
starte xterm im Hintergrund;
starte xclock im Hintergrund;
starte twm;
fi
done
endprocess
Bei xdm heißt die Benutzer-Session-Prozedur .xsession und die zusätzliche
Session-Prozedur .xsession+. Man sollte darauf achten, daß diese Dateien
ausführbar sind. Außerdem wird die Session beendet, wenn sich die
Prozedur beendet. In der Prozedur sollten also alle Kommandos im Hintergrund
gestartet werden, außer dem letzten, das während der gesamten Session
laufen muß. Dies ist meist der Window-Manager. Wird dieser dann mit Exit
beendet, wird auch die Session mit allen anderen Clients beendet.
Resourcen sind hierarchisch aufgebaut. Jedes Programm greift auf eine Klasse von Resourcen zu (xterm zum Beispiel auf Xterm). Darunter können sich Komponenten des Programms befinden und am Ende der Hierarchie stehen Eigenschaften. Teile der Hierarchie können auch durch Wildcards ('*') ersetzt werden. Beispiel:
xterm*font: 9x15
setzt in allen Komponenten von xterm den gewünschten Font auf 9x15.
Resourcen werden vom System vorbesetzt. Man kann sie durch eigene ersetzen
(.xresources) oder erweitern (.xresources+).
Ein anderes Problem liegt am Konzept des TCP/IP-Protokolls. Da nicht alle Rechnertypen, die am Internet hängen, das Konzept einer Benutzer-ID haben, ist diese auch bei TCP/IP nicht vorgesehen. Auf den X-Server kann also nicht nur der augenblickliche Benutzer der Konsole zugreifen, sondern alle Benutzer des Rechners. Und das in beliebiger Form. Ein anderer Benutzer kann zum Beispiel den gesamten Bildschirminhalt überschreiben.
Bei jedem Anmelden an einem Rechner generiert das Programm xdm, das die Anmeldemaske zur Verfügung stellt, einen Schlüssel und legt ihn in der Datei .Xauthority im HOME-Verzeichnis des Benutzers ab. Jedes X-Programm, das der Benutzer dann startet, sucht in dieser Datei nach dem Schlüssel und gibt ihn dem Server beim Aufbau der Verbindung an. Nur wenn dieser Schlüssel mit dem übereinstimmt, der beim Login generiert wurde, wird die Verbindung tatsächlich aufgebaut, ansonsten wird der Aufbauversuch vom Server zurückgewiesen. Auf diese Art wird verhindert, daß jeder Benutzer seine Fenster auf den Bildschirm eines anderen Benutzers legen und diesen dadurch bei seiner Arbeit behindern kann. Voraussetzung für die Sicherheit des Systems ist natürlich, daß die Rechte für die Datei .Xauthority richtig gesetzt sind. Nur der Eigentümer der Datei darf dafür das Lese- und Schreibrecht haben, alle anderen Benutzer nicht einmal das Leserecht, da sie sonst den Schlüssel aus der Datei herauslesen könnten.
X ermöglicht unter anderem jedem Programm, das eine Verbindung zum X-Server aufbauen kann, das Mitlesen von Tastatureingaben, die auf dem Rechner vorgenommen werden. Darunter können natürlich auch Paßworteingaben sein (zum Beispiel bei einem rlogin). Daher darf der Zugriff auf den Server auf keinen Fall unkontrolliert freigegeben werden.
xterm [Optionen]
oder
xterm [Optionen] & (als Hintergrundprozeß)
Optionen:
breite x höhe +xkoord +ykoord
'breite' und 'höhe' geben die Fenstergröße (in Buchstaben) an, 'xkoord' und 'ykoord' die Position (in Pixeln). Ein xterm-Fenster hat gemäß Voreinstellung 24 Zeilen mit 80 Zeichen Breite. Je nach verwendeten Zeichen + oder - ergibt sich die Ecke des Bildschirms und des Fensters, auf die sich 'xkoord' und 'ykoord' jeweils beziehen. Es gibt vier Möglichkeiten:
xterm -geometry 80x25+200+400
xterm -geometry 80x25+130+360
erzeugt ein Terminalfenster mit 80 Spalten und 25 Zeilen, dessen obere linke Ecke an der X-Koordinate 130 und der Y-Koordinate 360 liegt.
Rechnername [Benutzer]
Was kann man nun überhaupt mit Ressourcen festlegen? Mit Programmname.geometry wird festgelegt, an welcher Stelle ein Fenster des angegebenen Programms bei dessen Start auf dem Bildschirm erscheinen soll. Die Einträge mit den Endungen background und foreground legen für die entsprechenden Programme Vordergrund- und Hintergrundfarbe fest. iconic bestimmt, ob ein bestimmtes Programm als Icon (true) oder als Fenster (false) gestartet wird.
 Zum Inhaltsverzeichnis |
 Zum nächsten Abschnitt |