Booten und Konfiguration im Netz

Übersicht Weiter
BOOTP Zurück Anfang Weiter

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:

root@sonne> bootptest erde
bootptest: version 2.4.3
Sending to 192.168.100.100 (request) htype:0 hlen:0 xid:1457 C:192.168.100.99 vend-rfc1395
Recvd from 192.168.100.99 (reply) htype:0 hlen:0 xid:1457 C:192.168.100.99 Y:192.168.100.99 S:192.168.100.99 sname:"sonne" file:"/00:00:1C:D9:4C:C5" vend-rfc1395 SM:255.255.255.0 DNS:192.168.100.99 DNAM:"galaxis.de"

Der Client bootpc

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

bootpc [--dev device] [--debug] [--server addr] [--hwaddr addr] [--returniffail] [--timeout seconds] [--serverbcast] [--help] [...]

--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:

root@sonne> ifconfig eth0 0.0.0.0 up

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:

root@sonne> route add default eth0

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:

root@sonne> bootpc --serverbcast
SERVER='192.168.100.100'
IPADDR='192.168.100.10'
BOOTFILE=''
NETMASK='255.255.255.0'
NETWORK='192.168.100.0'
brOADCAST='192.168.100.255'
DNSSRVS_1='192.168.100.1'
DNSSRVS_2='211.97.100.1'
DNSSRVS='192.168.100.1 211.97.100.1'
DOMAIN='galaxis.de'
SEARCH='galaxis.de'

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:

root@sonne> cat bootpc-script
# Nachfolgend stehen die Parameter in Variablen (SERVER, IPADDR,...) zur Verfügung
eval `bootpc --returniffail --timeoutwait 2 --serverbcast`

# Device 'eth0' mit »richtiger« IP-Adresse konfigurieren
ifconfig eth0 down
ifconfig eth0 $IPADDR netmask $NETMASK broadcast $brOADCAST up

# Default-Route setzen
route add default eth0

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.

pump [-krRsd?] [-c file] [-h hostname] [-i interface] [-l hours] [--usage]

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:

root@sonne> pump -s
Device eth0
        IP: 192.168.100.100
        Netmask: 255.255.255.0
        Broadcast: 192.168.100.255
        Network: 192.168.100.0
        Boot server 127.0.0.2
        Next server 192.168.100.10
        Domain: galaxis.de
        Nameservers: 192.168.100.1 211.97.100.1

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:

# Globale Direktive(n)
domainsearch "galaxis.de outside.all"
retries 3

# Lokale Direktive(n) für eth0
device eth0 {
   nogateway
}

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>



DHCP Zurück Anfang Weiter

Booten übers Netz Zurück Anfang