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. 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.
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:
user@sonne> grep bootp /etc/inetd.conf
|
Wird anstatt des »inetd« der xinetd verwendet, ist die Datei /etc/xinetd.conf der entsprechende Anlaufpunkt:
user@sonne> cat /etc/xinetd.conf
|
Neben dem »(x)inetd-Modus« lassen sich Bootp-Server und Bootp-Gateway ebenso als Daemon betreiben (»Standalone-Modus«). Die Aufrufe besitzen folgende Syntax:
bootpd [ -t Timeout -d Debuglevel -c chdir-path ] [ bootptab [ dumpfile ] ]
|
Die Kommandozeilenparameter bedeuten (auf einige veraltete Optionen haben wir bewusst verzichtet):
| -t Timeout | ||
| Zeitspanne (Minuten), nach der sich der Server selbsttätig beendet, falls keine weiteren Bootp-Anfragen eintrafen. Im (x)inet-Modus sind 15 Minuten voreingestellt; im Standalone-Modus arbeiten beide Server unbegrenzt (entspricht 0 Minuten). | ||
| -d | ||
| Debugmodus (-d, -d1 .., -d4); bestimmt die Flut der Statusmeldungen. | ||
| -c chdir-path | ||
| bootpd wechselt in das angegebene Arbeitsverzeichnis. Die Option ist nur in Verbindung mit TFTP (Booten übers Netz) sinnvoll, da der Bootp-Server dann für die Überprüfung der Bootdateien der Clients zuständig ist. Das Verzeichnis sollte dasselbe sein, das der Tftp-Server verwendet. | ||
| bootptab | ||
| Konfigurationsdatei, aus der der Bootp-Server die Informationen für die Clients bezieht. Voreinstellung ist /etc/bootptab. | ||
| dumpfile | ||
| Name einer Datei, in die der Bootp-Server bei Empfang des Signals »SIGUSR1« seine interne Datenbank ablegt | ||
| Server | ||
| Name des Bootp-Servers, an den ein Bootp-Gateway BOOTREQUEST-Pakete weiterleitet | ||
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:
user@sonne> grep bootp /etc/services
|
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.
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:tg[=Wert...]:tg[=Wert...]:tg[=Wert...]
|
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:
| bf | |||||||||
| Name der Bootdatei (siehe Booten übers Netz) | |||||||||
| bs | |||||||||
| Größe der Bootdatei in 512-Byte-Blöcken (siehe Booten übers Netz) | |||||||||
| dn | |||||||||
| Domainname | |||||||||
| ds | |||||||||
| Liste von DNS-Servern | |||||||||
| gw | |||||||||
| Liste von Gateways | |||||||||
| ha | |||||||||
| Hardwaredresse des Clients | |||||||||
| hd | |||||||||
| Verzeichnis, in dem die Bootdatei liegt (siehe Booten übers Netz) | |||||||||
| hn | |||||||||
| Rechnername, den der Client nachfolgend verwenden soll (überschreibt auf Clientseite den aktuellen Namen) | |||||||||
| ht | |||||||||
Type der Netzhardware, so wie sie im Assigned Number RFC spezifiziert ist. Die Angabe kann numerisch oder symbolisch erfolgen. Wichtige Symbole sind:
|
|||||||||
| ip | |||||||||
| IP-Adresse des Clients | |||||||||
| lp | |||||||||
| Liste von Printservern | |||||||||
| ms | |||||||||
| Weist den Server an, die Antwort-Pakete mit der angegebenen Fragmentgröße zu versenden | |||||||||
| rp | |||||||||
| Verzeichnis, das als Root zu mounten ist (siehe Booten übers Netz) | |||||||||
| sa | |||||||||
| Adresse des TFTP-Servers, den der Client verwenden soll (siehe Booten übers Netz) | |||||||||
| sm | |||||||||
| Subnetzmaske des Netzwerks, in dem der Client sich befindet | |||||||||
| Tn | |||||||||
| Eine generischer »Tag«, der Hersteller spezifische Erweiterungen ermöglicht. n ist ein numerischer Wert und bezeichnet die konkrete Aktion. Debians Fai macht von einer solchen Eigenschaft regen Gebrauch. Aktuelle Bootp-Implementierungen verfügen über Erweiterungen, die die DHCP-Verbesserungen integrieren. Zuständig sind hierfür die Tags T250 (optionale Konfigurationsparameter), T243 (Modus der Adressübernahme in die bootptab) und T253 (Anzahl der dynamisch zuweisbaren Adressen in hexadezimaler Notation). Wir werden auf ihren Einsatz nicht eingehen. | |||||||||
| tc | |||||||||
| Eintrag, mit dem auf ein Makro (Dummy-Eintrag) Bezug genommen wird | |||||||||
| td | |||||||||
| Wurzelverzeichnis auf dem TFTP-Server | |||||||||
| ts | |||||||||
| Adresse eines Zeitservers | |||||||||
| yd | |||||||||
| NIS-Domainname | |||||||||
| ys | |||||||||
| Adresse eines NIS-Servers | |||||||||
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.
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:
user@sonne> cat /etc/bootptab
|
Verringert wird der Schreibaufwand durch die Zusammenfassung der gemeinsamen Parameter in ein Makro. Eine andere Darstellung derselben Konfiguration wäre:
user@sonne> cat /etc/bootptab
|
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:
root@sonne> bootpd -d4
|
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.
Maximale Flexibilität erlangt DHCP durch drei verschiedene Verfahrensweisen bei der Zuteilung von IP-Adressen an einen Client:
| Statische Zuordnung | ||
| Die auch als »manuelle Zuweisung« bezeichnete Methode erlaubt die feste Vergabe konkreter IP-Adressen an konkrete Clients. So sollte bspw. ein Server immer unter ein und derselben Adresse zu erreichen sein. Das Prinzip ähnelt dem Verfahren des BOOTP. | ||
| Automatische Zuordnung | ||
| Der Server hält einen Pool von IP-Adressen, aus der er einem Client eine freie Adresse zuweist. Der Client erhält die Adresse für unbegrenzte Zeit. | ||
| Dynamische Zuordnung | ||
| Wie »Automatische Zuordnung«, wobei der Client die Adresse nur für einen bestimmten Zeitraum verwenden darf. Nach Ablauf der »Lease-Zeit« wird dem Client die Adresse entzogen. Ein Clientrechner kann in einem solchen Fall versuchen, sein Abonnement zu verlängern, wobei weder die Verlängerung noch die erneute Zuordnung derselben IP-Adresse gesichert ist (ein anderer Client hat sich ggf. »vorgedrängelt«). | ||
Der gesteigerte Variation der Kommunikation spiegelt sich ebenso in der Anzahl der Anfragen und Antworten wider, die Client und Server miteinander austauschen (können):
| DHCPDISCOVER | ||
| Broadcast-Anfrage eines Clients zur Lokalisierung eines DHCP-Servers | ||
| DHCPOFFER | ||
| Serverantwort nach einem DHCPDISCOVER mit dem Angebot an Parametern | ||
| DHCPREQUEST | ||
| Anfrage eines Clients an einen konkreten Server. Hierunter fallen sowohl die Anfrage nach der Erstaustattung mit IP-Adresse und den weiteren Parametern als auch die Bitte um Verlängerung der Lease-Zeit als auch die Anforderung nach Bestätigung der bisherigen Parameter (u.a. nach einem Reboot des Clients). | ||
| DHCPACK | ||
| Serverantwort mit IP-Adresse und den geforderten Parametern | ||
| DHCPNACK | ||
| Ablehnung eines DHCPREQUEST durch den Server | ||
| DHCPDECLINE | ||
| Ablehnung des Clients, da die IP-Adresse schon verwendet wird | ||
| DHCPRELEASE | ||
| Ein Client gibt seine Konfiguration frei (dClient an Server, Adresse ist schon benutzt.amit steht die IP zur erneuten Vergabe zur Verfügung) | ||
| DHCPINFORM | ||
| Clientanfrage nach Parametern ohne IP-Adresse | ||
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.
user@sonne> cat /etc/dhcpd.conf |
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:
user@sonne> /sbin/ifconfig eth0 |
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.
user@sonne> /sbin/arp -a |
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:
root@sonne> tcpdump -qte broadcast and port bootpc
|
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. &Umml;ber mehrere Kommandozeilenoptionen lässt sich das Verhalten beeinflussen:
dhcpd [ -p port ] [ -f ] [ -d ] [ -q ] [ -cf config-file ] |
| -cf config-file | ||
| Der Server liest die Konfiguration aus der angegebenen Datei anstatt aus /etc/dhcpd.conf | ||
| -d | ||
| Die Fehler landen auf der Standardfehlerausgabe anstatt beim syslogd | ||
| -f | ||
| Der Serverprozess startet im Vordergrund | ||
| -lf lease-file | ||
| Der Server liest die Datei zur Lease-Zeiten aus der angegeben Datei anstatt aus /var/lib/dhcp/dhcpd.leases. Diese Datei wird vom Server selbst verwaltet und sollte - obwohl sie im ASCII-Format vorliegt - nicht verändert werden. | ||
| -p port | ||
| Der Server verwendet den angegebenen Port anstatt 67 | ||
| -q | ||
| Unterdrückt die Ausgabe einer Copyright-Meldung beim Programmstart (sinnvoll bei Verwendung in Startskripten) | ||
root@sonne> dhcpd |
| 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 Ausfrü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...