Booten und Konfiguration im Netz

Übersicht

Die etwas »schwammige« Formulierung »Booten und Konfiguration im Netz« versucht die nachfolgend vorgestellten - und doch recht unterschiedlichen - Techniken auf einen gemeinsamen Nenner abzubilden.

Genau genommen, umschreibt »Konfiguration einiger Netzwerkparameter während des Netzwerkstarts« trefflich das Ansinnen von Dynamic Host Configuration Protocol DHCP oder Bootstrap Protocol BOOTP. Aber als Titel schien uns das schlicht weg zu lang.
I.d.R. wird man das Netzwerk im Rahmen des Bootvorgangs aktivieren, weshalb DHCP und BOOTP oft in einem Atemzug mit »Booten« und »Netzkonfiguration« genannt werden. Wichtigstes Ansinnen beider Protokolle ist es, einen Clientrechner mit einer IP-Adresse zu versehen. Ursprünglich entsprang der Bedarf eines solchen Verfahrens dem Einsatz festplattenloser Clients, die ihre IP-Adresse während des Starts nicht kennen können (Wo sollten sie diese auch speichern?). Die heutigen Einsatzfälle sind weit reichender und sollen mit der Vorstellung des jeweiligen Protokolls genannt werden.

Der älteste (verbreitete) Mechanismus zur IP-Adress-Vergabe ist das Reverse Address Resolution Protocol (RARP), quasi das »umgekehrte« ARP. Es basiert auf einer Broadcast-Anfrage, wobei der Client in seinem Subnetz die seiner Hardwareadresse zugeordnete IP-Adresse erfragt. Ein RARP-Server wird anhand einer Datenbank mit der gewünschten Information antworten.

RARP ist jedoch zu sehr auf die zugrunde liegende Netzhardware fixiert und auf den bloßen Austausch der IP-Adresse beschränkt. Der Rechnername selbst oder bspw. der Namen eines DNS-Servers kann hierüber nicht in Erfahrung gebracht werden. U.a. der Wunsch nach solchen Anforderungen führte zur Entwicklung des BOOTP, das allgemein als Nachfolger des RARP bezeichnet wird. Der evolutionären Linie folgend, tritt DHCP mit einem nochmals gesteigerten Funktionsumfang das Erbe des BOOTP an.

Bei »Booten übers Netz« handelt es sich da um etwas gänzlich anderes, dient dieses Verfahren doch zum Start von »plattenlosen« Clients (Terminals), die alle notwendigen Daten - einschließlich des Kernels und des Rootdateisystems - von einem Server beziehen. Da einem solchen Vorgehen eine Konfiguration des Netzwerks vorausgehen muss - und DHCP bzw. BOOTP die genutzten Techniken sind - gliedert sich auch dieses Thema unter »Booten und Konfiguration im Netz« ein...

BOOTP - Internet Bootstrap Protocol

Das Bootstrap Protocol dient zur Verteilung von IP-Konfigurationsparametern an einen Rechner. Für gewöhnlich handelt es sich um festplattenlose Clients, die während des Bootvorgangs alle notwendigen Informationen von einem Bootp-Server beziehen. Auch wenn das neuere DHCP BOOTP in vielen Bereichen verdrängt hat, gelangt BOOTP zumeist in Zusammenhang mit Booten übers Netz zum Einsatz, da der Kernel BOOTP direkt unterstützt.

Die Funktionsweise ist einfach: Ein konfigurationswilliger Client sendet eine Anforderung (BOOtrEQUEST) als Broadcast in das lokale (Sub)Netz. Ein Bootp-Server antwortet mit einem BOOtrEPLY-Paket, das eventuell mehrere Konfigurationsparameter für das Netzwerk, mindestens aber die IP-Adresse des Clients beinhaltet. Der Bootp-Server muss nicht zwingend im lokalen Subnetz liegen, dann erfordert das Protokoll aber ein Bootp-Gateway.

Bootp-Gateways dienen der Weiterleitung von BOOtrEQUESTS. Der zuständige Daemon bootpgw wird hierzu mit der Adresse eines Bootp-Servers als Argument gestartet. Dieser Daemon lauscht nun im Netz nach Anfragen von Clients. Trifft eine Bootp-Anfrage ein, wartet das Gateway noch drei Sekunden, ob eine zugehörige Antwort von einem Server eintrifft. Wenn nicht, trägt er in das BOOtrEQUEST-Paket seine Adresse ein und leitet es an den ihm bekannten Bootp-Server weiter. Bootp-Gateways könnten somit die Folgen des Ausfalls eines Servers lindern.

Serverstart

Nur in seltenen Fällen wird ein Bootp-Server entscheidend mehr als einige hundert Clients bedienen. Typisch für einen Rechnerpool sind wohl gar nur 10-50 Clients. Auch fordert ein Client nur ein einziges Mal während seiner Systemlaufzeit eine Netzkonfiguration an, sodass letztendlich eher selten Bootp-Kommunikationen im Netz zu verzeichnen sind. Es bietet sich daher an, den Bootp-Server nur bei Bedarf zu aktivieren und dies ist die Aufgabe von inetd:

Wird anstatt des »inetd« der xinetd verwendet, ist die Datei /etc/xinetd.conf der entsprechende Anlaufpunkt:

Neben dem »(x)inetd-Modus« lassen sich Bootp-Server und Bootp-Gateway ebenso als Daemon betreiben (»Standalone-Modus«). Die Aufrufe besitzen folgende Syntax:

Die Kommandozeilenparameter bedeuten (auf einige veraltete Optionen haben wir bewusst verzichtet):

Obwohl die Datei /etc/services in den von Distributionen ausgeliefertem Zustand meist komplett bestückt ist, sollten Sie sich vergewissern, dass die entsprechenden Ports freigeschalten sind:

Da alle verbreiteten Bootp-Implementierungen UDP als Transportprotokoll verwenden, genügt die Existenz der ersten Zeile. Die Zeilen 3 und 4 betreffen einen Bootp-Client und sind auf Server-Seite überflüssig.

Die Syntax der Konfigurationsdatei

Typisch erfolgt die Konfiguration in der Datei /etc/bootptab; über die Angabe des Datenbanknamens per Kommandozeilenoption kann die Datei prinzipiell beliebig benannt werden.

Die Fülle der Parameter, die ein Bootp-Server anbieten kann, lassen sich grob in zwei Katagorien einordern. Das sind zum einen Daten, die spezifisch für einen einzelnen Client sind, wie Rechnername, Hardware- und IP-Adresse und es sind Parameter, die für eine Reihe von Clients gleichermaßen gelten (bspw. Domainname, DNS-Server oder Netzwerkmaske). Aus diesem Grund unterstützt das Datenbankformat eine Art »Makro«-Mechanismus, der die Definition von »globalen« Datensätzen erlaubt. Doch zunächst betrachten wir den allgemeinen Aufbau eines Datenbankeintrags:

Rechnername ist dabei der aktuelle Name des Clients oder ein Dummy-Eintrag. Um einen Dummy-Eintrag von einem gültigen Rechnernamen zu unterscheiden, beginnt der Bezeichner mit einem Punkt. Solch ein Dummy definiert eine Liste von Parametern, die als eine Art Makro in anderen Einträgen eingebunden werden können.

tg steht für ein zweistelliges Symbol, deren wichtigste folgende Liste erläutert:

Die relative Reihenfolge der Symbole ist unerheblich mit einer Ausnahme, dass ht zwingend unmittelbar vor ha stehen muss!

Mit Ausnahme des Symbols ip darf anstelle der IP-Adresse auch der Name des Servers stehen. Allerdings muss dieser mit den dem Client zur Verfügung stehenden Mitteln in die entsprechende IP-Adresse auflösbar sein. Für einen Client, der sein Rootverzeichnis über das Netzwerk bezieht, könnten die wichtigsten Adressen bspw. in der Datei /etc/hosts aufgeführt sein. Bei der Zuweisung mehrerer IP-Adressen (nicht bei ip, sa, sw, sm und ys) an ein Symbol sind diese durch Leerzeichen voneinander zu trennen. Symbolische Rechnernamen werden dagegen durch Kommata separiert.

Die einzelnen Symbole werden durch den Doppelpunkt voneinander getrennt, tritt ein Sonderzeichen (Doppelpunkt, Komma, Gleichheitszeichen, Leerzeichen) als Bestandteil eines Parameters auf, muss dieser in Anführungszeichen gesetzt werden. Im Falle des Hardwareadresse ist anstatt der Angabe von "7F:F8:10:00:00:AF" auch kurz 7FF8100000AF möglich.

Für einige der Symbole ist die bloße Angabe dieses erlaubt (:tg:) bzw. einzig zulässig. Dies beutet: »Der Wert ist gesetzt«. Ein Beispiel ist :hn:, was bedeutet, dass der Rechnername an den Client zu senden ist.

Im Zusammenhang mit dem Makromechanismus ist das Löschen einzelner Felder nützlich, was durch :tg=@: realisiert wird.

Schließlich lassen sich lange Zeilen aufsplitten, indem an die einzelnen Bestandteile ein Backslash »\« angefügt wird.

Beispiele

Die nachfolgende Konfigurationsdatei definiert einige Parameter für vier Clients. Neben IP-Adresse sollen die Rechner den Domainnamen, das Gateway und die Adressen zweier DNS-Server vom Bootp-Server beziehen. Zur Demonstration wird der letzte Eintrag auf mehrere Zeilen aufgeteilt:

Verringert wird der Schreibaufwand durch die Zusammenfassung der gemeinsamen Parameter in ein Makro. Eine andere Darstellung derselben Konfiguration wäre:

Zum Testen sollten Sie den Bootp-Server zunächst im Standalone-Modus mit maximalem Debuglevel betreiben. Bez. obiger Beispielkonfiguration startet der Server bei korrekter Dateisyntax mit folgenden Statusmeldungen:

Die weiteren Schritte zur Verifzierung der Konfiguration erfolgen auf Seite der Clients. Im entsprechenden Abschnitt finden Sie weitergehende Informationen. Hinweise zum Auslesen der Hardwareadresse eines Rechners erfahren Sie im folgenden Text zum DHCP-Server.

DHCP

Die Möglichkeiten von BOOTP stießen aus (mind.) zwei Gründen bald auf ihre Grenzen. Den ersten Schwachpunkt offenbarte die zunehmende Verbreitung von tragbaren Computern. »Mal eben schnell« einen solchen in ein bestehendes Netz zu integrieren, scheiterte, weil hierfür die Kenntnis der Hardwareadresse unbedingt erforderlich ist. Problem Nummer 2 erwuchs mit der zunehmenden Vernetzung, wobei frei verfügbare IP-Adressen immer mehr zur Mangelware wurden. Sind mehr Rechner miteinander verbunden, als es IP-Adressen im lokalen Netzwerk gibt, schließt die statische Zuordnung einige Rechner zwangsläufig für immer von der Kommunikation aus. Nun ist es in der Praxis selten der Fall, dass alle Rechner eines Netzwerks gleichzeitig laufen, sodass »meist« genügend Adressen für die aktiven Clients vorhanden sind. Mit der dynamischen Adressverteilung kann somit i.d.R. jeder Rechner mit einer Adresse versehen werden.

Drei Arten der Adresszuteilung

Maximale Flexibilität erlangt DHCP durch drei verschiedene Verfahrensweisen bei der Zuteilung von IP-Adressen an einen Client:

Der gesteigerte Variation der Kommunikation spiegelt sich ebenso in der Anzahl der Anfragen und Antworten wider, die Client und Server miteinander austauschen (können):

Konfiguration

Seine Konfiguration liest der Server aus der Datei /etc/dhcp.conf. Sie enthält alle Anweisungen über zu bedienende Netzwerke, Rechner und die zu verteilenden Konfigurationsdateien.

Auslesen der Hardwareadressen

Für den Fall, dass bestimmte IP-Adressen an konkrete Rechner gebunden werden müssen (bei Servern macht dies sicherlich Sinn), ist das Ermitteln der Hardwareadresse erforderlich. Ein Weg führt über das Kommando ifconfig, wozu allerdings der Gang zu jedem in Frage kommenden Rechner (bez. eine entfernte Sitzung) erforderlich wird:

Effektiver ist wohl das Auslesen des arp-Caches, also des Puffers, der die Hardware-Adressen zu jedem in »letzter Zeit« (die Dauer ist abhängig von der Gültigkeit eines solches Eintrags) kontaktierten Rechner enthält.

Um alle derzeit im lokalen Netz befindlichen Rechner zu erfassen, ließe sich ein ping in einer Schleife über alle IP-Adressen absetzen.

Eine weitere Möglichkeit bietet das Kommando tcpdump, wozu die Netzwerkkarte allerdings im so genannten PROMISC-Modus laufen muss. Folgender Aufruf findet die Hardwareadressen aller aktiven Rechner des lokalen Netzes:

Start des Daemons

I.d.R. genügt der bloße Aufruf des Kommandos dhcpd zum Start des Servers, womit der Serverprozess sich automatisch in den Hintergrund begibt und alle Parameter in der Voreinstellung übernimmt. Über mehrere Kommandozeilenoptionen lässt sich das Verhalten beeinflussen:

Dynamischer DNS-Eintrag von DHCP-zugewiesenen Adressen

Anmerkung: Der folgende Abschnitt basiert auf einer Ausarbeitung von Bernd Reimann.

Langer Titel - kurze Rede.
Wenn Sie in Ihrem Netzwerk mit DHCP arbeiten, ist es leider so, dass keinerlei Namensauflösung funtioniert. Um Ihre Clients mit Namen ansprechen zu können, bedarf es einiges an Handarbeit und auch einiges an konsequenter Update-Arbeit, woran es meist scheitert.

Mit der Kombination von DNS und DHCP gehört dies alles der Vergangenheit an. Diese beiden Server bieten Ihnen die Möglichkeit, die Adressen dynamisch vergeben zu lassen und auch dynamisch in Ihrem Nameserver einzupflegen. Einige wenige Handgriffe und Änderungen in der Datei »dhcp.conf« genügen und schon können Sie sich ruhig zurücklehnen und die Arbeit anderen - nämlich den Servern - überlassen.

Sie sehen lediglich die Art der Kommunikaton muss festgelegt werden und schon können die beiden Server kommunizieren.
Genauere Informationen zu den Schlüsseln und DNS finden Sie hier.
Clientseitig müssen nun noch der Eintrag send host-name "mars" in die /etc/dhclient.conf eingetragen werden, damit der DHCP-Server den Hostnamen einer IP-Adresse zuordnen kann und diese beiden beim DNS registrieren kann

Booten übers Netz

Im 2-Jahres-Turnus stellt man mit Bedaueren fest, dass der einst so moderne Computer so gar nicht mehr zu den Reißern zählt; die eine oder andere Software stottert träge vor sich hin; das aktuellste Actionspiel erreicht die Dynamik einer Blitzschach-Partie...

Es wird Zeit für die Aufrüstung. Der Gang zum Händler beginnt mit einer Belehrung des besserwissenden Angestellten, dass unser Mainboard für die neuen Prozessoren nicht geeignet ist. Das Netzteil ist unterdimensioniert und mit dem langsamen Speicher dürfe man das System auf gar keinen Fall ausbremsen! Ach ja, die alte Grafikkarte passt selbstverständlich auch nicht zum performanten Aufrüstpaket, ganz zu schweigen vom Kopfschmerz provozierenden Festfrequenzmonitor.

Als Resultat wird man zum Besitzer eines Zweitrechners, denn für die paar Kröten, die der Händler für das gute Stück noch anrechnen wollte, stellt man ihn dann doch lieber in die Besenkammer...