Kapitel 16 Besonderheiten in SuSE Linux 16.1 Filesystem Hierarchy Standard (FHS) und Linux Standard Base (LSB) SuSE Linux strebt eine weitgehende Konformität zum Filesystem-Stan- dard (FSSTD) bzw. zu dessen Nachfolger, dem Filesystem Hierarchy Stan- dard (FHS, Paket fhs, Serie doc; vgl. http://www.pathname.com/ fhs/), an. Aus diesem Grunde ist es bisweilen erforderlich, Dateien oder Verzeichnisse an die richtigen" Plätze im Dateisystem zu verschieben. SuSE unterstützt aktiv die Bemühungen des Linux Standard Base-Projekts; aktuelle Informationen dazu unter http://www.linuxbase.org. 16.1.1 Beispiel-Umgebungen für FTP und HTTP Zu FTP Um die Einrichtung eines FTP-Servers zu erleichtern, hält das Paket ftpdir eine Beispiel-Umgebung bereit. Diese Umgebung wird unter /usr/local/ftp installiert. Zu HTTP Apache ist der Standard-Webserver bei SuSE Linux; gleichzeitig mit der Installation des Apache werden Beispiel-Dokumente unter /usr/local/ httpd zur Verfügung gestellt. Wenn Sie einen eigenen Webserver aufbau- en wollen, ist es empfehlenswert, eine eigene DocumentRoot in /etc/ httpd/httpd.conf einzutragen. 16.1.2 teTeX ­ TEX unter SuSE Linux teTeX ist gemäß der TEX Directory Structure (TDS) zusammengestellt (vgl. ftp://ftp.dante.de/tex-archive/tds/), ohne den FHS zu ver- letzen. 16.2 Booten mit der initial ramdisk" 419 16. Besonderheiten in SuSE Linux Problemstellung Sobald der Linux-Kernel geladen ist und das Root-Dateisystem (/) gemoun- tet hat, können Programme ausgeführt und weitere Kernel-Module eingebun- den werden, um zusätzliche Funktionalitäten bereitzustellen. Um aber das Root-Dateisystem überhaupt mounten zu können, müssen ver- schiedene Bedigungen erfüllt sein: Der Kernel benötigt die entsprechenden Treiber, um das Gerät ansprechen zu können, auf dem das Root-Dateisystem liegt (insbesondere SCSI-Treiber). Weiter muss der Kernel den Code ent- halten, der benötigt wird, um das Dateisystem lesen zu können (ext2, reiserfs, romfs usw.). Weiterhin ist es denkbar, dass bereits das Root- Dateisystem verschlüsselt ist; zum Mounten ist in diesem Fall die Eingabe des Schlüssels/Passworts erforderlich. Betrachtet man nur einmal das Problem der SCSI-Treiber, so sind verschiede- ne Lösungsansätze denkbar: Der Kernel kann alle denkbaren Treiber enthal- ten. Problematisch, da sich verschiedene Treiber beißen" können; außerdem wird der Kernel dadurch sehr groß. Eine andere Möglichkeit besteht darin, verschiedene Kernel zur Verfügung zu stellen, die jeweils nur einen oder sehr wenige SCSI-Treiber enthalten. Auch dieser Weg ist problematisch, da er ei- ne sehr große Zahl unterschiedlicher Kernel notwendig macht. Ein Problem, das durch verschieden optimierte Kernel (Pentium-Optimierung, SMP) noch weiter verschärft wird. Der Ansatz, den SCSI-Treiber als Modul zu laden, führt zur generellen Pro- blematik, der durch das Konzept der initial ramdisk begegnet wird: Das Schaffen einer Möglichkeit, Userspace-Programme bereits vor dem Mounten des Root-Dateisystems ausführen zu können. 16.2.1 Konzept der initial ramdisk Die initial ramdisk (auch initdisk" oder initrd" genannt) löst genau diese oben beschriebenen Probleme. Der Linux-Kernel bietet die Möglichkeit, ein (kleines) Dateisystem in eine Ramdisk laden zu lassen, und darin Programme ausführen zu lassen, bevor das eigentliche Root-Dateisystem gemountet wird. Das Laden der initrd wird dabei vom Bootloader (LILO, loadlin usw.) übernommen; all diese Bootloader benötigen lediglich BIOS-Routinen, um Daten vom Bootmedium zu laden. Wenn der Bootloader den Kernel laden kann, dann kann er auch die initial ramdisk laden. Spezielle Treiber sind somit nicht erforderlich. 16.2.2 Ablauf des Bootvorgangs mit initrd Der Bootloader lädt den Kernel und die initrd in den Speicher und startet den Kernel, wobei der Bootloader dem Kernel mitteilt, dass eine initrd vorhanden ist und wo im Speicher diese liegt. War die initrd komprimiert (was typischerweise der Fall ist), so de- komprimiert der Kernel die initrd und mountet sie als temporäres Root- Dateisystem. Hierauf wird in der initrd ein Programm mit dem Namen linuxrc gestartet. Dieses Programm kann nun all die Sachen tun, die erfor- derlich sind, um das richtige Root-Dateisystem mounten zu können. Sobald 420 16.2. Booten mit der initial ramdisk" linuxrc terminiert, wird die (temporäre) initrd wieder abgehängt (engl. unmounted) und der Bootvorgang wird wie gewohnt mit dem Mounten des richtigen Root-Dateisystems fortgeführt. Das Mounten der initrd und das Ausführen von linuxrc kann somit als ein kurzes Intermezzo während eines normalen Bootvorgangs betrachtet werden. Kann die initrd nicht abgehängt werden (was i. a. als Fehler angesehen werden sollte), so versucht der Kernel die initrd auf das Verzeichnis /initrd um-zumounten. Ist auch der Mountpunkt /initrd nicht vorhan- den, so resultiert eine Fehlermeldung. Das System ist in einem solchen Fall voll funktionsfähig, jedoch kann der durch die initrd belegte Speicher nie freigegeben werden und steht somit nicht mehr zur Verfügung. linuxrc Für das Programm linuxrc in der initrd gibt es lediglich die folgenden An- forderungen: Es muss den speziellen Namen linuxrc tragen und es muss im Root-Verzeichnis der initrd liegen. Abgesehen davon muss es lediglich vom Kernel ausgeführt werden können. Das bedeutet, dass linuxrc durchaus dynamisch gelinkt sein darf; in diesem Fall müssen natürlich die shared li- braries" wie gewohnt vollständig unter /lib in der initrd verfügbar sein. Weiter darf linuxrc auch ein Shellskript sein; in diesem Fall muss natürlich eine Shell in /bin existieren. Kurz gesagt, muss die initrd ein mini- males Linux-System enthalten, das die Ausführung des Programmes linuxrc erlaubt. Bei der Installation von SuSE Linux wird ein statisch gelinktes linux- rc verwendet, um die initrd so klein wie möglich halten zu können (der Platz auf Bootdisketten ist sehr knapp). linuxrc wird mit `root'-Rechten ausgeführt. Das echte Root-Dateisystem Sobald linuxrc terminiert, wird die initrd abgehängt und verworfen, der Bootvorgang geht normal weiter und der Kernel mountet das wirkli- che Root-Dateisystem. Was als Root-Dateisystem gemountet werden soll, kann durch linuxrc beeinflusst werden. Dazu muss linuxrc lediglich das /proc-Dateisystem mounten und den Wert des echten Root-Dateisystems in numerischer Form nach /proc/sys/kernel/real-root-dev schrei- ben. 16.2.3 Bootloader Die meisten Bootloader (vor allem LILO, loadlin und syslinux) können mit initrd umgehen. Die einzelnen Bootloader werden wie folgt angewiesen, eine initrd zu verwenden: 1. LILO Eintrag der folgenden Zeile in /etc/lilo.conf: Die Datei /boot/initdisk.gz ist die initial ramdisk. Sie kann (muss aber nicht) komprimiert sein. 2. loadlin.exe Aufruf mittels: C:> loadlin initrd=C:\loadlin\initdisk.gz 421 16. Besonderheiten in SuSE Linux initrd=/boot/initdisk.gz 3. syslinux Eintrag der folgenden Zeile in syslinux.cfg: append initrd=initdisk.gz 16.2.4 Anwendung von initrd bei SuSE Installation des Systems Die initrd wird bereits seit geraumer Zeit für die Installation verwendet: Dabei kann der Anwender in linuxrc Module laden und die für eine Installa- tion notwendigen Eingaben (wie vor allem Quellmedium) machen. Linuxrc startet dann YaST, das die Installation durchführt. Hat YaST seine Arbeit getan, teilt es linuxrc mit, wo das Root-Dateisystem des frisch installierten Systems liegt. linuxrc schreibt diesen Wert nach /proc, beendet sich, und der Kernel bootet in das frisch installierte System weiter. Bei einer Installation von SuSE Linux bootet man somit von Anfang an quasi das System, das gerade erst installiert wird ­ irgendwie schick ;-) Ein ech- ter Reboot nach der Installation erfolgt nur, wenn der gerade laufende Kernel nicht zu den Modulen passt, die im System installiert wurden. Da SuSE Linux derzeit bei der Installation einen Kernel für Uni-Prozessor-Systeme verwen- det, geschieht dies derzeit nur dann, wenn im System ein SMP-Kernel mit- samt entsprechenden Modulen installiert wurde. Um alle Module verwenden zu können, muss deshalb der neu im System installierte SMP-Kernel gebootet werden. Booten des installierten Systems In der Vergangenheit hat YaST mehr als 40 Kernel für die Installation im Sys- tem angeboten, wobei sich die Kernel im Wesentlichen dadurch unterschie- den hatten, dass jeder Kernel einen bestimmten SCSI-Treiber enthielt. Dies war nötig, um nach dem Booten das Root-Dateisystem mounten zu können. Weitere Treiber konnten dann als Modul nachgeladen werden. Da inzwischen aber auch optimierte Kernel zur Verfügung gestellt werden, ist dieses Konzept nicht mehr tragbar ­ es wären inzwischen weit über 100 Kernel-Images nötig. Daher wird nun auch für das normale Starten des Systems eine initrd verwendet. Die Funktionsweise ist analog wie bei einer Installation. Das hier eingesetzte linuxrc ist jedoch einfach nur ein Shellskript, das lediglich die Aufgabe hat, einige vorgegebene Module zu laden. Typischerweise handelt 422 16.2. Booten mit der initial ramdisk" es sich nur um ein einziges Modul, nämlich denjenigen SCSI-Treiber, der benötigt wird, um auf das Root-Dateisystem zugreifen zu können. Erstellen einer initrd Das Erstellen einer initrd erfolgt mittels des Scripts mk_initrd. Die zu ladenden Module werden bei SuSE Linux durch die Bezeichner INITRD_MODULES in /etc/rc.config festgelegt. Nach einer Instal- lation wird diese Variable automatisch durch die richtigen Werte vorbelegt (das Installations-linuxrc weiß ja, welche Module geladen wurden). Dabei ist zu erwähnen, dass die Module in genau der Reihenfolge geladen werden, in der sie in INITRD_MODULES auftauchen. Das ist besonders wichtig, wenn mehrere SCSI-Treiber verwendet werden, da sich ansonsten die Benennung der Platten ändern würde. Strenggenommen würde es reichen, nur denjenigen SCSI-Treiber laden zu lassen, der für den Zugriff auf das Root-Dateisystem benötigt wird. Da das automatische Nachladen zusätzlicher SCSI-Treiber jedoch problematisch ist (wie sollte es getriggert" werden, wenn auch am zweiten SCSI-Adapter Platten hängen), laden wir alle bei der Installation verwendeten SCSI-Treiber mittels der initrd. Das aktuelle mk_initrd prüft, ob für den Zugriff auf das Root-Dateisystem überhaupt ein SCSI-Treiber benötigt wird. Ruft man mk_initrd auf ei- nem System auf, bei dem / auf EIDE-Platten liegt, erstellt es keine initrd, da diese nicht nötig ist, weil die bei SuSE Linux verwendeten Kernel be- reits die EIDE-Treiber enthalten. Da inzwischen immer mehr spezielle EIDE- Controller auf den Markt kommen, wird es aber voraussichtlich für die Zu- kunft nötig werden, auch in diesen Fällen eine initrd für das Booten des installierten Systems zu verwenden. Wichtig: Da das Laden der initrd durch den Bootloader genauso abläuft wie das Laden des Kernels selbst (LILO vermerkt in seiner map-Datei die Lage der Dateien), muss nach jeder Änderung der initrd LILO neu in- stalliert werden! Nach einem mk_initrd ist somit immer auch ein lilo nötig! 16.2.5 Mögliche Schwierigkeit ­ Selbstcompilierte Kernel Übersetzt man sich selbst einen Kernel, so kann es zu folgendem häufigen Problem kommen: Aus Gewohnheit wird der SCSI-Treiber fest in den Ker- nel gelinkt, die bestehende initrd bleibt aber unverändert. Beim Booten geschieht nun folgendes: Der Kernel enthält bereits den SCSI-Treiber, die Hardware wird erkannt. Die initrd versucht nun jedoch, den Treiber noch- mals als Modul zu laden; dies führt bei einigen SCSI-Treibern (insbesondere beim aic7xxx) zum Stillstand des Systems. Strenggenommen handelt es sich um einen Kernelfehler (ein bereits vorhandener Treiber darf nicht ein zweites Mal als Modul geladen werden können) ­ das Problem ist aber be- reits in anderem Zusammenhang bekannt (serieller Treiber). Es gibt mehrere Lösungen für das Problem: Entweder den Treiber als Modul konfigurieren (dann wird er korrekt in der initrd geladen), oder aber den Eintrag für die initrd aus /etc/lilo.conf entfernen. Äquivalent zur letzteren Lösung ist es, den Treiber aus INITRD_MODULES zu entfernen und 423 16. Besonderheiten in SuSE Linux mk_initrd aufzurufen, das dann feststellt, dass keine initrd benötigt wird. 16.2.6 Ausblick Für die Zukunft ist es denkbar, dass eine initrd für weitaus mehr (und anspruchsvollere) Dinge verwendet wird als nur für das Laden der Module, die für den Zugriff auf / benötigt werden. * High end" EIDE-Treiber * Root-Dateisystem auf Software RAID (linuxrc setzt die md-Devices auf) * Root-Dateisystem auf LVM * Root-Dateisystem ist verschlüsselt (linuxrc fragt nach Passwort) * Root-Dateisystem auf einer SCSI-Platte am PCMCIA-Adapter Weitere Informationen /usr/src/linux/Documentation/ramdisk.txt /usr/src/linux/Documentation/initrd.txt Manual-Page von initrd (man 4 initrd). 424 16.3. linuxrc 16.3 linuxrc linuxrc ist ein Programm, das in der Hochlauf-Phase des Kernels gestartet wird, bevor richtig gebootet wird1. Diese angenehme Eigenschaft des Kernels erlaubt es, einen kleinen modularisierten Kernel zu booten und die wenigen Treiber, die man wirklich braucht, als Module nachzuladen ­ im Notfall sogar von einer zweiten Diskette (modules). linuxrc hilft Ihnen, die für Ihre Hardware relevanten Treiber zu laden. Sie können linuxrc nicht nur bei der Installation verwenden, sondern auch als Boot-Tool für Ihr installiertes System (also eine Art Notfalldiskette) und Sie können sogar ein autonomes, RAM-Disk-basiertes Rettungssystem star- ten, etwa wenn etwas Größeres auf der Festplatte zerstört ist oder wenn Sie schlicht das `root'-Passwort vergessen haben. Näheres finden Sie in Ab- schnitt 16.5 auf Seite 432. Hauptmenü Nachdem Sprache, Bildschirm und Tastatur eingestellt sind, kommen Sie in das Hauptmenü von linuxrc (vgl. Abbildung 2.3 auf Seite 30). Ziel ist der Menüpunkt `Installation / System starten'. Ob Sie direkt dorthin verzweigen können, hängt von der Hardware Ihres Rech- ners ab: Wenn alle Komponenten, die für eine Installation benötigt werden, bereits vom Kernel erkannt wurden, so brauchen Sie keine weiteren Treiber zu laden. Dies trifft zu für Rechner, die ausschließlich über Festplatten und CD-ROM- Laufwerk an einem (E)IDE-Adapter verfügen. Besitzt das System einen SCSI-Adapter, der für die Installation benötigt wird2, so muss ein SCSI-Modul geladen werden. Das gleiche gilt, wenn die Installation über das Netzwerk erfolgen soll: Hier muss für die einzusetzende Netzwerkkarte erst ein passendes Modul geladen werden. Schließlich gibt es noch eine Reihe von älteren CD-ROM-Laufwerken, die mit eigener Controller-Karte geliefert wurden und die daher jeweils eigene Kernelmodule benötigen. Auch wenn an einem Laptop PCMCIA-Geräte ver- wendet werden, müssen Sie Module laden. Systeminformationen Sind Sie sich nicht sicher, welche Hardware Ihr Rechner hat, so können Ihnen die Kernelmeldungen helfen, die während des Bootens ausgegeben wurden. Unter `Systeminformationen' (Abbildung 16.1 auf der nächsten Sei- te) können Sie neben den Meldungen des Kernels auch einige weitere Din- ge überprüfen, etwa die I/O-Adressen von PCI-Karten oder die Größe des Hauptspeichers, die von Linux erkannt wurde. Die folgenden Zeilen zeigen, wie sich eine Festplatte und ein CD-ROM- Laufwerk an einem EIDE-Adapter melden. In diesem Fall müssen Sie keine Kernelmodule für eine Installation laden: 1 Natürlich muss der Kernel entsprechend konfiguriert sein. 2 Ein Adapter, an dem nur ein Scanner hängt, kann erst einmal unberücksichtigt bleiben. 425 16. Besonderheiten in SuSE Linux Abbildung 16.1: Systeminformationen hda: ST32140A, 2015MB w/128kB Cache, LBA, CHS=1023/64/63 hdb: CD-ROM CDR-S1G, ATAPI CDROM drive Partition check: hda: hda1 hda2 hda3 < hda5 > Haben Sie einen Kernel gestartet, der bereits einen SCSI-Treiber fest inte- griert hat, so brauchen Sie natürlich ebenfalls kein SCSI-Modul mehr zu la- den. Typische Meldungen bei Erkennung eines SCSI-Adapters und der daran angeschlossenen Geräte: scsi : 1 host. Started kswapd v 1.4.2.2 scsi0 : target 0 accepting period 100ns offset 8 10.00MHz FAST SC- SI-II scsi0 : setting target 0 to period 100ns offset 8 10.00MHz FAST SC- SI-II Vendor: QUANTUM Model: VP32210 Rev: 81H8 Type: Direct-Access ANSI SCSI revisi- on: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 scsi0 : target 2 accepting period 236ns offset 8 4.23MHz syn- chronous SCSI scsi0 : setting target 2 to period 248ns offset 8 4.03MHz syn- chronous SCSI Vendor: TOSHIBA Model: CD-ROM XM-3401TA Rev: 0283 Type: CD-ROM ANSI SCSI revisi- on: 02 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 4308352 [2103 MB] [2.1 GB] Partition check: sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 > Laden von Modulen Sie wählen aus, welche Art von Modul Sie benötigen. Wurde von der Diskette gebootet, werden nun die entsprechenden Daten von linuxrc eingelesen und Ihnen im Folgenden zur Auswahl dargestellt. 426 16.3. linuxrc Wenn Sie von CD gebootet haben oder von DOS aus mittels loadlin nach- gestartet haben, stehen die Module bereits alle linuxrc zur Verfügung. Dies erspart das langwierige Laden, braucht dafür jedoch mehr Speicher. Hat Ihr Rechner weniger als 8 MB RAM, müssen Sie von Diskette booten. Abbildung 16.2: Module laden linuxrc bietet Ihnen die verfügbaren Treiber in einer Liste an. Links sehen Sie den Namen des zuständigen Moduls, rechts eine Kurzbeschreibung der Hardware, für die der Treiber zuständig ist. Für einige Komponenten gibt es mitunter mehrere Treiber oder neuere Alpha- Treiber. Auch diese werden hier angeboten. Abbildung 16.3: Auswahl der SCSI-Treiber 427 16. Besonderheiten in SuSE Linux Parametereingabe Haben Sie den Treiber gefunden, der für Ihre Hardware zuständig ist, positio- nieren Sie den Cursor und drücken Sie . Es erscheint eine Maske, in der Sie etwaige Parameter für das zu ladende Modul eingeben können. Näheres zu den unterschiedlichen Modulparametern finden Sie in Abschnitt 14.3.4 auf Seite 377. Abbildung 16.4: Eingabe der Parameter für das Laden eines Moduls Hier sei nur noch einmal darauf hingewiesen, dass im Gegensatz zur Para- metereingabe am Kernel-Prompt (MILO, LILO oder SYSLINUX) mehre- re Parameter für das gleiche Modul durch Leerzeichen voneinander getrennt werden müssen. In vielen Fällen ist die genaue Spezifizierung der Hardware gar nicht not- wendig; die meisten Treiber finden Ihre Komponenten von alleine. Lediglich bei den Netzwerkkarten und bei älteren CD-ROM-Laufwerken mit eigener Controller-Karte ist die Angabe von Parametern mitunter erforderlich. Pro- bieren Sie es jedenfalls am einfachsten erst einmal mit . Bei einigen Modulen kann das Erkennen und Initialisieren der Hardware recht lange dauern. Durch Umschalten auf die virtuelle Konsole 4 ( Alt + F4 ) können Sie die Meldungen des Kernels während des Ladens beobachten. Vor allem SCSI-Adapter lassen sich etwas Zeit beim Ladevorgang, da sie auch eine gewisse Zeit warten, bis sich alle angeschlossenen Geräte gemeldet haben. Wurde das Modul erfolgreich geladen, werden die Meldungen des Kernels von linuxrc angezeigt, sodass Sie sich vergewissern können, dass alles wie vorgesehen gelaufen ist. Ansonsten erlauben die Meldungen möglicherweise, die Ursache für das Scheitern zu finden. 428 16.3. linuxrc System / Installation starten Haben Sie die komplette Kernel-Unterstützung für Ihre Hardware erreicht, so können Sie zum Punkt `System / Installation starten' weiter- gehen. Abbildung 16.5: Ziel von linuxrc Von hier aus (Abbildung 16.5 auf der nächsten Seite) lassen sich mehrere Vor- gänge anstoßen: `Installation starten' (über diesen Punkt wird auch das Update eingeleitet), `Installiertes System booten' (die Rootpartition muss bekannt sein), `Rettungssystem starten' (vgl. Abschnitt 16.5 auf Seite 432) und `Live-CD starten'3. Der Punkt `Live-CD starten' kann z. B. immer dann nützliche Dienste leisten, wenn man ohne eigentliche Festplatten-Installation testen möchte, ob der fragliche Rechner oder das anzuschaffende Notebook über- haupt mit SuSE Linux kompatibel ist ­ ein solcher Test sollte in jedem zeitgemäßen PC-Laden ohne Umstände möglich sein! Für die Installation (Abbildung 16.6 auf der vorherigen Seite) und ähnlich auch für das Rettungssystem können Sie verschiedene Quellen wählen (Ab- bildung 16.8 auf Seite 433). 3 Diese Live-CD ( Live-Filesystem") steht nur für x86er Architekturen zur Verfügung; vgl. Abschnitt 3.6.4 auf Seite 107. 429 16. Besonderheiten in SuSE Linux Abbildung 16.6: Auswahl des Quellmediums in linuxrc 16.4 Das Hilfesystem für SuSE Linux Das Hilfesystem ist komponenten-orientiert aufgebaut und kann über be- liebige Webbrowser abgefragt werden (unter der grafischen Oberfläche vgl. oben Abbildung 1.1 auf Seite 8 bzw. auf der Text-Konsole vgl. hier Abbil- dung 16.7) ­ wenn Sie wollen, sogar netzweit. Der zentrale Baustein des Systems befindet sich in Paket susehilf, Serie doc (Dokumentation). Je nach gewünschtem Umfang bzw. nach erforderli- cher Funktionalität sind weiter die folgenden Pakete zu installieren (zum Vor- gang der Installation vgl. Abschnitt 3.4.3 auf Seite 94). Die essentiell wichti- gen Pakete werden automatisch installiert, wenn Sie die Standard-Installation von YaST aus durchführen ­ also bitte keine Panik, falls Sie für den Moment den Überblick zu verlieren scheinen ;-) Abbildung 16.7: Startseite des Hilfesystems (lynx) 430 16.4. Das Hilfesystem für SuSE Linux Paket apache, Serie n: Apache, der lokale WWW-Server. Paket sdb, Serie doc: Das Grundpaket mit der Suchfunktionalität für die SDB. Paket sdb_de, Serie doc: Die Texte der Support-Datenbank (SDB), deutschsprachig. Paket susepak, Serie doc: Falls Sie die Paket-Beschreibungen einmal in Ruhe studieren möchten ... Paket howtodeh, Serie doc: Die Howto-Dokumente, deutschsprachig. Paket howtoenh, Serie doc: Die Howto-Dokumente, englische Version (in der Regel natürlich aktueller als die Übersetzungen). Paket ldp, Serie doc: Bücher, FAQs etc. des Linux Documentation Pro- ject (LDP) in HTML. Paket rman, Serie ap: Enthält http-rman. Paket inf2htm, Serie doc: Damit ist's möglich, die Info-Dokumente (vgl. Abschnitt 1.4.3 auf Seite 9) mit dem WWW-Browser zu lesen; die Dokumente werden on-the-fly" konvertiert. Paket dochost, Serie n: Eine Maschinerie für einen zentralen Dokumenten- Server im Netz. Bitte machen Sie sich mit /usr/doc/packages/ dochost/README.SuSE vertraut! Paket htdig, Serie n: Zum Erstellen eines Suchindex über alle WWW- Dokumente die auf dem Rechner (oder im lokalen Netz) installiert sind; der Rechner wird zu einer kleinen Web-Suchmaschine. Paket dochost und Paket htdig sind nicht zwingend erforderlich, aber um volle Funktionalität zu erlangen, sind diese Pakete schon sehr nützlich. 16.4.1 Konfiguration für Einzelplatz bzw. Serversystem Setzen Sie in /etc/rc.config die Variablen für ein Einzelplatzsystem wie in Datei 16.4.1 aufgelistet (am besten mit YaST, wie in Abschnitt 3.6.12 auf Seite 114 und speziell auf Seite 452 erklärt). Dies setzt natürlich voraus, dass Ihr System sonne.kosmos.all heißt; andernfalls müssen Sie die von Ihnen vergebenen Namen verwenden. START_INETD="yes" START_HTTPD="yes" DOC_SERVER="yes" DOC_HOST="sonne.kosmos.all " DOC_ALLOW="LOCAL .kosmos.all " Datei 16.4.1: /etc/rc.config für Einzelplatz bzw. Serversystem Der inetd (engl. inet daemon) sollte in jedem Fall gestartet werden; dieser Daemon wird u. a. für den Zugriff auf Manpages via http-rman benö- tigt. http-rman kann natürlich nur dann funktionieren, wenn dieser Dienst in /etc/hosts.deny nicht abgeschaltet ist. Sorgen Sie dafür, dass der HTTP-Server (apache) beim Booten gestartet wird; dafür ist START_HTTPD auf yes zu setzen. 431 16. Besonderheiten in SuSE Linux DOC_SERVER legt fest, ob von diesem Rechner die Dokumente zur Verfü- gung gestellt werden sollen; diese Variable muss auch dann auf yes gesetzt werden, wenn man ­ wie z. B. im Falle eines Einzelplatzsystems ­ lokalen Zugriff auf die Dokumente haben möchte. DOC_HOST gibt den Namen den Dokumentenservers an (hier: sonne.kosmos.all). DOC_ALLOW ist eine sicherheitsrelevante Einstellung; dort sind die Rechner bzw. Domains einzu- tragen, denen Zugriff auf die Manpages gestattet werden soll. Wenn Sie den Zugriff für eine komplette Domain freigeben wollen, vergessen Sie nicht den führenden Punkt `.' vor dem Namen! Beachten Sie, dass nach jeder Änderung der Variablen SuSEconfig lau- fen muss; wenn Sie mit YaST arbeiten, geschieht dies beim Verlassen der Maske automatisch. Die Volltextsuche ist erst verfügbar, wenn die Indizes für ht://Dig (Pa- ket htdig) erzeugt sind. Die Indizes sind z. Z. ca. 70 MB groß. Un- ter /opt/www/htdig sollten während der Initialisierung der Datenbank mindestens 200 MB freier Plattenplatz vorhanden sein. Die Initialisierung geschieht durch die Eingabe von: erde:~ # suserundig Das Skript /usr/sbin/suserundig wertet die Konfigurationsdatei /opt/www/htdig/conf/susedig.conf aus und legt die Indizes an. Treten Veränderungen des Datenbestands ein (z. B. nach dem Update der HTML-Dokumente), dann muss suserundig erneut aufgerufen werden. 16.4.2 Konfiguration für einen Client-Rechner In einer vernetzen Umgebung möchten Sie möglicherweise nicht auf allen Rechnern die komplette Dokumentation installieren; brauchen Sie auch nicht! Installieren Sie von all den oben genannten Paketen auf dem Client nur das Paket dochost, Serie n und setzen Sie in /etc/rc.config die Variablen wie in Datei 16.4.2. DOC_SERVER="no" DOC_HOST="sonne.kosmos.all" DOC_ALLOW="" Datei 16.4.2: /etc/rc.config für einen Client-Rechner Dies kann natürlich nur dann funktionieren, wenn Dokumentation tatsächlich auf sonne.kosmos.all installiert ist! 16.4.3 Das Hilfesystem benutzen Wenn das Hilfesystem ­ wie oben beschrieben ­ installiert ist, können Sie es entweder mit dem Befehl hilfe oder susehelp aufrufen. Oder Sie ge- ben direkt in einem WWW-Browser die URL http://localhost/doc/ susehilf/index.html oder http://sonne.kosmos.all/doc/ susehilf/index.html ein; sonne.kosmos.all funktioniert natür- lich nur, wenn Sie Ihren Rechner bzw. den Dokumentenserver so genannt haben. 432 16.5. Das SuSE Rettungssystem 16.5 Das SuSE Rettungssystem Überblick SuSE Linux enthält ­ unabhängig vom Installations-System ­ ein selbstän- diges Linux-Rettungssystem4, mit dem Sie in Notfällen von außen" an alle Ihre Linux-Partitionen auf den Festplatten wieder herankommen. Bestandteil des Rettungssystems ist eine sorgfältige Auswahl von Hilfsprogrammen, mit denen Sie genügend Werkzeug zur Verfügung haben, um eine Vielzahl von Problemen mit unzugänglich gewordenen Festplatten, fehlerhaften Konfigu- rationsdateien usw. zu beheben. Das Rettungssystem besteht aus einer Bootdiskette bzw. einer bootbaren SuSE Linux-CD sowie einem Rescue"-System, das sich bei SuSE Linux von ganz unterschiedlichen Medien (Diskette, CD, aus dem Netz, ja sogar di- rekt vom SuSE-FTP-Server) nachladen lässt. ­ Alles in allem eine spannende Angelegenheit. Vorabeiten Da Sie die Bootdiskette jederzeit anhand der richtigen Abbilddatei auf der CD unter /disks neu erzeugen können, bildet es eine recht sichere Rückende- ckung. Neben der Bootdiskette wird von der CD im Minimalfall lediglich die Datei /disks/rescue benötigt, die das komprimierte Abbild eines klei- nen Root-Dateisystems enthält. Wenn Sie diese Datei mit den Linux-Befehlen erde: # /sbin/badblocks -v /dev/fd0 1440 erde: # dd if=/cdrom/disks/rescue of=/dev/fd0 bs=18k oder mit dem DOS-Befehl (angenommen, Q: ist unter DOS das CD-ROM- Laufwerk) Q:\> cd \dosutils\rawrite Q:\dosutils\rawrite> rawrite.exe auf eine zweite fehlerfreie Rettungs"-Diskette schreiben, können Sie das Rettungssystem auch von der Bootdiskette und dieser Rettungsdiskette laden; die Rettungsdiskette lässt sich auch mit YaST erstellen (vgl. Abschnitt 3.6.2 auf Seite 103). Die Rettungsdiskette basiert z. Z. noch bewusst auf der libc5 (SuSE Linux 5.3); nur so ist es möglich, einige Programme auf der Diskette unterzubringen (einen Editor, fdisk, e2fsck etc.) ­ die glibc wäre von der Größe her zu umfangreich. Die Rettungsdiskette lässt sich übrigens nicht mounten, da sie ja kein Datei- system, sondern nur das komprimierte Abbild eines solchen enthält (das un- komprimierte Abbild wäre mit etwa 3 MB für eine Diskette zu groß). Wenn Sie trotzdem einmal hineinschauen wollen, müssen Sie die Abbilddatei de- komprimieren und dann das unkomprimierte Abbild (als Benutzer `root') mounten. Dies setzt voraus, dass Ihr Linux-Kernel das loop-Device unter- stützt und geht dann wie folgt: erde: # cp /cdrom/disks/rescue /root/rescue.gz erde: # gunzip /root/rescue.gz erde: # mount -t ext2 -o loop /root/rescue /mnt 4 Genaugenommen sind es mittlerweile 2 Stück (weiter unten dazu mehr) ­ oder gar 3 Stück, falls man geneigt ist, das startbare Live-Filesystem" auch als ein Rettungssystem zu betrachten; zum Live-Filesystem vgl. Abschnitt 3.6.4 auf Seite 107. 433 16. Besonderheiten in SuSE Linux Unter /mnt können Sie nun den Inhalt des Rettungssystems in aller Ruhe durchforsten. Halten Sie einige geprüfte Boot- und Rettungsdisketten an sicheren Orten bereit. Der geringe Aufwand für Erzeugung und Pflege steht in keinem Verhältnis zu der Arbeit und dem Zeitverlust, wenn Sie im Notfall keine zur Hand haben (und Sie dann etwa auch noch das CD-ROM-Laufwerk im Stich lässt). Rettungssystem starten Das Rettungssystem wird wie eine Installation von der SuSE-Bootdiskette bzw. der bootbaren CD 1 gestartet. Die Schritte im Einzelnen: 1. Voraussetzung: das Disketten- bzw. CD-ROM-Laufwerk ist bootfähig (nötigenfalls muss man im CMOS-Setup die Boot-Reihenfolge ändern). 2. System mit der SuSE-Bootdiskette bzw. der CD 1 starten. Geben Sie am Bootprompt entweder yast1 oder manual; bei manual haben Sie die Möglichkeit, selbständig die notwendigen Kernel-Module zu laden. 3. Sprache, Tastatur usw. wie bei der Installation im linuxrc einstellen, bis Sie beim Hauptmenü angelangt sind. 4. Wählen Sie im Hauptmenü `Installation/System starten'. 5. Wenn Sie mit der Bootdiskette gestartet haben, legen Sie nun die Instal- lations-CD oder die Diskette (rescue) mit dem komprimierten Abbild des Rettungssystems ein. Abbildung 16.8: Quellmedium für das rescue-System 6. Wählen Sie im Menü `Installation/System starten' den Punkt `Rettungssystem starten' (vgl. Abbildung 16.5 auf Sei- te 427) und geben Sie dann das gewünschte Quellmedium an (Abbil- dung 16.8): `CD-ROM': Dies ist der Normalfall". linuxrc wird ein komfortables System laden (.../suse/images/rescue). Um diesen Weg be- schreiten zu können, muss der Rechner über mindestens 16 MB RAM 434 16.5. Das SuSE Rettungssystem (Arbeitsspeicher), besser 24 MB verfügen. ­ Übrigens, gleichzeitig wird /cdrom exportiert; so ist es also möglich, das Rettungssystem bequem zu starten und dann von dieser CD aus eine Netz-Installation durchzuführen (die notwendigen /etc/rc.config mit den rich- tigen Werten versorgen und dann SuSEconfig aufrufen; vgl. Ab- schnitt 17.5 auf Seite 444 ff.). `Netzwerk (NFS)': rescue-System via NFS aus dem Netz holen; dazu ist es natürlich erforderlich, dass Sie den Treiber für Ihre Netz- werkkarte zuvor geladen haben ; vgl. dazu auch die allgemeinen Hin- weise in Abschnitt 2.4.2 auf Seite 48. `Netzwerk (FTP)': rescue-System via FTP aus dem Netz holen; Netzwerkkartentreiber nicht vergessen! `Festplatte': rescue-System von Festplatte laden. `Diskette': rescue-System von der wie oben beschriebenen Dis- kette starten; diese Variante funktioniert auch dann, wenn der Rechner nur über wenig RAM verfügt. Das Rettungssystem wird nun dekomprimiert und als neues Root-Dateisys- tem in eine RAM-Disk geladen, gemountet und gestartet. Es ist damit be- triebsbereit. Mit dem Rettungssystem arbeiten Das Rettungssystem stellt Ihnen unter Alt + F1 bis Alt + F3 mindes- tens drei virtuelle Konsolen zur Verfügung, an denen Sie sich als Benutzer `root' ohne Passwort einloggen können. Mit Alt + F10 kommen Sie zur Systemkonsole mit den Meldungen von Kernel und syslog. Unter /bin finden Sie die Shell und Utilities (z. B. mount); eine Anzahl wichtiger Datei- und Netz-Utilities, unter anderem e2fsck zum Überprüfen und Reparieren von Dateisystemen liegen unter /sbin. In /sbin liegen auch die wichtigsten Binaries für die Systemverwaltung wie fdisk, mkfs, mkswap, init, shutdown, sowie für den Netzwerkbetrieb ifconfig, route und netstat. Als Editor ist der vi unter /usr/bin verfügbar; hier sind auch weitere Tools (grep, find, less etc.) und vor allen Dingen auch telnet zu finden. Beispiel: Zugriff auf das normale System Zum Mounten Ihres Linux-Systems auf der Platte ist der Mountpoint /mnt gedacht; Sie können natürlich für eigene Zwecke weitere Verzeichnisse er- zeugen und als Mountpoints verwenden. Nehmen wir als Beispiel einmal an, Ihr normales System setzt sich laut /etc/fstab zusammen wie im Beispiel Datei 16.5.1. /dev/sdb5 swap swap defaults 0 0 /dev/sdb3 / ext2 defaults 1 1 /dev/sdb6 /usr ext2 defaults 1 2 Datei 16.5.1: Beispiel: /etc/fstab 435 16. Besonderheiten in SuSE Linux Dann mounten Sie es Schritt für Schritt unter /mnt mit den folgenden Be- fehlen (Reihenfolge beachten!): erde:/ # mount /dev/sdb3 /mnt erde:/ # mount /dev/sdb6 /mnt/usr Nun haben Sie Zugriff auf Ihr ganzes System und können z. B. Fehler in Kon- figurationsdateien wie /etc/fstab, /etc/passwd, /etc/inittab ­ die jetzt natürlich unter /mnt/etc statt /etc liegen! ­ bereinigen. Jeder erfahrene Linux-Benutzer nimmt bei frühester Gelegenheit einen Aus- druck (Hardcopy) von /etc/fstab und dem Output des Befehls erde: # fdisk -l /dev/ zu den Akten"; anstelle von setzen Sie bitte der Reihe nach die Devicenamen Ihrer Festplatten ein, z. B. hda (vgl. die Aufstellung in Ab- schnitt D.1 auf Seite 521). Selbst komplette verlorene Partitionen lassen sich mit Linux fdisk oft einfach wieder durch Neu-Anlegen zurückgewinnen, wenn genau bekannt ist, wo die Partitionen vorher auf der Festplatte waren. Beispiel: Dateisysteme reparieren Beschädigte Dateisysteme sind ein besonders ernster Anlass für den Griff zum Rettungssystem. Dies kann z. B. nach einem unsauberen Shutdown (wie bei Stromausfall) oder einem Systemabsturz vorkommen. Dateisyste- me lassen sich grundsätzlich nicht im laufenden Normalbetrieb reparieren. Bei schwereren Schäden lässt sich unter Umständen nicht einmal das Root- Dateisystem mehr mounten und der Systemstart endet in einer "kernel panic". Da bleibt nur der Weg, die Reparatur von außen" unter einem Rettungssystem zu versuchen. Im SuSE Linux-Rettungssystem sind die Utilities e2fsck und, für die Diagno- se, dumpe2fs enthalten. Damit können Sie mit den meisten Problemen fertig werden. Da im Notfall meist auch die Manual-Page von e2fsck nicht mehr zugänglich ist, ist sie in Anhang E auf Seite 527, ausgedruckt. Beispiel: Wenn sich ein Dateisystem wegen eines ungültigen Super- blocks nicht mehr mounten lässt, wird e2fsck vermutlich zunächst eben- falls scheitern. Die Lösung ist, eines der Superblock-Backups zu verwenden, die im Dateisystem alle 8192 Blöcke (8193, 16385 ... ) angelegt sind und gepflegt werden. Dies leistet z. B. der Befehl erde: # e2fsck -f -b 8193 /dev/ Die Option -f erzwingt den Dateisystem-Check unbedingt und kommt damit dem möglichen Irrtum von e2fsck zuvor, es sei ­ angesichts der intakten Superblock-Kopie ­ alles in Ordnung. 16.6 Hinweise zu speziellen Softwarepaketen 16.6.1 Paket cron Die cron-Tabellen liegen unter /var/cron/tabs (und nicht mehr un- ter /var/lib/cron). Als systemweite Tabelle wird die Datei /etc/ crontab eingerichtet. In der Datei /etc/crontab muss zusätzlich nach 436 16.6. Hinweise zu speziellen Softwarepaketen der Zeitangabe eingetragen werden, unter welchem User der jeweilige Auf- trag ausgeführt werden soll (vgl. Datei 16.6.1 auf der nächsten Seite, dort ist `root' angegeben); dem gleichen Format folgen paket-spezifische Tabellen, die in /etc/cron.d liegen ­ vgl. Manual-Page von cron (man 8 cron). 1-59/5 * * * * root test -x /usr/sbin/atrun && /usr/sbin/atrun Datei 16.6.1: Beispiel eines Eintrags in /etc/crontab /etc/crontab kann nicht mit crontab -e bearbeitet werden, sondern muss direkt in einen Editor geladen, verändert und schließlich gespeichert werden. Einige Pakete installieren in den Verzeichnissen /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly Shellskripten, deren Abarbeitung von /usr/lib/cron/run-crons ge- steuert wird. /usr/lib/cron/run-crons wird alle 15 Minuten von der Haupt-Tabelle (/etc/contrab) aufgerufen; so wird sichergestellt, dass eventuell versäumte Läufe rechtzeitig nachgeholt werden. Wundern Sie sich also bitte nicht, wenn kurz nach dem Booten der Benutzer `nobody' in der Prozess-Tabelle mit regen Aktivitäten auftaucht; `nobody' aktualisiert wahrscheinlich dann gerade die locate-Datenbank (vgl. Abschnitt 17.6 auf Seite 454). 16.6.2 Paket curses Auf der CD befindet sich nun das Paket ncurses. Die zugehörigen Biblio- theken haben den Namen libncurses.so.. Dies hat zur Folge, dass in vielen Makefiles die Anweisungen für den Linker geändert werden müssen. Man sollte also eigene Pakete mit -lncurses übersetzen und nie mit -lcurses. Wer das dennoch will, der muss -I/usr/include/termcap -I/usr/include/curses -L/usr/lib/termcap -L/usr/lib/curses verwenden. 16.6.3 Quellen zum Paket uucp Die Quellen zum Paket uucp sind z. Z. in dem Source-RPM von Sendmail als Unterpaket enthalten. 16.6.4 Manual-Pages Für einige GNU-Programmen (z. B. tar) werden die Manual-Pages nicht mehr weitergepflegt. An ihre Stelle treten als Schnellübersicht die --help- Ausgabe und als ausführliche Manuals die Info-Dateien. Info (info) ist GNUs Hypertext-System. Mit info info erhält man erste Hilfe zur Benut- zung. info kann entweder über Emacs emacs -f info aufgerufen wer- den, oder standalone: info. Angenehm zu bedienen sind tkinfo, xinfo oder der Zugriff über das Hilfesystem; vgl. Abschnitt 16.4 auf Seite 429. 437 16. Besonderheiten in SuSE Linux 16.7 Tastaturbelegung Um die Tastaturbelegung von Programmen zu vereinheitlichen, wurden Än- derungen an den folgenden Dateien vorgenommen: /etc/inputrc /usr/X11R6/lib/X11/Xmodmap /etc/skel/.Xmodmap /etc/skel/.exrc /etc/skel/.less /etc/skel/.lesskey /etc/csh.cshrc /etc/termcap /usr/lib/terminfo/x/xterm /usr/X11R6/lib/X11/app-defaults/XTerm /usr/share/emacs/20.5/site-lisp/term/*.el /usr/lib/joerc Diese Änderungen wirken sich nur auf die Applikationen aus, welche die terminfo-Einträge auslesen, bzw. deren Konfigurationsdateien direkt ver- ändert wurden (vi, less etc.). Andere, nicht-SuSE-Applikationen sollten an diese Vorgaben angepasst werden. 438