Alle Seiten

Auf dieser Seite werden alle Einzelseiten automatisch zu einer Seite zusammengefasst. Diese Seite enthält also keine zusätzlichen Inhalte.

Im Jahre 1998 begann ich, mich mit dem Betriebssystem Linux zu beschäftigen. Die erste Distribution war die Distribution Suse Linux 5.3. Danach folgten weitere Suse-Linux-Versionen bis hin zur aktuellen OpenSuse- und Ubuntu-Version.

Die Linux-Rechner sind im Laufe der Jahre zum festen Bestandteil meines lokalen Netzwerks geworden und laufen zuverlässig und stabil.

Die Gründe für Linux-Rechner waren:

• Einrichtung eines lokalen Netzwerks
• Einrichtung eines "Internet im kleinen" ("Intranet")
• Faszination für ein Open-Source-Betriebssystem
• Berufliche Gründe
• Neugier
• Sehnsucht nach der vertrauten Kommandozeile
• Die aufgeschnappte Bemerkung "Linux kann alles" ;-)

Auf den Linux-Seiten meiner früheren Homepage waren Anleitungen zur Linux-Installation und -Konfiguration. Mit der Weiterentwicklung der Linux-Distributionen ist die Installation und Konfiguration immer komfortabler und einfacher geworden, so dass einige Seiten überholt waren. Deshalb habe ich sie bei der Überarbeitung dieser Homepage weggelassen und bitte um Verständnis dafür.

Vielleicht konnten diese Seiten im Laufe der vielen Jahre dem einen oder anderen etwas beim Einstieg in Linux helfen. Ich danke hiermit allen, die mir per E-Mail Lob und Anregungen zu diesen Seiten zukommen ließen.

Einige ausgewählte, ausführlicher behandelte Themen werden weiterhin auf dieser Homepage zu finden sein.

Ein DHCP-Server (DHCP = Dynamic Host Configuration Protocol) in einem Netzwerk teilt den anderen Rechnern die Angaben mit, die diese für den Betrieb im Netzwerk benötigen, also z.B. die IP-Adressen, die Netzmaske, den Domainnamen, die IP-Adressen des Gateways, der Nameserver und des WINS-Servers.

Der Vorteil eines DHCP-Servers liegt darin, dass die Rechner im Netzwerk diese Angaben von einem zentralen Server bekommen.

Ändern sich diese Daten, können sie neu vom Server geholt werden (spätestens beim Reboot), ohne dass sie auf jedem Rechner einzeln neu eingegeben werden müssen. Das ist insbesondere bei größeren Netzwerken ein entscheidender Vorteil.

Die Rechner im lokalen Netz, die sich die Netzwerkangaben vom DHCP-Server holen, können sich jedoch nur solange austauschen, wie auch der DHCP-Server läuft. Man wird deshalb je nach Art, Einrichtung (Redundanz) und Größe des lokalen Netzes überlegen, bei welchen Rechnern man die Netzwerkangaben fest einträgt und bei welchen nicht.

Insbesondere für transportable Rechner wie Laptops, die an verschiedenen Netzwerken angeschlossen werden, ist ein DHCP-Server im lokalen Netz von Vorteil. Durch die entsprechende Konfiguration des DHCP-Servers können solchen mobilen Rechnern jedoch ebenfalls feste IP-Adressen zugeordnet werden.

   Installation und Einrichtung des DHCP-Servers

• Die Einrichtung des DCHP-Servers soll hier anhand eines Beispiels eines Servers beschrieben werden, der zwei Netzwerk-Interfaces mit den IP-Adressen 192.168.0.1 (eth0) und 192.168.1.1 (eth1) für die beiden Subnets 192.168.0.0/24 und 192.168.1.0/24 hat (s. Bild 1). Die Konfiguration kann leicht an ein Netzwerk, das aus nur einem Subnet besteht, angepasst werden. Das Interface eth2 ist z.B. für den Anschluss eines DSL-Routers vorgesehen und soll nicht vom DHCP-Server angesprochen werden.

  

  Bild 1: Linux-Server mit DHCP-Server

  
  

• Mit YaST das Paket "dhcp-server (n)" installieren.

• Steuerung des DHCP-Servers:

  • rcdhcp start (Start des DHCP-Servers)
  • rcdhcp stop (Stop des DHCP-Servers)
  • rcdhcp restart (Neustart des DHCP-Servers)
  • rcdhcp status (Status des DHCP-Servers)

• In der Datei /etc/sysconfig/dhcpd für die Variable "DHCP_INTERFACE" die Netzwerk-Interfaces eintragen, an denen der DHCP-Server "lauschen" soll, also z.B. "eth0 eth1".

• Der DHCP-Server kann auch mit dem Kommando "dhcpd eth0 eth1" gestartet werden. Mit dem Kommando "dhcpd -d eth0 eth1" werden zusätzlich Debug-Informationen ausgegeben.

• Mit dem Kommando "insserv dhcpd" wird der DHCP-Server beim nächsten Booten des Rechners automatisch gestartet.

• Die einzige Konfigurationsdatei des DHCP-Servers ist die Datei /etc/dhcpd.conf. Wenn sie geändert wird, muss der Server neu gestartet werden, damit die Änderungen wirksam werden.

     # File /etc/dhcpd.conf
  
     # Abschnitt Global (für alle Abschnitte gültig)
     server-identifier 192.168.0.1;
     option domain-name "local.netw";
     default-lease-time 600; # zehn Minuten
     max-lease-time 3600;    # eine Stunde
     ddns-update-style none;
  
     # Abschnitt für Subnet 0 (an eth0)
     subnet 192.168.0.0 netmask 255.255.255.0 {
       range 192.168.0.51 192.168.0.60;
       option broadcast-address 192.168.0.255;
       option subnet-mask 255.255.255.0;
       option domain-name-servers 192.168.0.1;
       option routers 192.168.0.1;
       option netbios-name-servers 192.168.0.1;
  
       host win1pc {
         hardware ethernet 00:12:34:56:78:9A; # MAC-Adresse
         fixed-address 192.168.0.90; # feste IP-Adresse
         default-lease-time 172800; # zwei Tage
         max-lease-time 604800; # eine Woche
       }
     }
  
     # Abschnitt für Subnet 1 (an eth1)
     subnet 192.168.1.0 netmask 255.255.255.0 {
       range 192.168.1.61 192.168.1.70;
       option broadcast-address 192.168.1.255;
       option subnet-mask 255.255.255.0;
       option domain-name-servers 192.168.1.1;
       option routers 192.168.1.1;
       option netbios-name-servers 192.168.1.1;
  
       host win2pc {
         hardware ethernet 00:22:44:66:88:AA; # MAC-Adresse
         fixed-address 192.168.1.91; # feste IP-Adresse
         default-lease-time 172800; # zwei Tage
         max-lease-time 604800; # eine Woche
       }
     }

  • Im ersten Abschnitt sind die globalen Parameter aufgeführt, die für alle weiteren Abschnitte gelten. Danach folgen die Abschnitte für das Subnet 0 und die Hosts im Subnet 0, die feste IP-Adressen erhalten sollen. Anschließend erfolgen die Angaben für das Subnet 1 in gleicher Weise.

  • Der Parameter "server-identifier" muss vorhanden sein, wenn der Server mehr als eine Netzwerkkarte hat. Als Parameter soll die IP-Adresse der ersten Netzwerkkarte des Servers eingetragen werden.

  • Die Angaben "domain-name", "broadcast-address", "subnet-mask", "domain-name-servers", "routers" und "netbios-name-servers" werden an die DHCP-Clients (also an die Rechner im Netzwerk) übermittelt.

  • Für den Router (= Gateway) ist die feste IP-Adresse des Linux-Servers angegeben, ebenso für den Nameserver und den WINS-Server, die ja auf dem Linux-Server laufen.

  • Die "default-lease-time" ist der Standardwert, die "max-lease-time" der Maximalwert für die Gültigkeit der übermittelten IP-Adressen (in Sekunden). Welche Werte sinnvoll sind, hängt vom jeweiligen Netzwerk ab, also davon, ob ausreichend IP-Adressen für alle Rechner vorhanden sind und wie oft Rechner gewechselt werden. Die Zeitspanne reicht von Minuten bis hin zu Wochen oder Monaten.

  • In den Abschnitten "subnet" befinden sich die spezifischen Angaben für die Subnets. Der Parameter "range" gibt einen Bereich von IP-Adressen vor, die den Hosts dynamisch zugeordnet werden können. Wenn die Rechner im Netz auch mit Namen angesprochen werden sollen, müssen alle möglichen Namen dieses Bereichs natürlich auch in den Zone-Dateien des Nameservers aufgeführt werden.

  • In den Abschnitten "host" werden einzelnen Rechnern feste IP-Adressen zugeordnet (die sich natürlich nicht in dem "range"-Bereich befinden dürfen). Zur Identifikation der Rechner müssen unter den Parametern "hardware ethernet" die Hardwareadressen der Netzwerkkarten (MAC-Adressen) angegeben werden. Diese Adressen kann man unter Windows mit dem Kommando "ipconfig /all", unter Linux mit dem Kommando "ifconfig" ermitteln.

  • Sowohl unter Linux als auch unter Windows kann man die Adressen der Netzwerkkarten für die anderen Rechner des Netzes mit dem Kommando "arp -a" auflisten. Wenn der gesuchte Rechner in der Liste fehlt, genügt es, ihn "anzupingen", damit er in die Liste aufgenommen wird. Ein Ping-Rundruf ergibt dann eine vollständige Liste.

• Um die Konfiguration zu testen, sollte man die Lease-Zeiten auf einen kurzen Wert von wenigen Minuten setzen und dabei die Logdatei "/var/log/messages" auf dem Linux-Server beobachten. Sind die IP-Adressen erst einmal erfolgreich vergeben, machen sich eventuelle Fehler bei großen Lease-Zeiten erst sehr spät bemerkbar.

   Konfiguration der Clients

Die anderen Rechner im Netzwerk sollen sich nun die Netzwerkangaben vom DHCP-Server holen.

Bei Windows-Rechnern kann man unter "Systemsteuerung / Netzwerkverbindungen / LAN-Verbindung / Eigenschaften / Internetprotokoll / Eigenschaften" die Einstellung "IP-Adresse automatisch beziehen" vornehmen.

Mit dem Kommando "ipconfig /all" werden die Daten, die der DHCP-Server dem Windows-PC übermittelt, direkt angezeigt. "ipconfig /help" zeigt die Kommandooptionen, um die Netzwerkdaten freizugeben bzw. zu aktualisieren. Diese Vorgänge kann man auf dem Linux-Server in der Logdatei /var/log/messages (mit dem Kommando "tail -f /var/log/messages") gut verfolgen.

Auf Linux-Rechnern kann man mit YaST unter "Netzwerkgeräte / Netzwerkkarte" die "Automatische Adressenkonfiguration" für ein Interface auswählen.

Wenn man den Linux-Rechner neu startet, kann man im Bootlog verfolgen, wie sich der Linux-DHCP-Client mit dem Linux-DHCP-Server "unterhält".

   Links

Internet Software Consortium ... DHCP ... Server, Client, Relay Agent

   Dank

... an M., der mich auf die DHCP-Möglichkeiten ("I-Tüpfelchen") hingewiesen und mit seiner Konfigurationsdatei zu dieser Seite beigetragen hat. (22.05.2002)

Wenn sich im lokalen Netzwerk mehrere Rechner befinden, ist es sinnvoll, auf dem Linux-Server einen Nameserver einzurichten. Dies hat den Vorteil, dass man die Namen für die verschiedenen Rechner des lokalen Netzes zentral und nur einmal einzutragen braucht. Ohne Nameserver müsste man diese Einträge in den "hosts"-Dateien jedes einzelnen Rechners vornehmen.

Der Nameserver beantwortet alle Anfragen, die er selber beantworten kann. Alle anderen Anfragen leitet er an andere, äußere Nameserver weiter. Dies sind zumeist die Nameserver des eigenen Providers.

Damit der Nameserver Anfragen beantworten kann, wird für jede Domäne eine Zonendatei und eine zugehörige Datei für das Revers-Lookup benötigt. In diesen Dateien sind dann die Namen und IP-Adressen der Hosts der Domäne verzeichnet. Für das hier beschriebene lokale Netz soll beispielhaft der Name der Domäne "local.netw" lauten. Es kann aber auch jeder andere Name verwendet werden.

    Einrichtung des Nameservers

• Mit YaST Paket bind9 (n) installieren. BIND ist der Standard-Nameserver.

• Die Konfigurationsdatei /etc/named.conf wird um die externen Nameserver und die Einträge für die Zonen- und Revers-Dateien erweitert. (siehe Anhang 1).

  Wenn man einen Router zur Verbindung zum Internet verwendet, und auf diesem ein Nameserver läuft, kann man auch den Router als externen Nameserver eintragen. Der Router holt sich die Adressen der Nameserver des Providers bei der Einwahl selbst, so dass der Router immer die aktuellen Nameserveradressen hat. Der Eintrag des externen Nameservers in der Datei /etc/named.conf kann dann fest auf den Router eingestellt bleiben.

• Im Verzeichnis /var/named werden die zusätzlichen Zonen- und Reversdateien angelegt.

  • Die Datei /var/named/localnetw.zone wird für die Domäne local.netw für die Namensauflösung eingerichtet. (siehe Anhang 2).

  • Die Datei /var/named/localnetw.rev wird für die Domäne local.netw für das Revers-Lookup eingerichtet. (siehe Anhang 3).

  • Die Dateinamen "localnetw" können dabei beliebig gewählt werden, müssen aber mit den Bezeichnungen in der Datei /etc/named.conf übereinstimmen.

  • Die Dateien *.zone und *.rev müssen sorgfältig erstellt werden, da sie offenbar etwas empfindlich gegen falsche Zeichen sind. Auszuprobieren ist ggf. auch, Tabs statt Spaces zu verwenden.

  • Im Verzeichnis /var/lib/named sind bereits die Zonen- und Revers-Dateien für "localhost", /var/named/localhost.zone und /var/named/127.0.0.zone vorhanden.

  • In der Datei /var/named/root.hint stehen die Root-Nameserver. An diese Root-Nameserver wendet sich der lokale Nameserver, wenn er die Anfragen weder selbst beantworten kann noch Antworten von den eingetragenen externen Nameservern bekommmt.

  Anhand der Zonendateien wird augenfällig, dass die Namen www, irc, ftp, mail usw., die man so oft im Browser eingibt, nichts anderes sind als Alias-Namen für Hosts.

• Bei der Netzwerkkonfiguration des Linux-Servers, auf dem der Nameserver läuft, wird nun der eigene Server als Nameserver eingetragen. Damit richtet dieser Rechner alle Nameserveranfragen zunächst an den eigenen Nameserver (also an den, der auf ihm selber läuft).

• Mit dem Kommando "insserv named" wird der Nameserver beim Booten bereits mit gestartet.

• Der Nameserver kann über folgende Kommandos gesteuert werden:

  • rcnamed start (Start des Nameservers)
  • rcnamed stop (Stop des Nameservers)
  • rcnamed restart (Restart des Nameservers)
  • rcnamed status (Status des Nameservers ausgeben)

  Nach einer Änderung der Konfiguration des Nameservers muss dieser neu gestartet werden.

• Ein Test, z.B. mit "ping" zu einem bekannten Internethost, sollte nun zeigen, ob der so eingerichtete Nameserver wie gewünscht funktioniert.

• Wenn im LAN ein Nameserver läuft, brauchen die Rechner des LAN nicht in die Hosts-Dateien der einzelnen Rechner eingetragen zu werden. Wenn man jedoch Namen in die Hosts-Dateien einträgt, werden diese bei der Namensauflösung vorrangig vor dem Nameserver verwendet. Man kann also die Hosts-Datei auf dem eigenen PC verwenden, um die im Nameserver eingetragenen Namen zu "überschreiben".

  Auf einem Windows-PC ist die Hosts-Datei c:\windows\hosts, auf einem Linux-PC /etc/hosts. Beispiel für die zusätzlichen Einträge in einer Hosts-Datei:

    192.168.0.1   winpc.local.netw     winpc
    192.168.0.2   linuxpc.local.netw   linuxpc
    192.168.0.3   otherpc.local.netw   hugo

  In der dritten Spalte der Hosts-Dateien stehen die Aliasnamen, die beliebig sein können.

    Nameserver-Einstellungen im lokalen Netz:

Auf den anderen Rechnern des lokalen Netzes wird nun der Linux-Server, auf dem der Nameserver läuft, als Nameserver eingetragen. Wenn auf dem Linux-Server auch ein DHCP-Server läuft, kann die Nameserveradresse auch automatisch bezogen werden.

Unter Windows ist die Nameserverkonfiguration unter "Systemeinstellungen / Netzwerkverbindungen" zu finden.

    Links

Internet Software Consortium ... BIND ... Domain Name System Server

Anhang 1: Datei /etc/named.conf (Auszug)

# File /etc/named.conf

options {

  directory "/var/named";
  # ...

  forwarders {
	
     # Dieser Abschnitt enthält die IP-Adressen der Nameserver,
     # an die der lokale Nameserver diejenigen Anfragen
     # weiterschickt, die er nicht selbst beantworten kann.
     # In der Regel sind dies die Nameserver des Providers.

     # Externe Nameserver (Bsp.)
     123.123.123.123;
     234.234.234.234;

     # Wenn ein Router zur Einwahl ins Internet verwendet wird,
     # auf dem ein Nameserver läuft, kann dieser auch als
     # externer Nameserver eingetragen werden (Bsp.):
     # 192.168.0.100

     # ...

  };

};

# zone files (standardmäßig)

zone "." IN {
        type hint;
        file "root.hint";
};

zone "localhost" IN {
	type master;
	file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "127.0.0.zone";
};

# Weitere zone files (für das lokale Netz)

zone "local.netw" IN {
	type master;
        file "localnetw.zone";
};

zone "168.192.in-addr.arpa" IN {
	type master;
        file "localnetw.rev";
};

Anhang 2: Datei /var/named/localnetw.zone

; File /var/named/localnetw.zone
;
; $ORIGIN local.netw
;
$TTL      1D
@         IN SOA      linuxpc.local.netw. root.local.netw. (
                      3       ; serial (bei Aenderungen inkrementieren)
                      3H      ; refresh
                      15M     ; retry
                      1W      ; expire
                      1D )    ; minimum
;
;name server
          IN NS       linuxpc.local.netw.
;
;mail
          IN MX 10    linuxpc.local.netw.
;
;host addresses
;
winpc     IN A        192.168.0.1
linuxpc   IN A        192.168.0.2
otherpc   IN A        192.168.0.3
;
;
;aliases
;
www       IN CNAME    linuxpc
irc       IN CNAME    linuxpc
mail      IN CNAME    linuxpc
ftp       IN CNAME    linuxpc
news      IN CNAME    linuxpc
ntp       IN CNAME    linuxpc

Anhang 3: Datei /var/named/localnetw.rev

; File /var/named/localnetw.rev
;
$TTL      1D
@         IN SOA      linuxpc.local.netw. root.local.netw. (
                      3       ; serial (bei Aenderungen inkrementieren)
                      3H      ; refresh
                      15M     ; retry
                      1W      ; expire
                      1D )    ; minimum
;
; $ORIGIN 168.192.in-addr.arpa.
;
          IN NS       linuxpc.local.netw.
;
1.0       IN PTR      winpc.local.netw.
2.0       IN PTR      linuxpc.local.netw.
3.0       IN PTR      otherpc.local.netw.

Laufen mehrere Rechner zusammen in einem Netzwerk, ist es nach einer Weile etwas irritierend, wenn die Zeitangaben auf diesen Rechnern unterschiedlich sind. Um zum Beispiel Ereignisse in Logdateien auf verschiedenen Rechnern einander zuordnen zu können, ist ein zumindest sekundengenauer Zeitabgleich zwischen den Rechnern wünschenswert.

Da das Nachstellen der Systemzeiten von Hand unerquicklich ist, versucht man, sich diese Arbeit von den Rechnern abnehmen zu lassen. Dieses lässt sich mit den Programmen "netdate" bzw. "ntpdate" oder mit dem NTP-Dämon NTPD bewerkstelligen, die zudem noch die genaue Zeit aus dem Internet beziehen können.

   Programm "netdate"

Das Programm "netdate" holt sich Uhrzeit und Datum von den angegebenen Zeitservern, sucht sich dann den "besten" aus und stellt die Systemzeit nach. Auf welche Weise netdate den "besten" Zeitserver ermittelt, ist in der Manpage zu "netdate" beschrieben.

• Aufruf (weitere Optionen siehe "man netdate"):

    netdate [protocol] hostname...

  wobei für "hostname..." mehrere Zeitserver angegeben werden können und für "protocol" die Protokolle UDP (default) oder TCP.

• "netdate" schickt die Anfrage an Port 37 (Dienst "time") des Zeitservers. Einige Zeitserver lassen nur das Protokoll UDP zu, andere beide Protokolle.

• Den Zeitabgleich kann man nach dem Booten oder auch als Cronjob starten.

• Ein Linux-Rechner beantwortet "netdate"-Anfragen, wenn in der Datei "/etc/xinetd.d/time" der Service "time" aktiviert ist.

  Damit Änderungen in dieser Datei wirksam werden, muss der "xinetd" mit dem Kommando "rcxinetd restart" neu gestartet werden.

• Soll der Linux-PC auch "time"-Anfragen aus dem Internet beantworten können, müssen die entsprechenden Ports in der Firewall geöffnet werden.

• Die Systemzeit wird durch "netdate" unmittelbar auf den neuen Wert eingestellt. Dadurch können jedoch Sprünge in der Systemzeit verursacht werden. Der nachfolgend beschriebene NTPD hingegen führt die Zeit langsam nach, so dass keine Zeitsprünge vorkommen können. Zudem ist der NTPD genauer.

   Installation und Einrichtung des Timeservers NTPD

Der Dämon NTPD ist zugleich Zeitserver und -client. Aus mehreren vorgegeben Zeitservern sucht er sich die "beste" Quelle aus, stellt die Systemzeit mit und stellt die Zeit als Server wieder für andere Rechner zur Verfügung. Die Zeitabstände des Abgleichs mit anderen Zeitservern werden selbsttätig optimiert. Im Gegensatz zu "netdate" wird die Systemzeit nicht abrupt verstellt, sondern langsam nachgeführt, so dass keine Sprünge in der Systemzeit entstehen können.

Mit im Paket "xntp" enthalten ist das Programm "ntpdate", das ähnlich wie "netdate" die Systemzeit durch einen einmaligen Aufruf mitstellt.

• Mit YaST das Paket xntp (n) installieren.

• Leider gibt es keine Manpages zu den einzelnen Programmen und Dateien. Im Verzeichnis "/usr/share/doc/packages/xntp" befinden sich einige Hinweise.

  Die aktuellen Programme und Dokumentationen befinden sich auf der NTP-Homepage http://www.ntp.org.

• Anpassung der Konfigurationsdatei "/etc/ntp.conf":

    # Timeserver (Hostnamen durch Zeitserver ersetzen)
    server abc.timeserver1.de
    server def.timeserver1.de
    server klm.timeserver2.de
    server uvw.timeserver3.de
    server xyz.timeserver3.de
    # ...
  
    # Hardwareuhr des Rechners
    server 127.127.1.0
    fudge 127.127.1.0 stratum 10
  
    # Files
    driftfile /var/lib/ntp/drift/ntp.drift
    logfile /var/log/ntp

  • Im ersten Abschnitt sind die Zeitserver eingetragen, von denen der NTPD die aktuelle Zeit beziehen soll. Dieses können Internetserver, aber auch lokale Server sein.

  • Im zweiten Abschnitt wird die Uhr des Rechners selbst eingetragen, auf die der NTPD dann zugreift, wenn keine externen Hosts erreichbar sind. Mit "fudge" (engl. "zurechtpfuschen", "schwindeln") wird dem NTPD mitgeteilt, dass die lokale Hardwareuhr nur als Notlösung anzusehen ist. Dabei ist der "Stratum"-Wert die Position eines NTPD in der Kette mehrerer Zeitserver. Eine exakte Zeitquelle wie eine Funkuhr hat den Stratum-Wert "0", der erste NTPD, der diese Zeitquelle verwendet, den Stratum-Wert "1". Der zweite NTPD, der den ersten als Zeitquelle verwendet, hat dann den Stratum-Wert "2" usw. Die eigene Rechneruhr wird also mit der Zuweisung des Stratum-Wertes "10" als so ungenau eingestuft, dass der NTPD sie nur verwendet, wenn er keine bessere Zeitquelle findet.

  • Die Datei "ntp.drift" im dritten Abschnitt enthält einen Wert, der die Gangungenauigkeit der Hardwareuhr des Rechners wiedergibt. Der NTPD ermittelt beim ersten Start diesen Wert und schreibt ihn nach etwa 15-30 Minuten in diese Datei. Erst nachdem der NTPD diese Datei erstellt hat, arbeitet er auch als Zeitserver. Bei den folgenden Aufrufen ist diese Datei bereits vorhanden, und der NTPD arbeitet sofort als Zeitserver.

  • Verfügt der Rechner selbst über ein Zeitnormal wie z.B. eine DCF77-Funkuhr oder einen GPS-Empfänger, kann auch dieser in die Konfigurationsdatei eingetragen werden. Näheres dazu steht in der Default-Konfigurationsdatei.

• Steuerung des Servers:

  Aufruf mit dem Start-/Stop-Skript:

  • rcxntpd start
  • rcxntpd stop
  • rcxntpd status
  • rcxntpd restart

  Der Server kann auch mit dem Kommando "ntpd" gestartet werden. Mit dem Aufruf "ntpd -d" (Debug-Mode) gibt der Server zahlreiche Kontrollausgaben aus. Der Aufruf "xntpd" ist ein symbolischer Link für "ntpd".

• Mit "insserv xntpd" wird der Server beim Booten mit gestartet.

• Der NTPD verwendet den Dienst "ntp" (Port 123) mit dem Protokoll UDP. Die zugehörige Firewall-Variable muss also um "ntp" ergänzt werden:

    FW_SERVICES_EXT_UDP = "ntp"

Mit dieser Konfiguration stellt der NTPD Systemzeit und -datum auf die Werte ein, die er von den Zeitservern aus dem Internet bezieht.

   Weitere Programme zum Timeserver NTPD

Im Paket "xntp" sind u.a. die folgenden weiteren Programme enthalten:

• Das Programm "ntpdate" stellt ähnlich wie "netdate" die Systemzeit direkt nach. Es lässt sich nur aufrufen, wenn der Zeitserver NTPD nicht läuft.

• "ntpq" und "ntpdc" sind interaktive NTP-Abfrageprogramme. Werden sie ohne Parameter aufgerufen, bekommt man mit "help" die zur Verfügung stehenden Kommandos aufgelistet. "help <cmd>" gibt Hilfen zu den einzelnen Kommandos aus. Die beiden Programme lassen sich mit Parametern auch direkt aufrufen. Beispiele:

  • ntpq/ntpdc -p: Angaben über die vom NTPD verwendeten Zeitserver

• Weitere Programme sind:

  • ntptime: Kernel-Time-Variablen auslesen
  • ntptrace: Gibt die Kette der Zeitserver aus

   Zeitserver für das lokale Netz

Der so eingerichtete NTPD kann nun als Zeitserver für die Rechner des lokalen Netzes dienen. Damit braucht sich nicht jeder Rechner die Zeit aus dem Internet zu holen, sondern kann den lokalen Zeitserver verwenden.

• Um den lokalen Zeitserver von den anderen Rechnern im LAN mit Namen ansprechen zu können, kann man einen Alias-Namen (z.B. "ntp1") in die Zone-Datei des Nameserves eintragen. Der lokale Zeitserver ist dann z.B. mit mit "ntp1.local.netw" ansprechbar.

• Auf jedem weiteren Linux-Rechner im LAN wird das Paket "xntp (n)" installiert wie oben beschrieben. In die Konfigurationsdatei "/etc/ntp.conf" werden als Server nur der lokale Zeitserver und die Hardwareuhr eingetragen:

    server ntp1.local.netw
    server 127.127.1.0
    fudge 127.127.1.0 stratum 10
    driftfile /var/lib/ntp/drift/ntp.drift
    logfile /var/log/ntp

• NTP-Clients für die verschiedensten Betriebssysteme sind auf der NTP-Homepage aufgeführt, so dass sich zum Beispiel auch die Windows-PCs im LAN mit dem lokalen Zeitserver automatisch synchronisieren können.

• Windows-PCs können ihre Systemzeit auch mit dem Kommando "net time" mit dem Samba-Server auf dem Linux-PC abgleichen.

   Hardwareuhr und Systemzeit

Linux verwendet die Hardwareuhr des Rechners nur beim Booten, um nach den Angaben der Hardwareuhr die Systemzeit zu setzen. Danach führt Linux die Systemzeit unabhängig von der Hardwareuhr weiter.

Mit dem Kommando "hwclock -r" kann man die Angaben der Hardwareuhr auslesen. Mit der Zeile "hwclock -r ; date" kann man also die Hardwareuhr nahezu unmittelbar mit der Systemzeit vergleichen.

Beim Start des Linux-Rechners können die Hardware- und Systemzeit um einen größeren Wert voneinander abweichen. Ist dieser Wert größer als 1000s, geht der NTPD davon aus, dass ein systematischer Fehler vorliegt, korrigiert die Systemzeit nicht und beendet sich mit einer Warnung. Liegt die Abweichung darunter, führt der NTPD die Systemzeit langsam nach, was einige Zeit dauern kann.

In der Dokumentation wird deshalb empfohlen, vor dem Start des NTPD zuerst das Kommando "ntpdate" aufzurufen, um die Systemzeit sofort zu setzen, wenn auch möglicherweise etwas ungenau, und erst danach den NTPD zu starten, der die kleine Ungenauigkeit dann stetig korrigiert.

Bei laufendem Betrieb des NTPD kann "ntpdate" nicht aufgerufen werden, "netdate" jedoch wohl, so dass man auch den NTPD schon beim Booten starten und dann mit "netdate", falls nötig, die Systemzeit unmittelbar nachstellen kann, wenn der Rechner Online geht.

"ntpdate" verändert die Hardwareuhr nicht, der NTPD hingegen wohl, wenn er "meint", dass die genaue Zeit ermittelt ist. Durch diese ständige Nachführung der Hardwareuhr steht beim nächsten Booten wieder die bestmögliche Zeit zur Verfügung.

Die beschriebenen Vorgänge lassen sich gut verfolgen, wenn man den NTPD beendet, die Systemzeit mit "date" absichtlich etwas falsch setzt und dann die falsche Systemzeit mit "hwclock -w" (bzw. "hwclock -wu", falls die Hardwareuhr die UTC verwendet) in die Hardwareuhr überträgt. Die Zeitkorrekturen nach den Aufrufen "ntpdate" bzw. "netdate" oder dem Start des NTPD kann man dann mit "hwclock -r ; date" schön verfolgen.

   Zeitserver im Internet

Im Internet gibt es viele öffentliche Zeitserver. Auch größere Einwahlprovider sollten die Zeit über Zeitserver zur Verfügung stellen.

Eine Liste mit öffentlichen Zeitservern befindet sich auf der NTP-Homepage http://www.ntp.org. Dort sind auch die Zeitserver der Physikalisch-Technischen Bundesanstalt (PTB) aufgeführt, die in Deutschland mit der "Darstellung und Verbreitung der gesetzlichen Zeit" beauftragt ist.

Um einzelne Zeitserver nicht zu überlasten, gibt es einen Pool von Zeitservern. Anstelle von bestimmten Zeitservern werden aus einem weltweiten Pool zufällige Zeitserver ausgewählt. Dazu trägt man in die Datei "/etc/ntp.conf" ein:

  server 0.pool.ntp.org
  server 1.pool.ntp.org
  server 2.pool.ntp.org

Möchte man die zufällig ausgewählten Zeitserver auf Europa beschränken, um die Zeit durch kürzere Entfernungen etwas genauer zu synchronisieren, kann man in die Datei "/etc/ntp.conf" eintragen:

  server 0.europe.pool.ntp.org
  server 1.europe.pool.ntp.org
  server 2.europe.pool.ntp.org
  server 3.europe.pool.ntp.org

Die Genauigkeit der Synchronisation liegt im Bereich von Millisekunden.

   Links

http://www.ntp.org   NTP-Homepage

Im Laufe der Zeit wird der so schön eingerichtete Linux-PC immer unentbehrlicher, so dass früher oder später die Frage auftaucht, was man denn eigentlich macht, wenn das System z.B. durch einen Ausfall der Festplatte plötzlich nicht mehr verfügbar sein sollte.

Mit dem Kommando "tar" kann man zumindest Backups der wichtigsten Verzeichnisse (wie "/etc", "/root", "/home" usw.) und veränderlichen Dateien (z.B. in "/var") erstellen, so dass man das System durch eine Neuinstallation und das Zurückkopieren der gesicherten Dateien wieder herstellen kann.

Aufwendigere Absicherungen wie ausfallsichere Server, Hochverfügbarkeitssysteme oder professionelle Datensicherungen kommen aus Zeit- und Kostengründen oft nicht in Betracht, besonders nicht im häuslichen Netzwerk. Zudem ist die Wiederherstellung eines Systems aus den Datensicherungen zeitaufwendig.

Hat man auf einem der Linux-PCs im Netzwerk noch ausreichend Platz übrig, kann man den Server auch komplett "spiegeln". Fällt der Server-Rechner dann aus, kann das gespiegelte System diesen nach wenigen Minuten ersetzen. Läuft der Server dann wieder, kann umgekehrt das Originalsystem aus dem gespiegelten System wieder hergestellt werden.

Eine reguläre Datensicherung, bei dem die Backup-Datenträger mit verschiedenen Sicherungsständen an sicheren Orten aufbewahrt werden, ersetzt dieses Verfahren natürlich nicht.

Die Idee zu einem gespiegelten Server stammt aus dem Artikel "Server-Spiegelei" von Conny Dittmann, erschienen im Linux-Magazin Heft 4/2002, S. 99.

   Verzeichnisse einrichten bzw. kopieren

Das Verfahren wird hier an einem Beispiel beschrieben (s. Bild 1). Auf dem Rechner PC1 befindet sich das System "pc1", bestehend aus der Boot- und der Root-Partition. Auf dem Rechner PC2 befindet sich ein Grundsystem "pc2", das ebenfalls aus einer Boot- und einer Root-Partition besteht. Zusätzlich befinden sich auf dem Rechner PC2 zwei freie Partitionen hda2 und hda6.

Das Linux-System "pc1" (Quellsystem) auf dem Rechner PC1 soll nun zum Rechner PC2 gespiegelt werden, so dass das gespiegelte System "pmirr" (Zielsystem) entsteht.

Wie in Bild 1 dargestellt, wird zuerst das System "pc1" zum Rechner PC2 in das Unterverzeichnis "/pc1m" kopiert. Zum Erstellen dieser 1:1-Kopie wird das Programm "rsync" zum Synchronisieren von Verzeichnissen verwendet. Anschließend wird das gespiegelte System "pmirr" gebootet. Das vollständige Skript zur Einrichtung des Zielsystems befindet sich auf dieser Seite im Anhang 1.

Die Schritte sind im einzelnen:

• Auf PC2 stehen neben dem bereits installierten Grundsystem zwei leere Partitionen zur Verfügung, die groß genug sind, die Verzeichnisse "/boot" und "/" des Quellsystems aufzunehmen:

    /dev/hda2    (soll pc1:/boot des Quellsystems aufnehmen)
    /dev/hda6    (soll pc1:/     des Quellsystems aufnehmen)

  Besteht das Quell- oder Zielsystem aus weiteren Partitionen, muss diese Aufteilung natürlich entsprechend angepasst werden.

• Für das Zielsystem werden auf PC2 zwei Verzeichnisse eingerichtet und die Partitionen gemountet:

    pc2:/pc1m/boot für /dev/hda2      (= pmirr:/boot)
    pc2:/pc1m/root für /dev/hda6      (= pmirr:/    )

• Der Inhalt der Boot-Partition des Quellsystems wird in die Boot-Partition des Zielsystems kopiert:

    pc1:/boot  nach   pc2:/pc1m/boot  (= pmirr:/boot)

• Die folgenden Verzeichnisse bzw. Mountpoints werden auf dem Zielsystem nur eingerichtet (je nach den Verzeichnissen des Quellsystems):

    pc2:/pc1m/root/boot               (= pmirr:/boot)
    pc2:/pc1m/root/media              (= pmirr:/media)
    pc2:/pc1m/root/media/cdrom        (= pmirr:/media/cdrom)
    pc2:/pc1m/root/media/floppy       (= pmirr:/media/floppy)
    pc2:/pc1m/root/lost+found         (= pmirr:/lost+found)
    pc2:/pc1m/root/mnt                (= pmirr:/mnt)
    pc2:/pc1m/root/proc               (= pmirr:/proc)

• Die folgenden Verzeichnisse werden vom Quell- in das Zielsystem kopiert (je nach den Verzeichnisses des Quellsystems):

    pc1:/bin   nach   pc2:/pc1m/root/bin   (= pmirr:/bin)
    pc1:/dev    "     pc2:/pc1m/root/dev   (= pmirr:/dev)
    pc1:/etc    "     pc2:/pc1m/root/etc   (= pmirr:/etc)
    pc1:/home   "     pc2:/pc1m/root/home  (= pmirr:/home)
    pc1:/lib    "     pc2:/pc1m/root/lib   (= pmirr:/lib)
    pc1:/opt    "     pc2:/pc1m/root/opt   (= pmirr:/opt)
    pc1:/root   "     pc2:/pc1m/root/root  (= pmirr:/root)
    pc1:/sbin   "     pc2:/pc1m/root/sbin  (= pmirr:/sbin)
    pc1:/srv    "     pc2:/pc1m/root/srv   (= pmirr:/srv)
    pc1:/sys    "     pc2:/pc1m/root/sys   (= pmirr:/sys)
    pc1:/tmp    "     pc2:/pc1m/root/tmp   (= pmirr:/tmp)
    pc1:/usr    "     pc2:/pc1m/root/usr   (= pmirr:/usr)
    pc1:/var    "     pc2:/pc1m/root/var   (= pmirr:/var)

  Weitere eigene Verzeichnisse können hinzu kommen wie z.B.

    pc1:/bak   nach   pc2:/pc1m/root/bak   (= pmirr:/bak)
    pc1:/test   "     pc2:/pc1m/root/test  (= pmirr:/test)
    usw.

  In der Datei /etc/fstab ist das Dateisystem festgelegt. Da dieses zwischen Quell- und Zielsystem unterschiedlich ist, wird diese Datei nur einmal bei der Einrichtung des Zielsystems vom Grundsystem des PC2 kopiert.

    pc2:/etc/fstab      nach   pc2:/pc1m/root/etc/fstab

  Diese Datei muss dann entsprechend den Partitionen des Zielsystems angepasst werden. Bei den weiteren Synchronisierungen zwischen Quell- und Zielsystem wird diese Datei nicht mitkopiert (siehe Skript).

• Für die Ausführung der Spiegelung mit Hilfe eines Skripts ist es sinnvoll, den Public Key für "ssh" auf dem Quellsystem zu hinterlegen. Dadurch erspart man sich die Eingabe des root-Passwortes bei jedem "rsync"-Aufruf.

• Das Kommando "rsync" wird noch mit der zusätzlichen Option "--numeric-ids" aufgerufen, damit die User- und Group-IDs der Dateien des Zielsystems mit denen des Quellsystems übereinstimmen. Ohne diese Option ordnet "rsync" die User- und Group-IDs nach den Namen zu, nicht nach den Nummern. So könnte es z.B. zu falschen User-IDs bei Verzeichnissen und Dateien auf dem Zielsystem kommen, wenn ein User sowohl auf dem Quellsystem als auch auf dem Grundsystem vorhanden ist, jedoch auf beiden Systemen verschiedene User-IDs hat.

• Die "rsync"-Option "--delete-after" bewirkt, dass Dateien auf dem Zielsystem erst nach der Synchronisierung gelöscht werden. Für diese Option muss das Zielsystem über ausreichenden Plattenplatz verfügen.

• Befinden sich das Quell- und Zielsystem auf verschiedenen Rechnern, sind auch die Netzwerkkarten unterschiedlich. In diesem Fall muss man die Netzwerkeinstellungen des Zielsystems neu vornehmen. Man kann diese Neueinstellungen nach dem erstmaligen Kopieren auch einmal vornehmen und bei den weiteren Spiegelungen die Verzeichnisse, in denen die Netzwerkkonfiguration festgelegt ist, von der Spiegelung ausnehmen, indem man die Zeile im Skript, in der das Verzeichnis /etc kopiert wird, erweitert. z.B. um

    --exclude=/etc/sysconfig/network/ifcfg-eth-id-*

  Welche Dateien bzw. Verzeichnisse von den Spiegelungen auszunehmen sind, ist systemabhängig. Befinden sich Quell- und Zielsystem auf demselben Rechner, ist diese Ausnahme nicht notwendig.

Das Skript für die Spiegelung muss an die tatsächlichen Gegebenheiten angepasst und kann dann gestartet werden. Das Kopieren kann man auf der Konsole verfolgen. Man staunt schon über die Anzahl der Dateien, die auf dem System vorhanden sind. Mit dem Kommando "df" kann man sich auf einer anderen Konsole ansehen, wie sich die Partitionen nach und nach "füllen". Je nach PCs und Netzwerkverbindung dauert das erstmalige Kopieren auch einige Zeit.

Das Zielsystem kann dann in regelmäßigen Zeitabständen mit dem Quellsystem synchronisiert werden. Diese Synchronisierungen gehen dann erheblich schneller, da "rsync" nur die Unterschiede zwischen den Systemen überträgt.

Anmerkung: In dem gezeigten Beispiel erfolgt das Kopieren aus dem laufenden System heraus. Im ungünstigsten Fall (wenn z.B. gerade Datensätze in eine Datenbank geschrieben werden) kann das gespiegelte System inkonsistent sein. Mögliche Abhilfen:

• Sicherung der Datenbanken usw. auf reguläre Weise, damit die Daten ordnungsgemäß wieder hergestellt werden können. Diese Sicherung sollte unabhängig von der Spiegelung sowieso vorgenommen werden.

• Stoppen der entsprechenden Server vor dem Start der Spiegelung.

• Ausführung der Spiegelung, indem auf beiden Rechnern Grundsysteme installiert und gestartet werden. Dann kann das Quellsystem als "ruhendes" System kopiert werden. Befinden sich das Quell- und Zielsystem auf demselben Rechner, wird das Quellsystem in jedem Fall als ruhendes System kopiert, da erst das Grundsystem gestartet werden muss.

Hinweis: Wenn man aus irgendwelchen Gründen im Zielsystem Verzeichnisse wieder löschen will und sich dabei z.B. im Verzeichnis /pc1m/root befindet, also am Prompt z.B. eingibt:

  pc2:/pc1m/root # rm -r etc

sollte man darauf achten, dass man vor dem zu löschenden Verzeichnis kein "/" angibt, weil sonst das Verzeichnis des Grundsystems gelöscht wird!

   Booten des gespiegelten Systems

Nachdem das Quellsystem kopiert und die Datei /etc/fstab von Hand angepasst ist, muss das Zielsystem noch mit "Grub" bootbar gemacht werden.

Dazu muss das Zielsystem in der Datei "/boot/grub/menu.lst" des Systems pc2 hinzugefügt werden, z.B.

  title Gespiegeltes System
  kernel (hd0,1)/vmlinuz root=/dev/hda6 vga=0x317 selinux=0 \
          splash=silent resume=/dev/hda5  showopts
  initrd (hd0,1)/initrd

Es ist sinnvoll, einfacher und schneller, das Zielsystem vor der ersten Spiegelung auf normale Weise zu installieren. Bei der ersten Spiegelung brauchen dann nur die Änderungen übertragen zu werden. Außerdem wird die grub-Bootloader-Konfiguration bei der Installation automatisch um das Zielsystem ergänzt und die Datei fstab richtig erzeugt.

Bevor man das Ersatzsystem startet, muss das Quellsystem auf PC1 zunächst vom Netz getrennt werden, denn das gespiegelte System hat dieselbe IP-Adresse wie das Quellsystem, so dass es zur Kollision käme, wenn beide Systeme gleichzeitig am Netz liefen.

Das Ersatzsystem sollte nun genauso funktionieren wie das ursprüngliche System.

   Anmerkungen

Ein solches gespiegeltes System hat weitere Vorteile:

• Die Spiegelung des Servers kann nicht nur im lokalen Netz, sondern auch über das Internet erfolgen. Entfernte Standorte der beiden Rechner erhöhen zusätzlich die Ausfallsicherheit.

• Stehen weitere Linux-PCs zur Verfügung, kann man das Originalsystem auch mehrfach sichern. Umgekehrt kann man auf einem System mit genügend großer Festplatte auch mehrere Systeme sichern.

• Wichtige Daten wie das "/home"-Verzeichnis lassen sich öfter sichern als das Gesamtsystem.

• Sind die Platten in beiden Rechnern in auswechselbaren Halterungen (Quick-Out-Halterungen), braucht man bei einem Festplattencrash nur die Platte auszuwechseln, um das System wieder einsatzbereit zu machen.

• Anstelle des laufenden Originalsystems kann man auch das gespiegelte "eingefrorene System" in einem konsistenten Zustand sichern.

• Ein gespiegeltes System bietet die Möglichkeit, beliebige Änderungen ohne Rücksicht auf die Folgen zu testen. Nach den Experimenten synchronisiert man das Testsystem einfach wieder mit dem Originalsystem. Ist die Festplatte im Zielrechner groß genug, kann man das Originalsystem auch mehrfach auf dieser Platte sichern und eines der gespiegelten Systeme als Testsystem verwenden.

In meinem lokalen Netz wird der Hauptserver/-router regelmäßig auf einen anderen Server gespiegelt. Durch Starten des Ersatzsystems und Umstecken der Ethernetverbindungen ist man nach wenigen Minuten wieder am Netz. Das gespiegelte System funktioniert einwandfrei.

Anhang 1: Skript zum Spiegeln eines Linux-Systems

#!/bin/sh
# Skript zum Spiegeln von PC1 nach PC2.
# Dieses Skript muß an die jeweiligen Gegebenheiten angepasst werden.
# Nach der Anpassung die folgende Zeile entfernen:
exit 1

# Nach Ausführung dieses Skripts muss die Datei /etc/fstab
# des pc2-Grundsystems kopiert und von Hand angepasst werden.

# Dieses Skript soll nur auf PC2 laufen
if [ "$HOSTNAME" != "pc2" ]; then
  echo "Aufruf '$0' nur auf PC2 zulässig"
  exit 1
fi

# Variablen
rscmd="rsync -az -v --numeric-ids --delete --delete-after -e ssh"
rhost="pc1.local.netw:"
mboot="/pc1m/boot"
mroot="/pc1m/root"

# Mirror-Partitionen auf PC2 mounten:
mount /dev/hda2 $mboot
mount /dev/hda6 $mroot

# Systemverzeichnisse nur einrichten:
test ! -d $mroot/boot && (mkdir $mroot/boot; chmod 755 $mroot/boot)
test ! -d $mroot/media && (mkdir $mroot/media; chmod 755 $mroot/media)
test ! -d $mroot/media/cdrom && (mkdir $mroot/media/cdrom; chmod 755 $mroot/media/cdrom)
test ! -d $mroot/media/floppy && (mkdir $mroot/media/floppy; chmod 755 $mroot/media/floppy)
test ! -d $mroot/lost+found && (mkdir $mroot/lost+found; chmod 755 $mroot/lost+found)
test ! -d $mroot/mnt && (mkdir $mroot/mnt; chmod 755 $mroot/mnt)
test ! -d $mroot/proc && (mkdir $mroot/proc; chmod 555 $mroot/proc)

# Systemverzeichnisse kopieren:
$rscmd  $rhost/boot  /pc1m
$rscmd  $rhost/bin   /pc1m/root
$rscmd  $rhost/dev   /pc1m/root
# Nächste Zeile evt. um --exclude=/etc/sysconfig/network/ifcfg-eth-id-* ergänzen (s. Text)
$rscmd  $rhost/etc   /pc1m/root --exclude=/etc/fstab
$rscmd  $rhost/home  /pc1m/root
$rscmd  $rhost/lib   /pc1m/root
$rscmd  $rhost/opt   /pc1m/root
$rscmd  $rhost/root  /pc1m/root
$rscmd  $rhost/sbin  /pc1m/root
$rscmd  $rhost/srv   /pc1m/root
$rscmd  $rhost/sys   /pc1m/root
$rscmd  $rhost/tmp   /pc1m/root
$rscmd  $rhost/usr   /pc1m/root
$rscmd  $rhost/var   /pc1m/root

# Anwenderverzeichnisse kopieren:
$rscmd  $rhost/bak   /pc1m/root
$rscmd  $rhost/test  /pc1m/root

# Mirror-Partitionen wieder unmounten:
umount $mboot
umount $mroot

exit 0