Technische Praxis der Computersysteme Teil 1 - Universität Wien
Technische Praxis der Computersysteme Teil 1 - Universität Wien
Technische Praxis der Computersysteme Teil 1 - Universität Wien
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
9.1 Startup und Shutdown 9 KONFIGURATION<br />
werden können. Der Default-Master-Boot-Record hingegen liest nur die Partitionstabelle<br />
des Geräts ein und übergibt die Kontrolle an die aktive Partition, von dieser wird dann das<br />
entspechende System gebootet.<br />
Die Bootmanager verfügen über weitreichende Konfigurationsmöglichkeiten; so ist es<br />
möglich, den Zugriff (auch zu bestimmten Konfigurationen) über ein Passwort zu schützen,<br />
und das Verhalten beim Booten an<strong>der</strong>er Betriebssysteme zu beeinflussen. grub wird<br />
in dem (je nach Distribution an verschiedener Stelle zu findenden) Konfigurationsfile<br />
(grub/menu.lst) konfiguriert, lilo in lilo.conf. Wichtig ist es, daß <strong>der</strong> Bootmanager<br />
das Filesystem auf dem sich <strong>der</strong> zu ladende Betriebssystemkern befindet, verwenden kann<br />
(hier hat grub eindeutig die Oberhand), und es unter Umständen auch entsprechend dekomprimieren<br />
kann. Einzelheiten findet man in <strong>der</strong> Dokumentation <strong>der</strong> Bootmanager.<br />
Der Boot-Loa<strong>der</strong> beendet seine Arbeit mit dem Einlesen <strong>der</strong> gewählten Boot-Partition in<br />
den Speicher. Im Falle von Linux wird dabei <strong>der</strong> (komprimierte) Kernel (/boot/vmlinuz)<br />
geladen, entkomprimiert sich selbst und beginnt mit <strong>der</strong> Arbeit. Zunächst erkennt und<br />
initialisiert er die Hardware des Systems, schaltet die CPU in den Multitasking-Mode, startet<br />
(Low-Level) das Netzwerk und mountet die Rootpartition des Systems. Dann startet er<br />
die Mutter aller Prozesse init mit PID=1 sowie einige weiter spontane Prozesse. Danach<br />
startet <strong>der</strong> Kernel nie wie<strong>der</strong> einen Prozeß, son<strong>der</strong>n ist in <strong>der</strong> in Kapitel 2 beschriebenen<br />
Funktionsweise für das ”<br />
Management“ des Systems verantwortlich. Während des Bootens<br />
schreibt <strong>der</strong> Kernel Meldungen auf die Konsole, die über Erfolg o<strong>der</strong> Fehler Auskunft geben;<br />
diese können später (im laufenden Betrieb) mittels dmesg, o<strong>der</strong> in /var/log/messages,<br />
manchmal auch in /var/log/boot, erneut angesehen werden.<br />
Der weitere Startup-Fluß läuft somit über init. Dieser Prozeß liest zunächst das Konfigurationsfile<br />
/etc/inittab ein. Es wird das Default-Runlevel festgelegt, wobei unter Runlevel<br />
ein Betriebszustand des Systems verstanden wird, <strong>der</strong> jeweils eine bestimmte Funktionsweise<br />
definiert. Die Nummerierung <strong>der</strong> Runlevels kann von <strong>der</strong> Distribution abhängen; Im<br />
Falle von RedHat bedeutet Runlevel 3 normaler Multiuserbetrieb, Runlevel 5 Multiuserbetrieb<br />
mit grafischem Login, Runlevel 0 bzw. 6 ist <strong>der</strong> Shutdown bzw. Reboot und Runlevel<br />
1 ist <strong>der</strong> sogenannte Single User Mode, <strong>der</strong> dem Administrator den Betrieb des Systems<br />
ohne Multiuser-Umgebung ermöglicht; dieser wird vor allem bei grundlegenden Eingriffen<br />
in die Konfiguration des Systems verwendet, z.B. ist es sinnvoll, daß kein Benutzer einloggen<br />
kann, während root nach einem Festplattencrash die Benutzerdaten vom Backup auf<br />
eine neue Platte einspielt. Statt in den Default-Runlevel zu starten, kann man durch den<br />
Bootmanager auch in an<strong>der</strong>e Runlevel starten; übergibt man in den Kernel-Optionen ein<br />
single, so wird in den Single-User-Mode gestartet. Auch kann man das verwendete init<br />
überschreiben, zB durch init=/bin/bash (noch ein guter Grund, den Bootmanager durch<br />
ein Passwort zu schützen, ist aber für ein genügend ”<br />
zerschossenes“System manchmal die<br />
letzte Rettung).<br />
init startet alle für das gesetzte Runlevel in /etc/inittab vorgesehenen Programme<br />
und Systemdienste. Zunächst wird üblicherweise das für alle Runlevels vorgesehen Skript<br />
/etc/rc.sysinit o<strong>der</strong> /etc/rc.d/rc.sysinit abgearbeitet (Setzen des Hostnamens, Nis-<br />
Domainnames, Netzwerkkonfiguration, Festplattencheck, Mounten <strong>der</strong> lokalen Festplattenpartitionen,<br />
. . . ). Dann werden <strong>der</strong> Reihe nach die verschiedenen Systemdienste gestartet.<br />
Die meisten Linux-Systeme folgen hierbei dem System-V-Standard, <strong>der</strong> vorsieht, daß alle<br />
Dienste über eigene Scripts gestartet werden; diese befinden sich in /etc/rc.d/init.d/<br />
o<strong>der</strong> /etc/init.d/. In den Directories /etc/rc.d/rc?.d/ bzw. /etc/rc?.d/, wobei ”<br />
?“<br />
für die Nummer des Runlevels steht, befinden sich jeweils für die in diesem Runlevel zu<br />
aktivierenden Dienste Links auf die Scripts in /etc/(rc.d/)init.d/. Die Namen <strong>der</strong> Links<br />
lauten SnnDienst, wobei ”<br />
S“ für ”<br />
Start“ steht, die zweistellige Zahl ”<br />
nn“ die Reihenfolge<br />
festlegt und Dienst das jeweilige Programm meint, z.B.<br />
$ ls -l /etc/rc.d/rc3.d<br />
S30sendmail -> ../init.d/sendmail<br />
K35atalk -> ../init.d/atalk<br />
Analog dazu werden die Dienste beim Verlassen des entsprechenden Runlevels mit Links<br />
<strong>der</strong> Form KnnDienst gestoppt. Die einzelnen Systemdienste und wie man sie in verschie-<br />
137