1. Überblick über UNIX

Unix is user friendly, it just happens to be very particular about who it makes friends with.

1.1 Was ist UNIX

Das Betriebssystem UNIX blickt auf eine lange Vergangenheit zurück. Ursprünglich wurde es für PDP-Rechner der Firma DEC (Digital Equipment Corporation) entwickelt und sollte hauptsächlich die Bedürfnisse von professionellen Softwareentwicklern befriedigen. Heute ist UNIX auf Workstations mit 64-Bit-Prozessoren zugeschnitten. Zu den Neuerungen gehören die Einführung von Threads, mit denen ein Programm mehrere Funktionen gleichzeitig ausführen kann. Ebenfalls neu sind Echtzeitfunktionen mit denen Programmlaufzeiten vorhersagbar sind. Insbesondere für Datenbanken ist die Möglichkeit, sehr große Dateien verarbeiten zu können, von nicht unerheblicher Bedeutung. Ein Schritt in Richtung einer völligen Unabhängigkeit von der Hardware-Architektur ist die Normierung ganzer Zahlen mit einer Länge von mehr als 64-Bit. Ebenfalls neu ist die Einbeziehung der Benutzeroberfläche in die Spezifikation. Aber schon seit den Anfängen gilt:

  • UNIX ist ein portables, einfach aufgebautes Betriebssystem
    • Multitasking-BS (Multiprocessing-BS)
    • Multiuser-BS (Mehrbenutzer-BS)
    • dialogorientiert
  • UNIX ist ein Werkzeugkasten
    • viele hundert Dienstprogramme (dadurch wird es so kompliziert)
    • flexibel: kleine Tools sind schnell erstellt: "small is beautiful"
  • UNIX ist geeignet für
    • Mikrocomputer der Oberklasse
    • Mini-Computer
    • Großrechner
  • UNIX ist schrecklich
    • Befehlsname sind kryptisch (ls, pwd, cat, awk, grep, ...)
    • Motto 1: "Keine Nachricht ist eine gute Nachricht!"
    • Motto 2: "Wer will schon schlechte Nachrichten?"
  • Das Betriebssystem UNIX ist aus diesem Grunde ein System von Programmierern für Programmierer, die wissen was sie tun.

1.2 Historie

UNIX ist aus der Notwendigkeit entstanden, für die Programmerstellung ein Rechnerbetriebssystem zu entwickeln. Die Portierbarkeit von UNIX beruht auf der Entwicklung der Programmiersprache C (als Nachfolger von BCPL und B), die es möglich machte, ca. 90% des Betriebssystems in einer höheren Programmiersprache zu entwickeln.

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.

1.3 Die Struktur von UNIX

Zur Verdeutlichung der Zusammenarbeit verschiedener Komponenten in einem Rechnersystem wird allgemein ein Schalen- oder Schichtenmodell verwendet. Dabei werden die einzelne Komponenten in Form von Schalen oder Schichten dargestellt. Die Grenze zwischen den einzelnen Schalen werden dabei als Schnittstellen bezeichnet. In der folgenden Abbildung wird das UNIX Schalenmodell gezeigt. Die Funktionen des Betriebssystemkerns sind dabei speziell hervorgehoben.

Die Dialogschnittstelle zur Kommunikation mit dem Benutzer (zeichenorientiert) wird dabei als Shell bezeichnen. Diese Shells unter UNIX haben dabei zwei Funktionen, sie werden

  • als Kommandointerpreter und
  • als Programmiersprache
verwendet. Die zweite Funktion ist unter UNIX deshalb so bedeutend, da die gesamte Verwaltung (Administration) des Betriebssystems mit Skripten in dieser "Shell-Programmiersprache" erfolgt. Diese Möglichkeit wird in den Kapiteln 2 und 9 behandelt. Es gilt also:

Kommandointerpreter = Shell:

  • sh: Bourne Shell an die Programmiersprache ALGOL 68 angelehnt
  • csh: C-Shell an die Programmiersprache C angelehnt
  • ksh: Korn-Shell vereinigt Bourne- und C-Shell
  • bash: Bourne-Again-Shell (Erweiterung der Bourne Shell)
  • ...

1.4 Der Kernel

1.4.1 Aufgaben

  • Prozeß-Scheduling
  • Prozeß-Umschaltung
  • Prozeß-Kommunikation
  • Dateisystem verwalten
  • Ein-/Ausgabesteuerung
  • Gerätesteuerung (device driver)
  • Zugangskontrolle und Abrechnung
  • alle Systemdienste für Programmier-Schnittstellen
  • der Kernel ist relativ klein (ladbare Treiber)
  • alle Interrupts und I/O-Operationen werden über den Kernel abgewickelt

1.4.2 Erste Schritte

Unix ist ein Multiuser- und Multitasking-System. Das bedeutet, daß in einem bestimmten Augenblick sowohl mehrere Benutzer auf einer Unix-Maschine gleichzeitig arbeiten können, als auch, daß jeder einzelne dieser Benutzer mehrere Programme aufrufen kann, die alle zur gleichen Zeit ausgeführt werden.

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:

  • Mindestlänge 6 Zeichen
  • Je nach BS-Version muß mindestens eine Zahl und/oder ein Sonderzeichen darin enthalten sein

User und Superuser

UNIX kennt zwei Benutzerklassen. Die normalen Benutzer sind voneinander abgeschottet (siehe Kap. 1), jeder besitzt seinen eigenen Arbeitsbereich. Der Superuser, normalerweise der Systemadministrator, kann und darf alles. Er kann auf jede Datei zugreifen und Benuter eintragen oder löschen. Er kann auch Systemdienste aufrufen, die normalen Benutzern verwehrt sind. Normalerweise hat der Superuser den login-Namen "root". Der login-Name spielt jedoch eine untergeordnete Rolle, der Superuser ist vielmehr derjenige Benutzer, der die Usernummer (User Id, UID) 0 hat (Genaueres später).

Beenden der Arbeit am Computer

Zum Beenden der Arbeit am Rechner muß sich der Benutzer abmelden (logoff). Bei UNIX geschieht dies (je nach System) durch den Befehl exit oder die Tastenkombination Control-D.

Start und Stop des Systems

Bei UNIX-Rechnern kann der Rechner nicht einfach ein- und ausgeschaltet werden, denn speziell beim Ausschalten müssen alle Benutzerprozesse zuvor abgeschlossen und alle Dateien ordnungsgemäß geschlossen sein. In der Regel laufen UNIX-Systeme auch Tag und Nacht durch.

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.

Kommandosyntax (Befehlsaufbau)

Alle Befehle (= Dienstprogramme) von UNIX haben einen einheitlichen Aufbau; die Eingabe wird durch Drücken der RETURN-Taste abgeschlossen:

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.

Grundlagen des X-Window-Systems

Puristen arbeiten direkt auf der Kommandozeile und auch bei Telnet-Logins wird Kommandozeilenorientiert gewerkelt. Am besten startet man aber gleich nach dem Einloggen eine grafische Benutzeroberfläche (vergleichbar etwa dem Windows-System von Microsoft). Das erreicht man durch Eingabe des Befehls startx oder, falls man an einem X-Terminal sitzt, durch direktes Einloggen am Grafikbildschirm. Es dauert jetzt eine Weile (eine Sanduhr ist solange sichtbar) bis das X-Window-System (oder "X"), wie diese Oberfläche heißt, hochgefahren ist. Sobald das Starten von X beendet ist, nimmt der Mauszeiger die übliche Form eines Pfeils an und man kann mit der Arbeit beginnen.

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.

1.5 Das Dateisystem

1.5.1 Struktur und Zugriffsrechte

Das Dateisystem ist hierarchisch strukturiert in Form eines (umgedrehten) Baumes.

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):

  • Normale Dateien (normal files)
    • Dateien im üblichen Sinn: Text- oder Binärdateien
    • Das System unterstützt keine Dateistruktur (keine Datei-Header)
    • Dateien sind Bytefolgen (Strukturierung nur durch das Programm)
    • Zugriffsarten:
      • sequentiell
      • random access (Bytepositionierung)
  • Verzeichnisse (directories)
    • Strukturierung des Dateisystems
    • Zugriff auf normale Dateien auch über mehrere Namen
    • Verzeichnisse werden auf der Platte wie Dateien gespeichert
  • Spezialdateien (special files)
    • E/A-Geräte werden als Spezialdatei eingetragen
    • Zugriff auf Gerät <--> Zugriff auf eine Datei
    • gleicher Schutzmechanismus wie für normale Dateien
    • es gibt blockorientierte und zeichenorientierte Geräte
      • Platte /dev/hda1
      • Drucker /dev/lp
      • Speicher /dev/mem
      • Terminal /dev/tty

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:

Dateinamen
Dateinamen können bei Unix aus Groß und Kleinbuchstaben bestehen, wobei die unterschiedliche Schreibweise auch unterschiedliche Dateinamen bezeichnet. Die Datei 'test' ist also eine andere als 'Test' oder gar 'TEST'.
Dateilisten
Wo Dateieingaben erwartet werden, können in der Regel beliebig viele Dateinamen stehen.
Sonderzeichen
Dateinamen können ausser dem '/' so ziemlich alle Zeichen enthalten. Auch Leerzeichen oder Steuerzeichen.

Pfadnamen

Dateien werden über ihren Pfad spezifiziert: Angabe von Verzeichnissen und zum Schluß des Namens, getrennt durch Schrägstrich.
  • vollständiger Pfadname, beginnend bei root (absoluter Pfad) Angabe beginnt mit dem Schrägstrich. Zum Beispiel:

    /usr/projekt1/meier/test/steuerung

  • relativer Pfadname, beginnend beim aktuellen Verzeichnis (kurzer Pfad), zum Beispiel:

    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.

Schutzmechanismen

  • Jeder UNIX-Benutzer hat eine Benutzerkennung (user id, kurz: uid) mit der er sich gegenüber dem BS identifizieren kann.
  • Jeder UNIX-Benutzer gehört einer Gruppe an und besitzt damit eine Gruppen-ID, kurz:gid)
  • Jede Datei hat einen Eigentümer und eine Gruppe, die bei der Erzeugung der Datei eingetragen werden
  • Jeder Benutzer kann seine Dateien explizit einem anderen Benutzer (bzw. einer anderen Gruppe) "schenken".
  • Jede Datei besitzt 12 voneinander unabhängige Schutzbits

Bedeutung der drei Schutzbits SUID, SGID und STICKY

Wenn das SUID-Bit (Set User ID) gesetzt ist, behält das Programm für die Dauer der Ausführung die Rechte des Programmeigentümers und nicht jene dessen, der die Programme aufruft. Setzen durch das Kommando: "chmod u+s datei". Anzeige: "s" statt "x" bei den User-Rechten. Dazu ein Beispiel:

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:

  • die Datei gehört dem Benutzer, der sie löschen will
  • das Verzeichnis, in dem die Datei liegt, gehört dem Benutzer
  • der Benutzer hat Schreibrecht für die Datei
  • der Superuser will die Datei löschen
Setzen durch das Kommando : "chmod +t datei". Anzeige: "t" statt "x" bei den "Others"-Rechten.

Historisches: Das System der Zugriffsrechte, insbesondere SUID, SGID und STICKY, wurden von den Entwicklern patentiert. Interessant an der Patentschrift Bild der ersten Seite) war, das alles als Digitalschaltung dargestellt wurde, denn Software war damals noch nicht patentierbar. Das Patent wurde ein Jahr nach Erteilung von den Entwicklern freigegeben.

Die Implementierung des Dateisystems

Ein physisches Dateisystem ist eine dateiorientierte Struktur auf einem logischen Datenträger (Partition, Slice). UNIX bietet die Möglichkeit, mehrere dieser logischen Datenträger auf einem physischen Datenträger (Festplattenlaufwerk) zu verwalten. Desweiteren können neben den permanent vorhandenen physischen Dateisystemen (Dateisysteme auf dem Systemlaufwerk) auch weitere Dateisysteme auf montierbaren Datenträgern (Festplattenlaufwerke anderer Rechnersysteme, Wechselplatten, Disketten, usw. ) in den Dateibaum eingehängt bzw. entfernt werden.

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:

  • Boot-Block:
    Er enthielt im root-Dateisystem ein Urlader-Programm, welches das eigentliche UNIX-System (Betriebssystemkern) in den Arbeitsspeicher lädt. Dieser Bereich ist bei heutigen Systemen leer.
  • Super-Block:
    Er enthält alle relevanten Verwaltungsinformationen zu einem physischen Dateisystem:
    • Name und Größe des physischen Dateisystems
    • Größe der nachfolgenden Bereiche des physischen Dateisystems (Inodeliste, Nutzdatenbereich)
    • Verweise auf die Liste der freien Datenblöcke und die Liste der freien Inodes
    • Datum der letzten Sicherung und Modifikation
    • und weitere Angaben
  • Inodeliste:
    Sie stellt ein Inhaltsverzeichnis aller in dem Dateisystem existierenden Dateien dar. Sie besteht aus einer Folge von Inodes (Dateiköpfen), die die Verwaltungsdaten zu jeder Datei enthalten.
  • Nutzdatenbereich: Hier befinden sich die freien Blöcke, Datenblöcke (Inhalte von Dateien und Verzeichnissen) und Referenzblöcke, die zur Adressierung der Datenblöcke eingesetzt werden.

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.

Inodes (I-Knoten)

Da alle Inodes die identische Länge von 128 Byte haben, erübrigt sich die Abspeicherung der Knotennummer innerhalb des Inodes. Ein Inode enthält die relevanten Verwaltungsattribute einer Datei:
  • Dateityp und Zugriffsrechte
  • Eigentümer, Gruppe
  • Link-Zähler (siehe später)
  • Zeitstempel
    • Datum der letzten Änderung am i-Node
    • Datum der letzten Modifikation
    • Datum des letzten Zugriffs
  • Dateigröße in Byte
  • 10 Verweise auf Plattenblöcke
  • Einfach indirekter Verweis
  • Zweifach indirekter Verweis
  • Dreifach indirekter Verweis

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).

Links

Dies sind Verweise auf Dateien, d. h. über ein Link kann eine Datei unter einem zweiten Namen angesprochen werden. Eine Datei mit mehreren Links hat also mehrere Namen, ist jedoch nur einmal vorhanden. Beim Löschen eines Links - das für den Benutzer wie eine "normale" Datei wirkt - wird nur der Link und nicht die Datei gelöscht. erst beim Löschen des letzten Links verschwindet auch die Datei. Links sind nicht an den Eigentümer der Datei gebunden, d. h. Benutzer A kann ein Link auf die Datei von Benutzer B haben. Die Dateizugriffsrechte bleiben davon aber unberührt. Problem: Benutzer A löscht eine Datei, auf die Benutzer B ein Link hat. Dann bleibt die Datei zwar wegen des zweiten Links erhalten, wenn nun aber Benutzer A gelöscht wird, dann gibt es eine Datei ohne Eigentümer.

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.

Der Superblock

Der Superblock bildet die Verwaltungseinheit für eine Platte oder Plattenpartition (= Dateisystem). Er enthält folgende Felder:
  • Größe des Dateisystems
  • Anzahl und Liste der freien Blöcke
  • Index auf den nächsten freien Block der Liste
  • Größe der Inode-Liste - Anzahl und Liste der freien Inodes
  • Index auf den nächsten freien Inode der Liste
  • ....

Geräte

Alle Peripheriegeräte des UNIX-Rechners (Platte, Floppy-Disk, Magnetband, Terminals, Drucker, usw.) werden über das Dateisystem, also prinzipiell wie Dateien angesprochen. Dazu sind (normalerweise im Verzeichnis /dev) spezielle Programme, sogenannte Geräte-Treiber (device drivers), vorhanden, die über spezielle Dateien (special files) angesprochen werden können. Diese Gerätedateien sorgen für den Anschluß der Geräte an das UNIX-Dateisystem. Für die Namen der Dateien sind von AT&T Namenskonventionen vereinbahrt worden, an die sich jedoch nicht alle Systeme halten.

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.

  • major device number:Angabe des Gerätetyps (Platte,Terminal, Drucker, etc.)
  • minor device number: Angabe über die E/A-Schnittstelle oder nähere Umstände der Ansteuerung (z.B. Band zurückspulen/nicht zurückspulen)
Ein Gerät kann durchaus über verschiedene Treiber angesprochen werden. Normalerweise werden die Geräte vom Benutzer nicht direkt, sondern über Dienstprogramme angesprochen. Wenn jemand z. B. den Drucker direkt anspricht, während ein anderer Benutzer über den Spooler ausdruckt, gibt es "Datenmüll" auf dem Papier. Zwei interessante Geräte können jedoch alle Benutzer ansprechen:
  • /dev/null
    Daten, die an dieses Gerät geschickt werden, landen in einem "schwarzen Loch" - ideal für Ausgaben eines Programms. Wenn von diesem Gerät gelesen wird, liefert es immer "End Of File".
  • /dev/zero ist das zweite "Spezialgerät". Beim Lesen von diesem Gerät werden beliebig viele Nullbytes geliefert. Man verwendet es z. B. zum Füllen von Dateien oder wenn man eine "Dummy-Engabe" benötigt.

Es gibt bei UNIX prinzipiell zwei Typen von Treibern:

  • Zeichentreiber Für zeichenorientierte Geräte (Terminal, Drucker, etc.). Eingehende Daten werden in der Regel gepuffert und dann vom Programm aus dem Puffer gelesen, beim Schreiben erfolgt analog die Pufferung in Ausgangsrichtung.
  • Blocktreiber für blockorientierte Geräte (z. B. Platte). Hier ist meist noch ein Software-Cache (Schreib-Lesepuffer mit entsprechenden Zugriffsroutinen) zur Beschleunigung der E/A-Operationen implementiert. Zur Einrichtung von Treibern und Zuweisung der "device numbers" existiert ein passendes Kommando (mknode), das nur vom Superuser aufgerufen werden kann. Die Gerätedateien enthalten selbst keine Treiber, sondern legen nur fest, welcher Treiber im Kernel über die Gerätedatei angesprochen werden soll.

1.5.2 UNIX-Dateistruktur

So oder so ähnlich stellt sich die Dateistruktur von Unix dar:

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.

Verzeichnisstruktur

Verzeichnis Beschreibung / Funktion
/ Hier sollte mit Ausnahme des Default-Kernels und der zugeh?en System-Map keine Dateien liegen
/bin Systemverwaltungsprogramme, die nicht spezifisch f?en Superuser sind (cp, ls oder more)
/boot Lilo-Dateien, die nicht ausf?ar und keine Konfigurationsdateien sind; hier liegen auch alternative Kernel
/dev Ger?dateien
/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, ? das Informationen ? die Hardware ermittelt werden k?n
/root Home-Verzeichnis des Superusers (root)
/sbin Die ausf?aren Dateien f?ystemadministation und Startskripten
/tmp Tempor? Dateien
/usr Zweites Hauptverzeichnis f?rgramme (Unix System Resources)
/usr/X11R6 X-Window-System
/usr/dict W?rb?r zu ispell
/usr/doc Doku
/usr/include Header-Dateien f?en Pr?ozessor
/usr/local Lokale Anwendungen + Dateien (analog /usr)
/usr/info Textdateien des Textinfo-Dokumentationssystems
/usr/man Manuals (Online-Hilfe)
/usr/share Architekturunabh?ige Daten in verteilten Systemen mit verschiedenen Rechnerarchitekturen (Sparc, RS 6000 ...)
/usr/src Quellcode f?ie Programme des Standardsystems
/usr/src/linux Kernel-Sourcen; meist handelt es sich hier nur um einen symbolischen Link auf ein aussagekr?igeres Verzeichnis
/usr/spool Wird aus Kompatibilit?gr?n als symbolischer Link auf /var/spool beibehalten
/var Verzeichnis f?ie variablen Daten, falls /usr ? NFS readonly gemountet ist; in /var/log liegen System-Logfiles

1.5.3 Sonderzeichen der Tastatur

Da die ersten UNIX-Terminals Fernschreiber (Teletypes) waren, gab es keine Möglichkeit - wie am Bildschirm - einzelne Zeichen oder die ganze Eingabezeile mit dem Cursor zu löschen. Daher gibt es immer noch druckbare Löschzeichen. Außerdem existieren einige andere Spezialzeichen:

FunktionStandard
UNIX
Berkely
UNIX
ZeilenendeReturn-TasteReturn-Taste
Lösche Zeichen#Backspace
Lösche Zeile@Ctrl-U
Programm abbrechenDeleteCtrl-C
Dateiende
Eingabeende
Ctrl-DCtrl-D
Ausgabe anhaltenCtrl-SCtrl-S
Ausgabe fortsetzenCtrl-QCtrl-Q
Bildschirm
wiederherstellen
Ctrl-LCtrl-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.

1.5.4 Dateikommandos

Die ersten Kommandos

Die meisten UNIX-Befehle (= Programme) haben sehr kurze, kryptische Namen - und dafür zahllose Parametereinstellungen.

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:

  • cd Wechsel ins Home-Directory
  • cd [Verzeichnis] Wechsel in das angegebene Verzeichnis
Es können beliebige Pfade angegeben werden, z. B.: cd /usr/hans/daten

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:

  • -d   nur Verzeichnisse auflisten
  • -a   alleEinträge auflisten
  • -l   Langform (alle Infos)
  • -i   Inode-Nummer anzeigen
  • -n   UID-, GID-Nummer anzeigen
  • -R   alle Unterverzeichnisse auch anzeigen
  • -C   mehrspaltige Ausgabe (sinnvoll bei Kurzform)
  • -F   Kurzformat
  • -p   / nach Verzeichnisnamen anzeigen (passt zu -C)

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.

1.6 Das Prozeßkonzept

Jeder Prozeß, der im Betriebssystemkern aktiviert wird, erhält eine eindeutige Kennzeichnung, die sogenannte Prozeßnummer (PID). Über diese kann jeder Prozeß eindeutig identifiziert werden. Da die Prozeßnummer eine positive Integer-Zahl ist, gibt es eine maximale Prozeßnummer. Wird diese erreicht, beginnt die Zählung wieder von vorne, wobei noch existierende Prozesse mit niedriger Nummer übersprungen werden.

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.

  • Jeder Prozeß kann beliebig viele neue Prozesse erzeugen
  • Die Kindprozesse erben die gesamte Prozeß-Umgebung (Home-Directory, Standard-Pfadnamen, Terminal-Typ, etc.)
  • Eltern- und Kindprozesse laufen asynchron (Elternprozeß kann auf Ende des/der Kindprozess(e) warten --> Synchronisation)
  • Eltern- und Kindprozesse können miteinamder kommunizieren
  • Prozeß-Generierung mit fork()
  • Zwei Prozesse können miteinander kommunizieren und sich untereinander synchronisieren
  • Ein Prozeß kann einen Nachfolgeprozeß starten: exec()
  • 40 externe Prioritätsebenen, 2 interne Prioritätsebenen (System/User)

1.6.1 Der Scheduler

UNIX ist ein Multitasking-Betriebssystem, d.h. mehrere Prozesse eines oder mehrerer Benutzer konkurrieren um die Vergabe der Rechenzeit des Prozessors. Wie viele andere Systeme auch, arbeitet UNIX nach dem Zeitscheiben-Prinzip.

Ü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:

  • Round Robin mit Multilevel Feedback (siehe Kap. 1)
  • Neuberechnung aller Prioritäten einmal pro Sekunde - Hohe CPU-Auslastung: Priorität sinkt
  • länger nicht gerechnet: Priorität steigt
--> einfach, effizient, gerecht

1.6.2 Swapping und Paging

  • Wächst ein laufender Prozeß dynamisch, werden andere Prozesse auf Platte ausgelagert; zunächst blockierte P., dann erst bereite P.
  • Steht wieder Speicher zur Verfügung, werden erst die bereiten P. und dann die blockierten P. zurückgeholt.
  • Je nach Hardware kann auch virtuelle Speicherverwaltung verwendet werden (Paging); bei anderen Maschinen gibt es nur Swapping.

1.6.3 Speicheraufteilung eines Prozesses im Arbeitsspeicher

Der Speicher zu einem Prozeß wird in verschiedene Segmente unterteilt:
  • Environment: Programmumgebung (Eigentümer, Home-Dir., usw.)
  • Text: Programmcode (schreibgeschützt) - kann von mehreren Prozessen gleichzeitigverwendet werden
  • Daten: Benutzerdaten des Prozesses. Unterteilt in einen initialisierten und einen nicht init. Datenbereich
  • Stack: Benutzerstack und Verwaltungsinfo

1.6.4 Prozeßkommunikation und -Synchronisation

  • Dateien Ein oder mehrere Prozesse schreiben in Dateien, die von anderen Prozessen gelesen werden (wenig effizient).
  • Pipes (Datenkanäle) Eine Pipe ist ein FIFO-organisierter Speicher, in den ein Prozeß schreibt und aus dem ein anderer Prozeß liest (FIFO = first in, first out). Pipes werden wie Dateien angesprochen, sind jedoch in der Regel als Pufferbereich im Hauptspeicher organisiert (auf Datei muß erst ausgewichen werden, wenn der Puffer überläuft).
  • Signale sind Software-Interrupts, die asynchron auftreten. Hauptsächlich zur Kommunikation Benutzerprogramm <--> BS. Auslösung z. B. durch:
    • Aktionen des Benutzers (CTRL-C)
    • Programmfehler
    • durch andere Prozesse Im Prozeß muß explizit festgelegt werden, welche Aktion auf ein bestimmtes Signal erfolgen soll:
    • Ignorieren
    • Bearbeiten durch eine Service-Routine
    Ist nichts entsprechendes definiert, wird der Prozeß abgebrochen.
  • Named Pipes Bei einfachen Pipes gelten zwei Einschränkungen:
    • Lebensdauer an die Lebensdauer der beteiligten Prozesse gebunden
    • Kommunikation nur für Prozesse mit gemeinsamen Elternprozeß oder zwischen Eltern- und Kindprozeß
    Named Pipes werden als Spezialdateien angelegt (siehe Dateitypen), die sich wie Gerätedateien verhalten und beliebig lange leben können. Named Pipes können nur einmal gelesen werden und natürlich arbeiten sie als FIFO.
  • Message Queues dienen dem Austausch von strukturierten Nachrichten über eine Dienstleistung des BS.
  • Semaphore sind Zustandsvariablen als elementarer Mechanismuns zur Synchronisation von Prozessen.
  • Shared Memory ist ein gemeinsamer Datenbereich im Hauptspeicher, der von zwei Prozessen genutzt werden kann (sehr viel effizienter als Dateien).

1.6.5 fork(), exec() und wait()

Diese Systemaufrufe haben mit der Generierung von Kindprozessen zu tun und erlauben die Synchronisation zwischen Eltern- und Kindprozessen. An dieser Stelle wird nur soweit darauf eingegangen, wie es zum Verständnis der folgenden Abschnitte nötig ist.

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.

  • Etliche Systemprozesse schließen stdin, stdout und stderr, treten also in den Hintergrund. Solche Prozesse nennt man 'demon' (Daemonprozesse).
  • Terminiert der Elternprozeß vor dem Kindprozeß, wird dieser zum 'Waisenkind'. Normalerweise wird er dann vom Init-Prozeß 'adoptiert'.
  • Hat der Kindprozeß dann auch noch den Kontakt zum Terminal (Standardausgabe und -eingabe) wird er zum 'Zombie'.

Einzelschritte beim Aufruf von fork():

  1. Prozeßtabelle überprüfen (Platz frei?)
  2. Speicher für Kindp. allokieren
  3. Elternprozeß-Speicher --> Kindprozeß-Speicher kopieren
  4. Prozeßtabelleneintrag es Elternprozesses aktualisieren
  5. PID für Kindp. wählen, Kindp. in Prozeßtabelle eintragen
  6. Kernel und Dateisystem über Kindprozeß informieren
  7. Fertigmeldung an Eltern- und Kindprozeß senden

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:

  • 1. Elternprozeß ruft wait() zu spät auf:

    Beim Wait-Aufruf wird zuerst die Prozeßtabelle nach terminierten Kindprozessen durchsucht und diese dann gelöscht.

  • 2. Elternprozeß ist terminiert:

    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:

  1. Zugriffsrechte prüfen (Datei ausführbar?)
  2. Größe der Speichersegmente feststellen
  3. Aufrufparameter und Umgebung des Aufrufers festhalten
  4. Speicher des Aufrufers freigeben, neuen Speicher allokieren
  5. Neues Programm in den Speicher laden
  6. UID-, GID-Bits bearbeiten
  7. Prozeßtabelle aktualisieren
  8. Bereitmeldung an den Kernel senden

    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]).

    1.6.6 Die Programme init und getty

    Nach dem Start des Rechners und Laden von UNIX starten als erstes:
    • der Scheduler mit der Prozeßnummer 0
    • und das Programm init mit der Prozeßnummer 1

    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?

    • getty wird von init für jedes angeschlossene Terminal gestartet.
    • getty wartet, bis das Terminal eingeschaltet wird, liest den Usernamen ein und ruft dann mittels exec das login-Programm auf, das seinerseits das Passwort einliest.
    • Wenn sich nun ein Benutzer anmeldet, wird das in der Benutzerliste spezifizierte Programm per exec aktiviert (in der Regel der Kommandointerpreter, die Shell).

    • Die Shell (oder das anstelle der Shell aufgerufene Programm) arbeitet, bis es terminiert (bei der Shell durch Eingabe von EOF = CTRL-D). Da auch die Shell immer noch Kindprozeß von init ist, erhält nun init ein Signal, daß der Kindprozeß terminiert ist (siehe fork).
    • Nun "wacht init auf", stellt fest, welcher seiner Kindprozesse terminiert ist und durchsucht die Datei /etc/inititab - uns interessiert wieder nur getty.
    • In inititab steht beim Prozeß getty die Steuerinformation respawn (spawn = "laichen"). Das heißt für init, daß dieser Prozeß nach seiner Terminierung neu gestartet werden soll - und genau das geschieht.

    1.6.7 Vorbemerkung zur Shell

    Der Kommandointerpreter heißt bei UNIX 'Shell' (er umgibt das System wie eine Schale die Muschel). Die Shell ist sehr leistungsfähig und man kann über eine eigene Programmiersprache Kommandoprozeduren, sogenannte Shell-scripts, erstellen, die sich wie Programme aufrufen lassen. Darauf wird später noch genau eingegangen. Zunächst geht es um die grundlegenden Funktionen. Dabei ist immer von der StandardShell, der Bourne-Shell die Rede. Analoges gilt auch für andere Shells (bash = bourne again Shell, C-Shell, Korn-Shell); es werden dort aber teilweise andere Startdateien verwendet.
    • Nach dem Start sucht die Shell nach der Datei /etc/profile und führt die darin enthaltenen Kommandos aus. /etc/profile ist also für alle Benutzer gleich.
    • Dann erfolgt der gleiche Vorgang mit der benutzereigenen Datei .profile im Home-Directory.
    • Nun macht die Shell nichts anderes, als Eingaben vom Benutzer anzunehmen und die entsprechenden Programme aufzurufen.
    • Zeigt der Benutzer durch Eingabe von EOF = CTRL-D an, daß keine Kommandos mehr folgen, terminiert die Shell.

    1.6.8 Einflußnahme des Benutzers auf Prozesse

    • Der Benutzer kann Prozesse erzeugen (siehe vorher)
    • Der Benutzer kann eigene Prozesse jederzeit terminieren
    • Prozesse können "im Hintergrund" laufen (mit hoher oder niedriger Priorität)
    • Prozesse können als Batch (d.h. ohne Bindung an ein Terminal) laufen
    • Prozesse können regelmäßig zu bestimmten Zeiten gestartet werden (z. B. jede Nacht, jede Woche, etc.)
    • Prozesse können zu einem bestimmten Zeitpunkt gestartet werden
    Alles wird später im Detail behandelt!

    1.7 Grundlagen der Benutzerverwaltung

    Die Benutzerverwaltung ist bei UNIX ebenso offen aufgebaut, wie der Rest des Systems. Es existieren zwei Text-Dateien, die sämtliche Benutzerinformation aufnehmen:
    • /etc/passwd nimmt Benutzerdaten und Paßwort auf
      so war es jedenfalls bei den früheren Systemen (siehe unten). Deshalb gibt es seit einiger Zeit:
    • /etc/shadow nimmt das Passwort auf und ist nur von root lesbar
    • /etc/group nimmt die Gruppenzugehörigkeit auf

    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.

    1.7.1 Was geschieht beim Login?

    • Das Programm login erhält vom getty-Prozeß den eingegeben Benutzernamen (Login-Namen) und sucht nun in der Datei /etc/passwd nach einer passenden Zeile. Wird nichts gefunden --> Benutzer nach Paßwortabfrage abweisen.
    • Ist der Benutzer gefunden, wird überprüft, ob ein Paßwort eingetragen ist. Falls vorhanden, wird das Paßwort abgefragt und bei fehlerhafter Eingabe der Benutzer abgewiesen.
    • Danach wird das im Benutzereintrag spezifizierte Programm gestartet. In der Regel ist dies die Shell.

    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.

    1.7.2 Aufbau der Datei /etc/passwd

    Die Datei ist eine normale Textdatei und sie enthält für jeden Benutzer genau eine Zeile mit 7 Feldern, die jeweils durch einen Doppelpunkt voneinander getrennt sind. Die Zeilenlänge darf 511 Zeichen nicht überschreiten, wobei die Länge der einzelnen Felder variabel ist. Der Aufbau der Zeile ist:

    Login-Name:Paßwort:UID:GID:Kommentar:Home-Directory:Programm

    • Der Login-Name (3 .. 6 Zeichen) ist der Name, unter dem der Benutzer dem BS bekannt ist. Er kann Großbuchstaben enthalten. Besteht er vollständig aus Großbuchstaben, schaltet UNIX auf Großschreibung um (historisch bedingt).
    • Das Paßwort ist verschlüsselt und es ist stets 13 Zeichen lang. Ist das Feld leer muß kein Paßwort eingegeben werden (nur RETURN-Taste). Der Superuser kann zusätzlich ein Komma und zwei weitere Zeichen eintragen, die die Gültigkeitsdauer festlegen (später mehr). Anmerkung: Ab Version 5.3 steht hier nur ein "x" und das Paßwort in /etc/shadow. Das Paßwort darf nicht mit dem Login-Namen übereinstimmen, muß mindestens 6-8 Zeichen lang sein und muß mind. zwei Buchstaben und eine Ziffer enthalten.
    • UID = User Ident: In diesem Feld wird die Benutzernummer festgehalten (Wertebereich 0 bis 50000). Jeder Benutzer muß eine individuelle UID besitzen. Die 0 ist für den Superuser reserviert, die UIDs 1 - 99 für interne Zwecke. Reguläre Benutzer beginnen ab UID 100.
    • GID = Group ID: In diesem Feld wird festgehalten, zu welcher Gruppe der Benutzer gehört (Wertebereich 0 bis 50000). I. A. wird die GID 100 als Sammelgruppe verwendet (für alle Benutzer die keiner anderen Gruppe zugeordnet werden).
    • Kommentar: In diesem Feld (max. Länge 30 Stellen) werden allgemeine Hinweise zum Benutzer eingetragen (normalerweise der vollständige Name des Benutzers, Abteilung, etc). Dieses Feld wird beispielsweise von Mail- und News-Programmen abgefragt, um automatisch den Absender einzutragen.
    • Home Directory: Beim Eintragen eines Benutzers wird ihm auch ein Arbeitsverzeichnis, das Home Directory, eingerichtet. In dieses Verzeichnis wird beim Login verzweigt. Der Pfad muß vollständig eingegeben werden.
    • Programm: Hier wird das Programm angegeben (vollständiger Pfadname, max. 256 Zeichen), das nach Beendigung von login gestartet werden soll. Bei normalen Benutzern ist dies der Kommandointerpreter, die Shell. Sie wird auch gestartet, wenn dieser Eintrag fehlt. Je nach Anwendung des Rechners können hier aber auch andere Programme eingetragen werden, z. B. für die Buchhaltung gleich das Buchhaltungsprogramm. Es gibt auch die Auswahl zwischen den verschiedenen Shells (C-Shell, Bourne-Shell, Korn-Shell) oder der restricted Shell, die einen eingeschränkten Befehlsumfang besitzt.

    Beispiel für einen Eintrag in /etc/passwd:

    karl:,..:235:100:Karl Müller:/usr/karl:/bin/sh

    Gültigkeitsdauer des Paßworts:

    Die Gültigkeitsdauer des Paßworts wird im Paßwortfeld durch Anfügen von Komma und zwei Zeichen vom Superuser eingeschränkt. Bei Verwendung der Shadow-Datei stehen diese Angaben dort.
    • Das erste Zeichen legt die minimale Gültigkeitsdauer fest, d. h. in dieser Zeit kann das Paßwort nicht geändert werden.
    • Das zweite Zeichen legt die maximale Gültigkeitsdauer fest, d. h. nach Ablauf dieser Zeit muß das Paßwort geändert werden.

    Die Zeitdauer wird in Wochen gezählt; der Punkt "." bedeutet 0 Wochen, der Schrägstrich "/" 1 Woche, dann folgen Ziffern und Buchstaben:

  9. 0..9: 2 bis 11 Wochen
  10. A..Z: 12 bis 37 Wochen
  11. a..z: 38 bis 63 Wochen

    Sonderfälle:

    • .. (zwei Punkte) Der Benutzer muß beim nächsten Login sein Paßwort ändern - danach lebt es ewig (für neu eingerichtete Benutzer).
    • ./(Punkt, Schrägstrich) Der Benutzer kann sein Paßwort nicht mehr ändern. Sinnvoll bei einer "Gast"-Kennung, denn der Gast soll das Paßwort nicht ändern können.

    1.7.3 Aufbau der Datei /etc/group

    Auch diese Datei kann von den Benutzern nur gelesen werden, das Schreiben ist dem Superuser vorbehalten. Sie legt die Gruppenzugehörigkeit der Benutzer fest. Die Datei besteht aus Textzeilen mit 4 Feldern, die durch Doppelpunkte getrennt sind:

    Gruppenname:Paßwort:GID:Benutzernamen

    • Gruppenname: Maximal 8 Buchstaben/ziffern, die den Namen der Gruppe festlegen.
    • Paßwort: Zwar ursprünglich konzipiert, bleibt dieses Feld leer, denn es gibt keine Möglichkeit, das Paßwort verschlüsselt einzutragen.
    • GID = Group ID: In diesem Feld wird festgehalten, zu welcher Gruppe der Benutzer gehört (Wertebereich 0 bis 50000). Die Nummern 0 bis 99 sind für interne Zwecke reserviert, GID 100 wird als Sammelgruppe verwendet.
    • Benutzernamen: Hier werden alle Login-Namen der zur Gruppe gehörenden Benutzer, getrennt durch Komma, eingetragen. Einträge für die Standardgruppe, die in der Datei /etc/passwd festgelegt ist, sind nicht nötig.

    Beispiel für einen Eintrag in /etc/group:

    dozenten::200:kristl,plate,rother,ries,thomas

    1.7.4 Aufbau der Datei /etc/shadow

    Diese Datei kann von den Benutzern nicht gelesen werden, das Lesen und Schreiben ist dem Superuser vorbehalten. Sie enthält das Benutzerpaßwort und Angaben über die Gültigkeitsdauer von Paßwort und Benutzeraccount. Die Datei besteht aus Textzeilen mit 9 Feldern, die durch Doppelpunkte getrennt sind:

    Name:Paßwort:letzte Änderung:Min:Max:Vorwarnzeit:Inaktiv:Verfall:Kennzeichen

    • Name: Derselbe Benutzername, wie er in /etc/passwd steht
    • Paßwort: Normalerweise 13-stelliges, verschlüsseltes Paßwort, in dem die ersten beiden Stellen die Verschlüsselungsmethode (eine aus 4096) kennzeichnen. Anstelle des Paßworts kann hier auch ein Sperrvermerk stehen.
    • letzte Änderung: Der Tag der letzten Änderung des Paßworts. Gezählt wird in Tagen ab dem 1.1.1970 (offizieller Entstehungstag von UNIX).
    • Min: Minimale Gültigkeitsdauer des Paßworts in Tagen (vorher ist kein Ändern möglich).
    • Max: Maximale Gültigkeitsdauer des Paßworts in Tagen. Der Benutzer muß vor Ablauf dieser Frist sein Paßwort ändern.
    • Vorwarnzeit: Anzahl der Tage, wie lange der Benutzer vor Verfall seines Paßworts auf die notwendige Änderung hingewiesen wird.
    • Inaktiv: Anzahl der Tage, die es dem Benutzer gestattet ist, seinen Account unbenutzt zu lassen.
    • Verfall: Absolutes Datum, an dem die Verwendung des Accounts gesperrt wird.
    • Kennzeichen: Reserviert für künftige Verwendung. Derzeit auf 0 gesetzt. Damit nun nicht alle Diese Daten beim Anlegen eines Benutzers von Hand eingegeben werden müssen, wird - so vorhanden- die Datei /etc/default/passwd herangezogen, in der Standardwerte gespeichert sind.

    1.7.5 Voreinstellungsverzeichnis /etc/default

    In diesem Verzeichnis werden unter UNIX V.4 die Standardwerte für verschiedene Programme abgelegt. Das Verzeichnis enthält Dateien, deren Namen sich auf das zugehörige Programm oder die zugehörige Funktion des Betriebssystems beziehen, z. B. "passwd", "tar", "boot", "init", etc. Die Einträge in den Daten bestehen in der Regel aus Zeilen mit jeweils einer Zuweisung der Form 'Schlüsselwort'='Wert'. Dazu ein Beispiel:

    /etc/default/passwd:
    Standardwerte für das Paßwort und seine Gültigkeitsdauer. Einige wichtige Werte sind:

    • MAXWEEKS='maximale Zeit, bis das PW geändert werden muß'
    • MINWEEKS='minimale Zeit, in der das PW nicht geändert wird'
    • WARNWEEKS='Vorwarnzeit'
    • PASSLENGTH='minimale Passwortlänge'

    1.7.6 Anlegen eines Benutzers

    Erstaunlicherweise gab es ursprünglich kein Programm zum Anlegen von Benutzern - bei den meisten Systemen hat sich jedoch der Systemverwalter (= Superuser) ein Shell-script dafür angelegt. Bei vielen Systemen wird heute ein Standard-Tool mitgeliefert ('useradd' oder 'adduser'). Anmerkung: In diesem Abschnitt werden einige Kommandos erwähnt, die erst zu einem späteren Zeitpunkt näher erläutert werden. Um einen Benutzer neu einzutragen sind folgende Schritte notwendig:
    • Benutzer in der Datei /etc/passwd eintragen. Dabei ist darauf zu achten, daß der Login-Name und die UID eindeutig, d. h. nur einmal vorhanden, sind - sonst kommte es zu Schwierigkeiten bei der Zuordnung des Homedirectory und anderer Dateien.
    • In der Datei /etc/group wird der neue Login-Name im entsprechenden Gruppeneintrag ergänzt.
    • Nun wird das Home-Directory des neuen Benutzers eingerichtet und - falls erwünscht - eine Standardversion der Datei .profile (bei C-Shell .login) dorthin kopiert.
    • Home-Directory und .profile sind immer noch "Eigentum" des Superusers, mit dem chown-Befehl (Change Owner) werden beide an den neuen Benutzer übergeben. An sich reicht das aus. Jetzt können noch von der Arbeitsumgebung abhängende Maßnahmen vorgenommen werden.
    In der Regel wird das Anlegen und Löschen eines Users durch passende Systemprogramme oder -Skripten erledigt.

    Einen Benutzer sperren

    Soll ein Benutzer zeitweise (z. B. bei längerem Urlaub) oder auf Dauer gesperrt werden, seine Dateien aber noch erhalten bleiben, trägt der Superuser im Paßwortfeld einen Zeichenfolge ein, die als Ergebnis der Verschlüsselung nicht vorkommen kann, z. B. '*LCK*'. Überprüfung von /etc/passwd und /etc/group.

    1.7.7 Löschen eines Benutzers

    Die hierfür notwendigen Schritte sind wesentlich gefährlicher, da hier u. U. wichtige Informationen gelöscht werden. In der Regel wird der Benutzer zunächst deaktiviert (er kann sich also nicht mehr einloggen) und erst nach einer gewissen Zeit vollständig gelöscht. Dazu sind dann folgende Schritte nötig:
    • Löschen des Home-Directories mit allen darunter liegenden Dateien und Verzeichnissen (rm-Kommando)
    • Löschen des mail-Directory und aller Spool-Dateien
    • Löschen der zum Benutzer gehörenden Zeile aus /etc/passwd
    • Löschen des Login-Namens aus /etc/group Anmerkung:

    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.

    1.8 Starten und Stoppen des Systems

    Wie schon anfangs gesagt, sind Start (Bootstrap) und Stop (Shutdown) des Systems bei UNIX wesentlich komplexer, als bei einfachen Betriebssystemen. Es gibt - abhängig von den jeweiligen Aufgaben - mehrere "Run-levels" des Systems; hier nur eine Auswahl:

    0Power-Down: Ausschalten des Rechners
    1Administrativer Level: z. B. Einrichten neu eingebauter Platten oder andere Hardware-Initialisierungen. Oft auch "s" oder "S" (Singleuser = Einzelbenutzer-Modus).
    2Multiuser-Modus ohne Netzwerkanbindung
    3Multiuser-Modus mit Netzwerkanbindung (Normal-Level)
    4Frei für benutzerdefinierten Modus
    5Firmware-Modus: z. B. Diagnose und Wartung; oft nur mit spezieller Floppy zu starten
    6Shutdown 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:

    • Testen der Dateisysteme (Platten)
    • Montieren (mount) der Platten (Info aus /etc/fstab bzw. /etc/vfstab).
    • Säuberungsaktionen (z.B. Löschen von temporären Dateien, Aufheben von eventuell beim Shutdown gesetzten Sperren, etc.
    • Starten der Systemprozesse (Scheduler, init, getty, cron, Printer-Daemon, Mail, Accounting, etc.
    • Start der Netzwerk-Programme, montieren von Remote-Platten (NFS)
    • User-Login freigeben

    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.localStart lokaler Software
    /etc/rc.netStart der Netzwerksoftware
    /etc/rc.singleStart 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 ein Verzeichnis unter /etc, wobei der Name der Verzeichnisse einheitlich /etc/rcx.d ist (x 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 rcx.d sind nun nur noch Links auf diese Programme enthalten. Alle Links folgen ebenfalls einer festen Namenskonvention:

    • der erste Buchstabe ist entweder ein "S" oder ein "K"
    • danach folgt einezweistellige Zahl
    • zum Schluß folgt der Name des Programms in /etc/init.d

    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:

    • K30tcp
    • S20sysetup
    • S85lp
    • K40nfs
    • S40nfs
    • S75cron.

    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
    

    1.9 Sicherheitsmaßnahmen bei Arbeiten mit Root-Rechten

    Grundsätzlich sollten nur diejenigen Arbeiten mit Superuser-Rechten vorgenommen werden, die wirklich Root-Rechte benötigen. Da 'Root' wirklich alles darf, können Fehler massive Probleme bringen (z. B. das Löschen von Dateien oder das Ändern von Zugriffsrechten). Alle anderen Arbeiten können als 'Normaluser' oder mit Privilegien durch besondere Gruppenrechte durchgeführt werden. Durch Setzen von Gruppenrechten können auch bestimmte Benutzer mit Administrativen Aufgaben für bestimmte Bereiche betraut werden. Anmerkung: Durch die Vergabe von Gruppenrechten kann man sogar bestimmte Benutzergruppen "aussperren". Man ordnet den Benutzern und den zu vor ihnen zu schützenden Verzeichnissen und Dateien dieselbe Gruppe zu. Danach nimmt man bei den Dateien und Verzeichnisse die Gruppenzugriffsrechte weg. Bei Änderungen an "lebenswichtigen" Dateien, zu denen auch die oben genannten gehören, sollte man noch einen Superuser-Login auf einen zweiten Terminal haben laufen haben. Nach den Änderungen wird dann getestet, ob beim root-Login noch alles in Ordnung ist. Im Notfall kann man dann vom zweiten Terminal aus eingreifen. Auch hier gilt grundsätzlich, daß man sich sicher darüber sein sollte, was man eigentlich tut. Von zu verändernden Dateien werden zunächst Sicherheitskopien angefertigt. Bei Shell-Scripts und Konfigurationsdateien kann man vor dem Ändern einzelner Zeilen die betreffenden Zeilen zuerst kopieren und dann die "alte" Version der Zeile durch eine Kommentar-Markierung deaktivieren (bei UNIX sind alle Zeilen, die mit '#' beginnen, Kommantare). Das gilt auch für zu löschende Einträge, die ebenfalls "auskommentiert" werden. So kann man leicht zum alten Stand zurückkehren, wenn nach der Änderung etwas nicht klappt. Als Systemadministrator sollte man auch ein Tagebuch führen. Das kann ein einfaches Heft sein, in das man einträgt, was wann geändert wurde. Manche Fehler zeigen sich erst später und nur auf sein Gedächtnis sollte man sich nicht verlassen.

    Das X Window System

    Der Name

    Fast jeder sagt "X-Windows", dieser Name ist jedoch nicht korrekt. Das X Consortium hat die folgenden Namen als richtig festgelegt:
    • X
    • X Window System
    • X Version 11
    • X Window System, Version 11
    • X11

    Das X Window System

    X begann als Protokollspezifikation. Nachdem vor einigen Jahren immer schnellere Rechner mit Bitmap-Grafikdisplays erhältlich waren, ging das MIT mit der Unterstützung von einigen Firmen (dem X Consortium) daran, das Windowsystem für die Zukunft zu spezifizieren. Es wurde dabei zuerst ein Protokoll festgelegt. Danach begann das MIT mit einer Beispielimplementierung des Protokolls, um zu zeigen, wie es funktioniert und welche Möglichkeiten es bietet. Nach einigen Jahren begannen dann Firmen mit dem Vertrieb von kommerziellen Implementierungen des X Protokolls.

    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.

    Komponenten von X

    X benötigt hardwareseitig ein Bitmap-Display, eine Tastatur und ein Pointing-Device (Maus, Grafiktablett, etc.)

    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:

    vtwmVirtual twm (virtueller Screen mit Window)
    gwmGeneric Window Manager (gut konfigurierbar)
    olwmOPEN LOOK Window Manager
    mwmMotif Window Manager
    ...Und viele andere

    Was ist das Besondere an X?

    X ist ein portables Windowsystem. X benötigt nur Benutzerprozeße und keine Veränderungen am Betriebssystemkern. X-Server gibt es auch auf anderen Betriebssystemen (MS-DOS, MacOS, Atari TOS, Windows etc.) und es gibt sogenannte X-Terminals, intelligente Grafikterminals, die einen integrierten X Server haben.

    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.

    Wie benutzt man X über ein Netzwerk

    Das X Protokoll unterstützt ja auch Rechner, die vernetzt sind. Das bedeutet, man kann Ausgaben von einem Client auf Rechner A auch auf einem Server auf Rechner B ausgeben. Dafür ist folgendes notwendig:

    Auf dem Zielrechner muß dem Server mitgeteilt werden, daß er Requests vom Senderechner zulassen darf. Das geschieht mit dem Kommando:

       xhost +senderechner
    
    Auf 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:0
    
    oder man schreibt beim Aufruf des Programms
       clientprogramm -display zielrechner:0
    
    Die 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.

    Die X Session

    Entweder sofort nach dem Einloggen oder durch das Kommando startx wird für den Benutzer eine Session gestartet. Dabei werden automatisch verschiedene Clients gestartet (xterm, twm, xclock, etc.). Die Session beendet sich, wenn der Windowmanager beendet wird.

    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

    X-Clients können durch Resourcen parametrisiert werden. Clients besitzen Variablen, die zur Kommunikation zwischen Clients dienen. Diese sind die sogenannten Properties. Eine spezielle Property des Servers sind die Resources. In ihnen sind Parameter gespeichert, welche Clients abfragen können. Resourcen sind zum Beispiel geometry oder font.

    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+).

    X und Sicherheit

    Ein Problem von X ist noch die Sicherheit. Zum Beispiel kommt es vor, daß xterm-Fenster beim Ausloggen nicht geschloßen werden, sondern beim nächsten Benutzer wieder auf dem Bildschirm erscheinen.

    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.

    Der Terminalemulator xterm

    Um Nicht-X-Programme unter X laufen lassen zu können, gibt es den Terminalemulator xterm. Er erzeugt ein Fenster, das sich wie der normale Textbildschirm an einem UNIX-Rechner verhält. Um die Nutzung optimal zu gestalten, können mit dem Aufruf mehrere Optionen eingestellt werden, von denen einige hier aufgeführt werden (Vollständig sind sie in der Manualseite aufgeführt):

    xterm [Optionen]
    oder
    xterm [Optionen] & (als Hintergrundprozeß)

    Optionen:

      -e name [parameter]: Das Programm name wird sofort ausgeführt, wenn sich das Fenster öffnet. Am Ende des Programms wird das Fenster wieder geschlossen. Die angegebenen Parameter werden dem Programm übergeben. Der Fenstertitel und Iconname heißen dann auch name (soweit keine Option -T oder -n verwendet wurde).
      Die Option muß als letzte in der Optionenfolge eingegeben werden, da alles, was der gesamte Zeilenrest als Teil des auszuführenden Befehls betrachtet wird! Beispiel:
      xterm -e vi main.c
    • -l: Jede Ausgabe in xterm wird in der Datei XtermLog.nnnn (nnnn entspricht der Prozeßnummer) abgespeichert und gleichzeitig im Fenster angezeigt.
    • +l: Kein Logging.
    • -lf Dateiname: Die Logging-Ausgabe wird in der Datei Dateiname abgelegt.
    • -sb: Erzeugt den Scroll-Balken am linken Fensterrand.
    • +sb: Kein Scroll-Balken.
    • -sl nn: nn gibt an, wieviele Zeilen nach dem Herausrollen aus dem Anzeigebereich gespeichert werden sollen. Voreinstellung: 64 Zeilen.
    • -T string: setzt string als Fenstertitel.
    • -n string: setzt string als Fensternamen für den Iconmanager.
    • -rv: Tausche Vordergrund- und Hintergrundfarbe.
    • -geometry expression: gibt an, wie groß das Fenster sein soll und wo es plaziert werden soll. Das Format für expression:

      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:

      • +0+0 obere, linke Ecke
      • -0+0 obere, rechte Ecke
      • -0-0 untere, rechte Ecke
      • +0-0 untere, linke Ecke
      Es kann auch nur die Größe oder nur die Position angegeben werden. Beispiel:

      xterm -geometry 80x25+200+400

    • -iconic: Das aufgerufene Fenster wird sofort iconifiziert. Es erscheint also nur als Eintrag im Iconmanager (falls vorhanden) und/oder als einzelnes Icon.

    Die Datei .xsession

    Diese Datei wird nach dem Anmelden vom System abgearbeitet. Es handelt sich bei ihr um ein Shellscript, das von der Standardshell des Benutzers. Die Sitzung eines Benutzers dauert so lange, bis die Datei .xsession vollständig abgearbeitet wurde. Daraus folgt, daß .xsession mindestens ein Programm nicht als Hintergrundprozeß starten darf. Das Ende dieses Programms stellt dann auch das Ende der Sitzung dar. Es ist sinnvoll, Programmen, die man in .xsession startet, eine Positionsangabe mitzugeben, entweder direkt oder über .Xdefaults. Tut man das nicht, muß man das Fenster jeweils per Hand auf dem Bildschirm positionieren. Das Angeben der Position ist bei vielen Programmen über den Parameter -geometry möglich. Beispiel:

    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.

    Die Datei .xxxwmrc

    Diese Datei konfiguriert den Window-Manager (wobei "xxx" für den gewählten Window-Manager steht. Dieser stellt er die Menüs zur Verfügung, die erscheinen, wenn man auf dem root-Fenster (dem Bildschirmhintergrund) die mittlere oder die rechte Maustaste drückt. Diese Datei dient dazu, die Benutzeroberfläche frei nach seinen eigenen Wünschen zu gestalten.

    Die Datei .rhosts

    Diese Datei gibt an, wer sich von welchem Rechner aus ohne Angabe eines Paßwortes am Rechner anmelden darf. Damit kann man vermeiden, daß bei jedem Aufruf von rlogin das Paßwort eingegeben werden muß. .rhosts darf nur für den User selbst schreibbar sein. Sie muß jedoch für alle lesbar sein. Jede Zeile in .rhosts muß folgenden Aufbau haben:

    Rechnername [Benutzer]

    Die Datei .Xdefaults

    Viele X-Clients ermöglichen es, ihr Aussehen und ihre Konfiguration mittels sogenannter Ressourcen festzulegen. Ressourcen sind im Grunde nur Wörter oder Zeichenketten, die der X-Server bereithält und die der X-Client bei Bedarf abfragen kann. Meist erkundigt sich der Client beim Server, ob für ihn Ressourcen definiert sind und verwendet diese, falls es welche gibt. Ansonsten benutzt er Standardwerte. Jeder Benutzer kann seine eigenen Ressourcedefinitionen in der Datei .Xdefaults in seinem HOME-Verzeichnis ablegen. Diese wird, falls vorhanden, automatisch beim Anmelden dem X-Server bekanntgemacht.

    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
    Copyright © FH München, FB 04, Prof. Jürgen Plate
    Letzte Aktualisierung: 09. Mar 2005