Druckversion | |||||||||||||||||||||
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 bootptestbootptest 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 bootpcBevor wir uns der notwendigen Vorarbeit widmen, sollen die wichtigsten Optionen des Kommandos genannt werden.
--debug Ausführliche Meldungen über die einzelnen Schritte
--dev Device Name des Netzwerkdevices, über das die Kommunikation laufen soll. Wichtig ist die Angabe, wenn
mehrere Geräte (Netzwerkkarten, Modems,...) vorhanden sind.
--help Hilfe zum Programm
--hwaddr Hardwareadresse Die Anfrage wird unter der angegebenen Hardwareadresse gestellt
--returniffail Programmabbruch erfolgt bei einem Fehler, ansonsten wird ein Tastendruck erwartet
--server <Server-IP> Adresse des zu befragenden Bootp-Servers (ohne die Angabe wird per Broadcast nach einem gesucht)
--serverbcast
Weist den Bootp-Server an, die Antwort als Broadcast zu senden. Zur Erstausstattung eines Clients
mit einer IP-Adresse ist die Angabe zwingend erforderlich!
--timeoutwait Sekunden Wie lange soll maximal auf eine Antwort gewartet 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 pumpRedHat 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: -c <file> Name einer Konfigurationsdatei, wenn es sich nicht um /etc/pump.conf handelt
-h <hostname> Name/Adresse des zu befragenden Bootp- bzw. DHCP-Servers
-i <Interface> Zu konfigurierenden Netzwerkgerät; Voreinstellung ist eth0
-k Beendet den Daemon und deaktiviert alle Netzwerkgeräte
-l <hours> Gültigkeitsdauer der vom Server empfangenen Daten in Stunden; die Option ist nur in Verbindung mit DHCP wichtig
-R Anforderung neuer Daten (auch ohne das die alten »verfallen« sind)
-s Anzeige von Statusinformationen
-d Keine Modifikation der /etc/resolv.conf (DNS-Server-Einträge)
--no-gateway Kein Setzen einer default-Route für das Netzwerkgerät
--help Eine Kurzhilfe zum Kommando
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: device <Devicename>
Bindet nachfolgende Direktiven an das bezeichnete Device; die Liste muss in geschweifte Klammern
eingeschlossen sein
domainsearch <Suchpfad>
Anstatt den DNS-Suchpfad zur Auflösung unvollständiger Rechnernamen aus der Datei
/etc/resolv.conf zu nehmen, wird der angegebene verwendet
nonisdomain Der Nis-Domainname bleibt erhalten, selbst wenn der Server einen anderen mitteilt
nodns Kein Überschreiben der Datei /etc/resolv.conf
nogateway Ignorieren der Angaben zu default-Routen vom Server
retries <Anzahl> Anzahl Wiederholungen, wenn eine Anfrage am Server scheiterte
timeout <Sekunden> Eine unbeantwortete DHCP/Bootp-Anfrage gilt nach Ablauf der angegebenen Zeitspanne als fehlgeschlagen
script <Programm/Skriptname>
|
|||||||||||||||||||||
Korrekturen, Hinweise? |