Kai-Hildebrandt.de - GNU/Linux

Installation & Konfiguration

Einleitung

Im Folgenden ein paar Tipps und Hinweise zur Planung und Installation eines Linux-Systems.

Hierbei handelt es sich lediglich um Kurztipps und selbst in der Summe soll dies keine komplette Anleitung sein. Dieser Anspruch würde schon an der Vielzahl der Distributionen scheitern, die normalerweise eine spezifische Installationsanleitung mitliefern, nach der man vorgehen kann. Bei vielen Distributionen ist die Installation auch schon so einfach, dass man sein System ohne größere Umstände installiert bekommt. Leider kommt dabei aber selten ein ideal konfiguriertes System heraus. :-S

Genau diesen Punkt möchte ich hier aufgreifen und die Gedanken beschreiben, die man sich vor dem Einschieben des Installationsmediums machen sollte. Diese Anleitungen sollten sich auf verschiedene gängige Distributionen anwenden lassen.

« zurück (Gesammelte Anleitungen)

Partitionieren und Mounten

Als absolutes Minimum sind eine Root-Partition (eingehängt unter / als oben liegende Wurzel des Dateisystems) und eine Swap-Partition notwendig.

Swap-Partitionen und deren Nutzung

Die Swap-Partition dient einerseits zum Auslagern länger nicht angeforderter Speicherseiten auf die Festplatte und, je nach Konfiguration, als Speicherort für das Speicherabbild bei suspend-to-disk. Bei den neueren Linux-Kerneln gibt es eine weitere Neuerung, die den Swapspeicher nutzt: tmpfs.

Dieses spezielle Dateisystem nutzt einen Teil des Arbeitsspeichers als Ramdisk und ist somit sehr performant. Es kann aber auch wie gewöhnliche Speicherseiten in den Swapbereich ausgelagert werden. Der Inhalt einer Ramdisk geht bei einer abrupten Stromunterbrechnung verloren, wenn man keine USV (oder einen Notebookakku) hat. Das Dateisystem tmpfs findet unter anderem für den Gerätedateibaum unterhalb des Verzeichnisses /dev bei udev Verwendung.

Für diese beschriebenen Funktionen (suspend-to-disk, tmpfs) sollte die Größe der Swap-Partition mit mindestens der doppelten Größe des vorhandenen Hauptspeichers bemessen werden.

Wenn man keine Swap-Partition anlegt, kann es schonmal zu seltsamem Verhalten führen, wenn der gesammte physikalische Speicher belegt ist. Dann werden gezielt Prozesse beendet, um Speicher freizugeben. Das Gleiche passiert natürlich auch, wenn der komplette virtuelle Speicher (also physikalisches RAM und Swapspeicher) vollgelaufen sind. Ein solches Verhalten zeugt entweder von Fehlplanung der Resourcen des Systems (sprich: zu wenig eingebautem Speicher) oder einem Software- oder Konfigurationsfehler.

Weitere Partitionen und deren Mountpoints

Das Root-Dateisystem ist als Einstiegspunkt natürlich zwingend erforderlich. Die Swap-Partition sollte wie soeben beschrieben auch immer in der richtigen Größe vorhanden sein. Damit wäre das System ohne Weiteres lauffähig, es wäre aber alles andere als ideal. Deshalb folgt hier eine kleine Auflistung, welche Teile des Dateisystembaums man auf separate Partitionen (bzw. Festplatten) auslagern sollte und warum man das tun sollte.

Weitere Vorüberlegung

Jede weitere Partition kostet unwiderbringlich Festplattenplatz und zwar nicht aufgrund der Verwaltungsinformationen, sondern weil man keine Partition zu 100% mit Daten belegen kann. Man hat also Verschnitt, der mit jeder weiteren angelegten Partition anwächst. Wird einer der genannten Mountpoints nicht auf eine separate Partition oder Festplatte ausgelagert, befinden sich die Dateien und Verzeichnisse unterhalb des Root-Dateisystems.

Das Ziel soll sein, soviele Partitionen wie nötig und so wenige wie möglich anzulegen. Die folgende Liste soll bei der Entscheidung helfen, ob eine Auslagerung eines Verzeichnisses auf eine separate Partitionen notwendig ist.

/boot
Diese Partition beherbergt alle Dateien, die für den Bootvorgang notwendig sind. Unter anderem liegen hier die Kerneldateien und die Konfigurationsdateien von GRUB. Zu Zeiten, in denen nur LiLo zum Laden des Kernels verwendet wurde, hat man diese erste Partition mit ca. 100 MB angelegt. Damit blieb die Kernelposition unterhalb der 1024-Zylinder-Grenze der Festplatte, die der alte LiLo ansprechen konnte. Ohne diese Partition wäre das System nicht bootfähig gewesen.

Heutezutage wird diese Partition aufgrund eines Bugs im Dateisystem XFS interessant, da bei der Verwendung von GRUB auf einer XFS-Partition, es zu der etwas irreführende Fehlermeldung führt:

Due to a bug in xfs_freeze, the following command might produce a segmentation fault when /boot/grub is not in an XFS filesystem. This error is harmless and can be ignored.

Die Fehlermeldung kann man schon ignorieren, aber die Installation von GRUB bleibt an dieser Stelle hängen, wenn das Verzeichnis /boot/grub auf einer XFS-Partition liegt. Wenn man das Root-Dateisystem mit XFS angelegt hat, muss man also eine /boot-Partition anlegen, die mit einem anderen Dateisystem (z. B. ext2) formatiert ist, sonst kann GRUB nicht installiert werden.

Alternativ kann man auch LiLo verwenden, wie es der debian-Installer in einem solchen Fall macht.

Die Auslagerung von /boot auf eine gesonderte Partition ist also nicht mehr erforderlich, es sei denn, man will XFS als Dateisystem für sein Root-Dateisystem verwenden oder hat nur den alten LiLo als Bootloader zur Verfügung.
/home
Unterhalb dieses Verzeichnisses liegen die Heimverzeichnisse für alle auf dem System arbeitenden Benutzer. Im Falle eines Serversystems kann es durchaus sein, dass diese Daten über das Netz von einem anderen Server eingebunden werden (z. B. via NFS). Falls dies nicht der Fall ist, und auf dem verwendeten System sich normale Benutzer einloggen können, sollte man dieses Verzeichnis auf eine eigene Partition oder besser eine eigene Festplatte auslagern.

Die Vorteile der Auslagerung der Heimverzeichnisse sind:
- Normale Benutzer besitzen hier Schreibrechte, d. h. sie können das Dateisystem komplett vollschreiben ohne damit eine Anmeldung am System zu verhindern.
- Im Falle von Systemupdates kann diese Partition ungeändert übernommen werden, sämtliche Benutzerdaten und -einstellungen bleiben dabei erhalten. Selbst ein Wechsel der Distribution ist möglich.
Die Größe dieser Partition kann gar nicht groß genug sein. Hier liegen sämtliche Daten der Benutzer, also Dokumente, Audio- und Video-Dateien, Bilder usw. Wenn man an Festplattenplatz spart, dann nicht hier!
/var
Unterhalb der /var-Hierarchie befinden sich alle variablen Daten des Systems und den installierten Anwendungen. Dazu zählen z. B. die Mailboxen der Benutzer und allerhand zwischengespeicherter Informationen (bei debian: APT).

Außerdem befindet sich hier das für alle Benutzer schreibbare temporäre Verzeichnis /var/tmp. Für diese Partition muss Schreibzugriff eingeräumt werden und es dürfen alle am System angemeldeten Benutzer Daten ablegen. Damit besteht hier wieder die Gefahr, das System durch ein Vollaufen des Root-Dateibaums zu blockieren. Das kann durch das Auslagern des /var-Verzeichnisses auf eine eigene Partition verhindert werden.

Bei älteren, nicht LSB-konformen Linux-Systemen wurden auch Daten von Serverdiensten unterhalb von /var abgelegt. Hierfür ist jetzt das relativ junge /srv-Verzeichnis vorgesehen (zu /srv).

Bei einem debian-Systen sollte die Größe der /var-Partition mindestens das 1,5fache aller Daten unterhalb der /usr-Hierarchie abzüglich der Daten unterhalb des Verzeichnisses /usr/local entsprechen. Das hat den Grund, dass ein eventuelles Distributionsupgrade alle Softwarepakete für das Upgrade hier speichern können muss, ansonsten geht es schief.

Einen absoluten Wert festzulegen, ist hier nicht wirklich sinnvoll, dennoch ist eine Hausnummer mit Sicherheit hilfreich. Mein aktuelles Debiansystem "etch" hat ca. 5 GB Daten unterhalb von /usr, also ist eine /var-Partition mit ca. 10 GB eine gute Wahl.
/tmp
Und wieder die Problematik mit dem Vollschreiben der Root-Partition, denn unterhalb dieses Verzeichnisses besitzt wieder jeder angemeldete Benutzer Schreibrechte. Man kann dieses Verzeichnis natürlich auch auf eine eigene Partition auslagern, es gibt aber auch platzsparendere Wege.

Zwei Möglichkeiten werden unter Spezialfall /tmp vorgestellt.
/usr
Unterhalb dieses Verzeichnisses befinden sich keine Benutzerdaten, wie die Abkürzung vermuten lassen könnte. Hinter USR verbirgt sich UNIX System Resource, also handelt es sich um das Systemverzeichnis und zwar die unveränderlichen Programme und Daten. Unterhalb des /usr-Verzeichnisses ist während des Normalbetriebs kein Schreibzugriff notwendig, so dass man diese Partition auch schreibgeschützt einhängen kann. Falls man neue Softwarepakete einspielt, muss man die Partition natürlich erneut zum Schreiben einhängen und das funktioniert, indem man einen Remount durchführt:
```
# mount -o rw,remount /usr
```
Auf schreibgeschützt eingehängte Medien kann auch der Superuser root nicht schreiben, somit können keine Daten oder Programme auf dieser Partition aus Versehen gelöscht oder verändert werden. Das ist zwar nett, ist aber nicht essentiell notwendig und macht die eine oder andere Verwaltungsaufgabe etwas unbequemer.

Auf einem Server kann es durchaus sinnvoll sein, das /usr-Verzeichnis auf eine eigene Partition zu legen, auf einem Arbeitsplatzrechner sollte man lieber ein bisschen mehr Platz für das Root-Dateisystem vergeben. Da unterhalb von /usr nicht geschrieben wird und Benutzer darauf keine Schreibrechte besitzen, ist das nicht weiter schlimm.
/usr/local
Eine kleine Untermenge von /usr bildet das Unterverzeichnis /usr/local, in dem manuell installierte (GNU-)Programme abgelegt werden. Die Dateisystemhierarchie unterhalb dieses Verzeichnisses entspricht der direkt unterhalb von /usr, es werden hier jedoch nie distributionsspezifische Programme oder Dateien angelegt, so dass es keine Konflikte bei gleichen Programmpaketen geben kann.

Auch unterhalb von /usr/local sollte bei Normalbetrieb kein Schreibzugriff notwendig sein, variable Daten sollte man unterhalb von /var/local anlegen lassen, indem man die selbst installierten Programme entsprechend konfiguriert.

Ein Auslagern auf eine separate Partition kann sinnvoll sein, wenn man einer bestimmten Benutzergruppe das Installieren selbst erstellter Programme erlauben will, die /usr-Partition aber mit Schreibschutz eingehängt ist.

Da dies auf Servern eher ein Risiko darstellt und als Arbeitsstation keine wirkliche Anwendung ist, braucht man dieses Verzeichnis auch nicht auslagern. Dann doch lieber wieder dem Root-Dateisystem oder der /usr-Partition, falls diese ausgelagert ist, etwas mehr Festplattenplatz spendieren.
/opt
Unterhalb dieses Verzeichnisses befinden sich optionale Softwarepakete. Die komplette Programm- und Datendateien eines solchen Pakets liegen gekapselt innerhalb eines während der Installation angelegten Verzeichnisses. Diese Anwendungen sollten nie Daten außerhalb ihrer Verzeichnishierarchie erzeugen oder auf außerhalb liegende Dateien zugreifen.

Wenn man solche Softwarepakete benutzt (z. B. Entwicklungsumgebungen wie NetBeans oder Eclipse), kann man sich überlegen, /opt auf eine separate Partition auszulagern. Alternativ kann man auch wieder dem Root-Dateisystem mehr Platz spendieren, das aber dann wieder in Gefahr laufen könnte, durch die variablen Daten der verwendeten Anwendungen vollzulaufen.
/srv
Das jüngste der oben gelisteten Verzeichnisse ist für die Daten von laufenden Serveranwendungen gedacht, um deren Daten einen gesonderten Bereich zu spendieren.

Für den Heimgebrauch absolut unnötig, im Falle eines Serversystems ist die anfallende Datenmenge zu planen und diese Partition in jedem Fall auszulagern, da dort z. B. Webanwendungen Daten ablegen können.

Weiterführende Informationen zu den einzelnen Verzeichnissen gibt es beim LDP unter Linux Filesystem Hierarchy.

« nach oben

Spezialfall `/tmp`

Im Anschluss an die Planung für das Partitionieren kommen hier noch Konfigurationsmöglichkeiten bezüglich des temporären Verzeichnisses /tmp, das innerhalb des Root-Dateisystems liegt und somit ausgelagert werden sollte. Um keine weitere Partition für das meist nur mit Dateien im Kilobyte-Bereich belegte Dateisystem zu verschwenden, legt man es entweder als tmpfs an, oder man legt es mit /var/tmp zu einem einzigen temporären Verzeichnis zusammen.

`/tmp` als tmpfs

Die erste Möglichkeit ist es, tmpfs zu nutzen. Bei modernen Linuxsystemen wird ein Teil des physikalischen Speichers für tmpfs reserviert und unter anderem für udev bzw. das Geräteverzeichnis /dev verwendet. Man kann sich für das temporäre Verzeichnis einfach ein Stück Speicher (hier: 64MB) herausschneiden und diese als /tmp einhängen:

# Datei /etc/fstab

# /tmp als tmpfs einbinden
tmpfs   /tmp   tmpfs   rw,size=64M,mode=1777,nodev,nosuid,noexec   0   0

Damit ist nach 64MB das Verzeichnis voll und das Root-Dateisystem vor dem Überlaufen gerettet. :-)

Ferner sind hier noch die mount-Optionen nodev, nosuid und noexec angegeben, d. h. es dürfen keine Gerätedateien angelegt, keine SetUID-Bits für ausführbare Programme gesetzt werden und überhaupt keine Dateien ausgeführt werden. Letzteres kann bei manchen Install-Skripten zu Problemen führen und man muss z. B. die Umgebungsvariable TMPDIR anpassen.

`/tmp` und `/var/tmp` via Bind-Mount zu einem Verzeichnis vereinen

Wozu braucht man überhaupt zwei temporären Verzeichnisse? Man hat die /var-Partition ausgelagert und dort unterhalb von /var/tmp bereits ein temporäres Verzeichnis. Jetzt liegt natürlich nahe, das Verzeichnis /tmp ganz zu löschen und es als Symbolischen Link auf /var/tmp anzulegen, wie es z. B. unter Solaris gemacht wird (wurde?). Mit Linux geht das aber eleganter, vor allem, da ein Symbolischer Link eben eine Datei und kein Verzeichnis ist und sich auch nicht wie eines verhält.

Seit Linux 2.4.0 ist es möglich, Teile des Dateisystembaums an anderer Stelle einzuhängen, sogenannte Bind-Mounts. Diese Eigenschaft machen wir uns gleich zunutze:

# Datei /etc/fstab

# bind mount /var/tmp -> /tmp
/var/tmp   /tmp   none   rw,bind,nodev,nosuid,noexec   0   0

Die Funktion der verwendeten mount-Optionen wurden bereits weiter oben geklärt.

Jetzt entspricht der Inhalt von /tmp exakt dem von /var/tmp, denn es ist dasselbe Verzeichnis, wie ein df zeigt:

# mount | grep /tmp
/var/tmp on /tmp type none (rw,noexec,nosuid,nodev,bind)
# df -h /tmp/.
Dateisystem          Größe Benut  Verf Ben% Eingehängt auf
/dev/hda7             9,4G  1,2G  8,2G  13% /var

Damit liegt das Verzeichnis /tmp jetzt unterhalb von /var. Damit kann auch das Root-Dateisystem nicht mehr aufgrund eines überfüllten temporären Verzeichnisses vollaufen.

Normalerweise wird das /tmp-Verzeichnis beim Systemstart gelöscht, was damit jetzt auch /var/tmp betrifft. Da es sich bei diesen Verzeichnissen um Systemverzeichnisse handelt, sollte man dort als Benutzer sowieso keine Nutzdaten liegen haben, es sei denn man weiß, was man tut. ;-)