Booten und Konfiguration im Netz
Übersicht Weiter

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 Zurück Anfang Weiter

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:

user@sonne> grep bootp /etc/inetd.conf
bootps   dgram  udp   wait   root   /usr/sbin/bootpd   /etc/bootptab

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

user@sonne> cat /etc/xinetd.conf
...
bootps
{
        socket_type     = dgram
        wait            = no
        user            = root
        server          = /usr/bin/bootpd
        server_args     = /etc/bootptab
}
...

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 ] ]
bootpgw [ -t Timeout -d Debuglevel ] Bootp-Server

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
bootps           67/udp    # Bootstrap Protocol Server
bootps           67/tcp    # Bootstrap Protocol Server
bootpc           68/udp    # Bootstrap Protocol Client
bootpc           68/tcp    # Bootstrap Protocol Client

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

ethernet bzw. ether 10..100 Mb Ethernet
ieee802 bzw. tr bzw. token-ring IEEE 802 networks
arcnet ARCNET
ax.25 AX.25 Amateur Radio networks

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.

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:

user@sonne> cat /etc/bootptab
erde:dn=galaxis.de:ds=192.168.100.1 211.97.100.1:ht=ethernet:ha=005056AA6464:ip=192.168.100.10:sm=255.255.255.0
venus:dn=galaxis.de:ds=192.168.100.1 211.97.100.1:ht=ethernet:ha="00:52:52:EA:01:64":ip=192.168.100.11:sm=255.255.255.0
mars:dn=galaxis.de:ds=192.168.100.1 211.97.100.1:ht=ethernet:ha=77630A0B0104:ip=192.168.100.12:sm=255.255.255.0

merkur:\
        dn=galaxis.de:\
        ds=192.168.100.1 211.97.100.1:\
        ht=ethernet:\
        ha=205252EA01F4:\
        ip=192.168.100.13:\
        sm=255.255.255.0

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
.default:\
        dn=galaxis.de:\
        ds=192.168.100.1 211.97.100.1:\
        sm=255.255.255.0:\
        ht=ethernet

erde:tc=.default:ha=005056AA6464:ip=192.168.100.10
venus:tc=.default:ha="00:52:52:EA:01:64":ip=192.168.100.11
mars:tc=.default:ha=77630A0B0104:ip=192.168.100.12
merkur:tc=.default:ha=205252EA01F4:ip=192.168.100.13

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
bootpd: info(6):   bootptab mtime: Mon Jun 4 09:54:14 2001
bootpd: info(6):   reading "/etc/bootptab"
bootpd: info(6):   read 5 entries (4 hosts) from "/etc/bootptab"

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 Zurück Anfang Weiter

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:

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

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.

user@sonne> cat /etc/dhcpd.conf
subnet 192.168.100.0 netmask 255.255.255.0 {
# --- default gateway
       option routers 192.168.100.1;
       option subnet-mask 255.255.255.0;

#      option nis-domain "nisdomain.de";
       option domain-name "galaxis.de";
       option domain-name-servers 192.168.100.100;

       option time-offset 1;
#     option ntp-servers 192.168.1.1;
#      option netbios-name-servers 192.168.1.1;
# --- Selects point-to-point node (default is hybrid). Don't change this unless
# -- you understand Netbios very well
#      option netbios-node-type 2;

#      range dynamic-bootp 192.168.100.10 192.168.100.99;
       range 192.168.100.10 192.168.100.99;
       default-lease-time 21600;
       max-lease-time 43200;

# we want the nameserver to appear at a fixed address
#      host ns {
#        next-server marvin.redhat.com;
#        hardware ethernet 12:34:56:78:AB:CD;
#        fixed-address 207.175.42.254;
#      }
}

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:

user@sonne> /sbin/ifconfig eth0
eth0      Link encap:Ethernet HWaddr 00:00:CC:E9:1E:37
          inet addr:192.168.100.11 Bcast:192.168.100.255 Mask:255.255.255.0
          UP brOADCAST NOtrAILERS RUNNING MTU:1500 Metric:1
          RX packets:65 errors:0 dropped:0 overruns:0 frame:0
          TX packets:149 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:6884 (6.7 Kb) TX bytes:22860 (22.3 Kb)
          Interrupt:11 Base address:0xa000

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
erde.galaxis.de (192.168.100.99) at 00:00:1E:D9:4C:A5 [ether] on eth0
mars.galaxis.de (192.168.100.22) at 00:00:3F:D0:4D:D4 [ether] on eth0

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

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:

dhcpd [ -p port ] [ -f ] [ -d ] [ -q ] [ -cf config-file ]
      [ -lf lease-file ] [ if0 [ ...ifN ] ]

-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
Internet Software Consortium DHCP Server 2.0pl3
Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium.
All rights reserved.

Please contribute if you find this software useful.
For info, please visit http://www.isc.org/dhcp-contrib.html

Listening on Socket/eth1/172.16.45.0
Sending on  Socket/eth1/172.16.45.0
Listening on Socket/eth0/192.168.100.0
Sending on  Socket/eth0/192.168.100.0

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.

# /etc/dhcpd.conf

server-identifier ns1.zoneA.de;
authoritative;
# Dies ist die wichtigst Zeile. Sie spezifiziert die Methode, wie Updates
# an den Server übertragen werden.
ddns-update-style interim;
ddns-updates on;

# Dies ist die gleiche Key-Definition, wie sie
# bereits in der /etc/named.conf zu finden ist
key rndckey {
algorithm hmac-md5;
secret "secret_md5_hash";
};

# oder
include "/etc/rndc.key";

# Hier werden die Zonen und die Schlüssel festgelegt
zone zoneA.de. {
primary ns1.zoneA.de;
key rndckey;
}

zone 0.1.10.in-addr.arpa. {
primary ns1.zoneA.de;
key rndckey;
}


# Hier verbieten wir noch den Clients selbstständig
# Updates an den DNS-Server zu geben, da allein der
# DHCP-Server diese Aufgabe übernehmen soll
deny client-updates;
allow unknown-clients;

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

user@sonne> /sbin/arp
              Address        HWtype HWaddress          Flags Mask   Iface
              mars.zoneA.de  ether  xx:xx:xx:xx:xx:xx  C            eth0
              ns1.zoneA.de   ether  xx:xx:xx:xx:xx:xx  C            eth0
user@sonne> tail /var/log/messages
      ns1 dhcpd: DHCPREQUEST for 10.1.0.208 from xx:xx:xx:xx:xx:xx (mars) via eth0
      ns1 dhcpd: DHCPACK on 10.1.0.208 to xx:xx:xx:xx:xx:xx (mars) via eth0
                                 ^^^^ send host-name "mars"

Booten übers Netz Zurück Anfang

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