Booten und Konfiguration im Netz

Übersicht

BOOTP

Sowie im Linuxumfeld bootpd und dhcpd als Bootp-Server geeignet sind, existieren auf Clientseite mehrere Programme, die Bootp-Anfragen stellen können. Bezogen auf ihre Verbreitung reduziert sich die Auswahl auf bootpc, das im selben Paket enthalten ist, wie der Daemon bootpd und auf pump, das die RedHat-basierten Distributionen zur Verfügung stellen. RedHat beschreitet den Weg, die Bootp-Anfragen durch den DHCP-Server abhandeln zu lassen, vielleicht resultiert hieraus die Verwendung eines eigenen Clientprogramms.

Testlauf mit bootptest

bootptest ist im Umfang des bootp-Pakets enthalten und zumindest bei der Suche nach Fehlern recht nützlich. Das Kommando sendet in Sekundenabständen BOOTPREQUESTS an einen angegebenen Server und gibt dessen Antwort - falls sie eintraf - aus. Das Programm setzt allerdings bereits eine eingerichtete Netzwerkverbindung voraus, zwar ist es möglich mit der Option -h eine Anforderung auf Basis der Hardwareadresse abzusenden, jedoch antwortet der Server nicht von Haus aus mit einem Broadcast, sondern mit einem an die IP des Clients gerichteten Paket. Ist die Schnittstelle des Clients allerdings noch nicht auf diese Adresse konfiguriert, wird der Kernel das Paket ablehnen.

bootptest hilft letztlich nur, um die Verfügbarkeit eines Bootp-Servers zu testen:

Der Client bootpc

Bevor wir uns der notwendigen Vorarbeit widmen, sollen die wichtigsten Optionen des Kommandos genannt werden.

Der typische Zeitpunkt der Anwendung von bootpc ist im Verlauf des Bootvorgangs des Rechners. Häufigstens Ansinnen wird wohl der Bezug einer IP-Adresse von einem Server sein, was allerdings ein eingerichtetes Netzwerk bedingt. Der logische erste Schritt wird somit die Konfiguration der Netzwerkkarte sein. Hierfür benötigen wir jedoch eine IP-Adresse, die wir noch nicht kennen (können) - sonst müssten wir sie nicht erst anfordern...

Willkürlich eine IP-Adresse zu wählen kann scheitern, falls diese sich mit einer existierenden überschneidet. Sicherer ist daher die Wahl einer »ungütigen« IP-Adresse wie "0.0.0.0". Tatsächlich gibt sich ifconfig damit zufrieden:

Das Symbol eth0 im Beispiel bezieht sich auf eine Ethernet-Karte und kann verwendet werden, wenn die Karte entweder fest im Kernel eingebunden ist oder aber in der Datei /etc/modules.conf ein Alias unter dem Namen auf das tatsächliche Device existiert.

Wenn bootpc nun einen Broadcast aussendet, dann muss der Kernel wissen, wohin er dieses zu senden hat. Er benötigt in seiner IP-Routing-Tabelle einen Eintrag, der Pakete mit »unbekannten« Adressen an ein Device leitet. Für unser Beispiel heißt das, dass alle Pakete mit unbekanntem Empfänger an das Device eth0 zu senden sind:

Schließlich können die Parameter angefordert werden. Unbedingt erforderlich ist die Option --serverbcast, um dem antwortenden Bootp-Server mitzuteilen, er solle sein Paket doch als Broadcast senden und nicht an die dem Client zugedachte IP-Adresse richten. Nur ein Broadcast wird der lokale Kernel des Clients akzeptieren; auf eine IP-Adresse reagiert er erst, wenn es die »seine« ist:

Ersichtlich aus den Ausgaben sollte sein: bootpc allein richtet mir mein Netzwerk noch nicht ein. Tatsächlich liefert der Bootp-Client einzig die relaventen Informationen. Wie damit zu verfahren ist, liegt in Händen des Administrators. Vermutlich wird er den »Rest« von einem Shellskript erledigen lassen; wir demonstrieren hier pump is a daemon that manages network interfaces that are controlled by either the DHCP or BOOTP protocol.einzig die Konfiguration der Netzwerkkarte und das Setzen der Routen anhand der neuen Parameter. Unser Skript beginnt wie folgt:

Zum Zwecke des Aufzeigens der möglichen Vorgehensweise sollte das Beispiel genügen. In realistischen Szenarien darf natürlich eine Fehlerbehandlung nicht fehlen. Das Einrichten zum Zugriff auf die gelieferten DNS-Server erfordert eine Modifikation der Datei /etc/resolv.conf. Hier sollte dringend Sorge getroffen werden, um den »ursprüglichen« Zustand während des Herunterfahrens des Systems zu rekonstruieren. Das Ganze läuft auf ein Init-Skript hinaus, das mittels der Parameter »start« und »stop« alternative Maßnahmen trifft.

Der Client pump

RedHat basierte Distributionen verwenden als Bootp- als auch als DHCP-Client häufig das Programm pump. »pump« arbeitet dabei als Daemon und administriert von Haus aus Netzwerk-Schnittstellen und einige Netzwerkdienste.

Die wichtigen Optionen sind:

Um mit pump das Netzwerk eines Clients via Bootp oder DHCP einzurichten, genügt auf Clientseite der Aufruf des Kommandos. Die nachfolgende Statusabfrage sollte berichten, welche Informationen vom Server bezogen wurden:

Die Aufzählung der Optionen von pump deutete bereits die Möglichkeit an, das Verhalten des Daemons per Konfigurationsdatei zu beeinflussen. Der typische Name der Datei lautet /etc/pump.conf. Ihre Existenz genügt, um von pump beachtet zu werden. Die Direktiven in der Datei können sowohl einem speziellen Device zugeordnet werden oder als globale Direktive für alle zu konfigurierenden Netzwerkgeräte gelten:

Jedes wiederholte Vorkommen einer Direktive überschreibt die bisherigen Werte. Als Direktiven sind möglich:

DHCP

Booten übers Netz