Die manuelle Konfiguration der Netzwerksoftware sollte stets die zweite Wahl sein. Wir empfehlen, YaST zu benutzen. Das Wissen um die Hintergründe der Netzwerkkonfiguration wird Ihnen auch die Arbeit mit YaST erleichtern.
Jede Netzwerkkarte — egal ob fest eingebaut oder Hotpluggerät (PCMCIA, USB, teilweise auch PCI) — wird mittels Hotplug erkannt und eingerichtet. Eine Netzwerkkarte erscheint dem System auf zwei verschiedene Weisen: Einmal ist sie ein physikalisches Gerät (engl. device), zum anderen fungiert sie als Schnittstelle (engl. interface). Das Einstecken oder das Erkennen des Gerätes löst ein Hotplugevent aus. Dieses Hotplugevent löst dann die Initialisierung des Gerätes über das Skript /sbin/hwup aus. Mit der Initialisierung der Netzwerkkarte als neues Netzwerkinterface erzeugt der Kernel ein weiteres Hotplugevent. Dieses löst dann die Einrichtung des Interfaces mittels /sbin/ifup aus.
Der Kernel nummeriert Interfacenamen entsprechend der zeitlichen Reihenfolge ihrer Registrierung durch. Die Initialisierungsreihenfolge ist entscheidend für die Namensgebung. Fällt bei mehreren Netzwerkkarten die erste aus, verschiebt sich die Nummerierung aller danach initialisierten Karten. Bei echt hotplugfähigen Karten entscheidet die Reihenfolge, in welcher die Geräte angeschlossen wurden.
Um eine flexible Konfiguration zu ermöglichen, wurde einerseits die
Konfiguration von Gerät (Hardware) und Interface getrennt und andererseits
die Zuordnung von Konfigurationen zu Geräten bzw. Interfaces nicht mehr über
die Interfacenamen geregelt. Die Konfigurationen für Geräte befinden sich
unter /etc/sysconfig/hardware/hwcfg-*, während sich die
Interfacekonfigurationen unter
/etc/sysconfig/network/ifcfg-* befinden. Die Namen der
Konfigurationen sind so gewählt, dass sie die Geräte bzw. Interfaces, zu
denen sie gehören, beschreiben. Da die frühere Zuordnung von Treibern zu
Interfacenamen gleichbleibende Interfacenamen voraussetzt, kann diese
Zuordnung nicht mehr in /etc/modprobe.conf geschehen.
Alias-Einträge in dieser Datei würden mit dem neuen Konzept sogar zu
unerwünschten Nebeneffekten führen.
Die Konfigurationsnamen, also alles, was auf hwcfg- oder
ifcfg- folgt, können die Geräte durch den Einbauort, eine
gerätespezifische ID oder auch durch den Interfacenamen beschreiben. Für eine
PCI-Karte kann das beispielsweise bus-pci-0000:02:01.0
(PCI-Slot) oder vpid-0x8086-0x1014-0x0549 (Vendor- und
Produkt-ID) sein. Für das dazugehörige Interface kann ebenfalls
bus-pci-0000:02:01.0 oder aber
wlan-id-00:05:4e:42:31:7a (MAC-Adresse) verwendet werden.
Will man eine bestimmte Netzwerkkonfiguration nicht einer ganz bestimmten
Karte sondern einer beliebigen Karte eines bestimmten Typs (von der immer nur
eine zu einer Zeit eingesteckt ist) zuweisen, wählt man die
Konfigurationsnamen weniger spezifisch. So würde z.B.
bus-pcmcia für alle PCMCIA-Karten verwendet werden.
Andererseits können die Namen durch Voranstellen eines Interfacetyps
eingeschränkt werden. So würde wlan-bus-usb allen
WLAN-Karten, die über USB angeschlossen sind, zugewiesen werden.
Es wird immer diejenige Konfiguration verwendet, die ein Interface oder das Gerät, das das Interface zur Verfügung stellt, am besten beschreibt. Die Suche nach der besten Konfiguration wird von /sbin/getcfg erledigt. Die Ausgabe von getcfg liefert alle Information, die sich zur Beschreibung eines Geräts verwenden lässt. Die genaue Spezifikation der Konfigurationsnamen befindet sich in der Manualpage zu getcfg.
Nach der beschriebenen Methode lässt sich ein Netzwerkinterface zuverlässig mit der richtigen Konfiguration einrichten, selbst wenn die Netzwerkgeräte nicht immer in derselben Reihenfolge initialisiert werden. Nach wie vor bleibt allerdings das Problem bestehen, dass der Name des Interfaces immer noch von der Initialisierungsreihenfolge abhängt. Soll dennoch zuverlässig auf das Interface einer bestimmten Netzwerkkarte zugegriffen werden, gibt es zwei Wege, dies zu erreichen:
/sbin/getcfg-interface
liefert den Namen des zugehörigen Netzwerkinterfaces zurück. Deshalb ist es
auch möglich, in manchen (aber noch nicht in allen) Konfigurationsdateien
von Netzwerkdiensten statt dem Interfacenamen (der nicht persistent ist)
den Konfigurationsnamen wie Firewall,
dhcpd, Routing oder diverse virtuelle Netzwerkinterfaces
(Tunnel) einzutragen.
Konfigurationsname
Für alle Interfaces, deren Konfiguration nicht mit den Interfacenamen
benannt ist, kann ein persistenter Interfacename vergeben werden. Dies
erreicht man durch Eintragen von
PERSISTENT_NAME= in
eine Interfacekonfiguration (pnameifcfg-*). Der persistente
Name pname darf aber nicht ein Name sein, der
auch vom Kernel automatisch vergeben würde. Also sind
eth*, tr*, wlan*,
qeth*, iucv* usw. nicht erlaubt.
Stattdessen bieten sich beispielsweise net* oder
beschreibende Namen wie extern,
intern oder dmz an. Die persistenten
Namen werden einem Interface nur unmittelbar nach der Registrierung
desselben vergeben, d.h. der Treiber der Netzwerkkarte muss dazu neu geladen
(bzw. hwup
Gerätebeschreibung
aufgerufen) werden. Ein rcnetwork
restart reicht dazu nicht aus.
![]() | Persistente Interfacenamen verwenden |
|---|---|
Bitte beachten Sie, dass die Verwendung persistenter Interfacenamen noch nicht in allen Bereichen getestet wurde. Es kann vorkommen, dass bestimmte Applikationen mit frei gewählten Interfacenamen nicht zurechtkommen. Bitte informieren Sie uns über solche Fälle via http://www.suse.de/feedback. | |
ifup initialisiert nicht die Hardware, sondern setzt ein
bereits existierendes Interface voraus. Zur Hardwareinitialisierung gibt es
hwup, was von hotplug (bzw.
coldplug) aufgerufen wird. Sobald ein Gerät initialisiert
wird, wird aber via hotplug automatisch
ifup für das neue Interface aufgerufen und falls der
Startmode onboot, hotplug oder
auto ist und der Service network
gestartet wurde, auch aufgesetzt. Früher war es üblich, dass ein
ifup interfacename die
Hardwareinitialisierung anstieß. Jetzt ist die Vorgehensweise genau
umgekehrt. Zuerst wird ein Stück Hardware zu initialisiert; alle folgenden
Aktionen ergeben sich daraus. Dadurch ist es möglich, mit einem bestehenden
Konfigurationsset eine veränderliche Menge von Geräten immer optimal
einzurichten.
Der besseren Übersicht wegen sind die wichtigsten an der Netzwerkkonfiguration beteiligten Skripten in Tabelle 22.5, „Skripten zur manuellen Netzwerkkonfiguration“ zusammengefasst. Wenn möglich, wurde nach Hardware- bzw. Interfaceaspekt getrennt:
Tabelle 22.5. Skripten zur manuellen Netzwerkkonfiguration
Ebene | Befehl | Funktion |
|---|---|---|
Hardware | hwup, hwdown, hwstatus |
Die |
Interface | getcfg | Mit getcfg fragen Sie den zu einem Konfigurationsnamen oder einer Hardwarebeschreibung zugehörigen Interfacenamen ab. Weitere Informationen sind in der Manualpage von getcfg erhältlich. |
Interface | ifup, ifdown, ifstatus |
Die |
Mehr Informationen zum Thema Hotplug und persistente Gerätenamen lesen Sie in Kapitel 18, Das Hotplug-System und Kapitel 19, Dynamische Device Nodes mit udev nach.
Dieser Abschnitt gibt eine Übersicht über die Netzwerkkonfigurationsdateien und erklärt ihre Funktion sowie das verwendete Format.
In diesen Dateien befinden sich die Hardwarekonfigurationen von
Netzwerkkarten und anderen Geräten. Sie enthalten die notwendigen Parameter
wie Kernelmodul, Startmodus und Skriptzuordnungen. Details hierzu finden
Sie in der Manualpage zu hwup. Die Konfigurationen
hwcfg-static-* werden beim Start von Coldplug
unabhängig von vorhandener Hardware angewendet.
Diese Dateien enthalten die Konfigurationen für Netzwerkinterfaces. Sie
enthalten unter anderem den Startmodus und die IP-Adresse. Die möglichen
Parameter sind in der Manualpage von ifup beschrieben.
Es können außerdem alle Variablen aus den Dateien
dhcp, wireless und
config in den ifcfg-*-Dateien
verwendet werden, wenn eine sonst allgemeine Einstellung nur für ein
Interface verwendet werden soll.
Die Datei config enthält allgemeine Einstellungen zum
Verhalten von ifup, ifdown und
ifstatus. Sie ist vollständig kommentiert. Ebenso gibt
es Kommentare in dhcp und
wireless, wo allgemeine Einstellungen zu DHCP und
Funknetzwerkkarten Platz finden. Alle Variablen aus diesen Dateien können
auch in ifcfg-* verwendet werden und haben dort
Vorrang.
Hier wird das statische Routing von TCP/IP-Paketen festgelegt.
In der Datei /etc/sysconfig/network/routes können alle
statischen Routen eingetragen werden, die für die verschiedenen Aufgaben
eines Systems benötigt werden könnten: Route zu einem Rechner, Route zu einem
Rechner über ein Gateway und Route zu einem Netzwerk.
Für alle Interfaces, die individuelles Routing benötigen, kann dies jeweils
in einer eigenen Datei pro Interface definiert werden:
/etc/sysconfig/network/ifroute-*. Für das Zeichen
* muss die Interface-Bezeichnung eingesetzt
werden. Die Einträge können folgendermaßen aussehen:
DESTINATION GATEWAY NETMASK INTERFACE [ TYPE ] [ OPTIONS ] DESTINATION GATEWAY PREFIXLEN INTERFACE [ TYPE ] [ OPTIONS ] DESTINATION/PREFIXLEN GATEWAY - INTERFACE [ TYPE ] [ OPTIONS ]
Falls GATEWAY, NETMASK, PREFIXLEN oder INTERFACE nicht angegeben werden, muss
an ihrer Stelle das Zeichen - gesetzt werden. Die Einträge
TYPE und OPTIONS können schlicht entfallen.
In der ersten Spalte steht das Ziel einer Route. Dabei kann dort die IP-Adresse eines Netzes oder Rechners oder bei erreichbaren Nameservern auch der voll qualifizierte Name eines Netzes oder eines Rechners stehen.
Die zweite Spalte enthält entweder das Default-Gateway oder ein Gateway,
hinter dem ein Rechner oder Netzwerk erreichbar ist.
Die dritte Spalte enthält die Netzmaske für Netzwerke oder Rechner hinter
einem Gateway. Für Rechner hinter einem Gateway lautet die Maske zum
Beispiel 255.255.255.255.
Die letzte Spalte ist nur für die am lokalen Rechner angeschlossenen Netzwerke (Loopback, Ethernet, ISDN, PPP, …) wichtig. Hier muss der Name des Devices eingetragen werden.
In dieser Datei wird angegeben, welcher Domain der Rechner angehört
(Schlüsselwort search) und wie die Adresse des
Nameservers ist (Schlüsselwort
nameserver), der angesprochen werden soll. Es
können mehrere Domainnamen angegeben werden. Beim Auflösen eines
nicht voll qualifizierten Namens wird versucht, durch Anhängen der
einzelnen Einträge in search einen gültigen, voll
qualifizierten Namen zu erzeugen. Mehrere Nameserver können durch mehrere
Zeilen, die mit nameserver beginnen, bekannt
gemacht werden. Kommentare werden wieder mit #
eingeleitet. YaST trägt hier den angegebenen Nameserver ein (siehe
Beispiel 22.5, „/etc/resolv.conf“).
Beispiel 22.5. /etc/resolv.conf
# Our domain search example.com # # We use sonne (192.168.0.20) as nameserver nameserver 192.168.0.20
Einige Dienste wie pppd (wvdial),
ipppd (isdn), dhcp
(dhcpcd und dhclient),
pcmcia und hotplug modifizieren die
Datei /etc/resolv.conf über das Skript
modify_resolvconf.
Wenn die Datei /etc/resolv.conf durch dieses Skript
vorübergehend modifiziert wurde, enthält sie einen definierten Kommentar,
der Auskunft darüber gibt, welcher Dienst sie modifiziert hat, wo die
ursprüngliche Datei gesichert ist und wie man die automatischen
Modifikationen abstellen kann.
Wenn /etc/resolv.conf mehrmals modifiziert wird, wird
diese Verschachtelung von Modifikationen auch dann wieder sauber abgebaut,
wenn sie in einer anderen Reihenfolge zurückgenommen werden; dies kann bei
isdn, pcmcia und
hotplug durchaus vorkommen.
Wenn ein Dienst nicht sauber beendet wurde, kann mit Hilfe des Skripts
modify_resolvconf der Ursprungszustand
wiederhergestellt werden. Beim Booten wird geprüft, ob eine modifizierte
resolv.conf stehen geblieben ist (z. B. wegen
Systemabsturz). Dann wird die ursprüngliche (unmodifizierte)
resolv.conf wiederhergestellt.
YaST findet mittels modify_resolvconf
check heraus, ob resolv.conf
modifiziert wurde, und dann den Benutzer warnen, dass seine Änderungen nach
der Restauration wieder verloren sein werden. Ansonsten verwendet YaST
modify_resolvconf nicht, das heißt eine Änderung der
Datei resolv.conf mittels YaST und eine manuelle
Änderung sind äquivalent. Beides entspricht einer gezielten und dauerhaften
Änderung, während eine Änderung durch einen der genannten Dienste nur
vorübergehend ist.
In dieser Datei (siehe Beispiel 22.6, „/etc/hosts“) werden Rechnernamen IP–Adressen
zugeordnet. Wird kein Nameserver verwendet, müssen hier alle Rechner
aufgeführt werden, zu denen eine IP–Verbindung aufgebaut werden soll.
Je Rechner wird eine Zeile bestehend aus IP-Adresse, dem voll
qualifizierten Hostnamen und dem Rechnernamen
in die Datei eingetragen.
Die IP–Adresse muss am Anfang der Zeile stehen, die Einträge werden
durch Leerzeichen bzw. Tabulatoren getrennt. Kommentare werden durch
# eingeleitet.
Hier werden Netzwerknamen in Netzwerkadressen umgesetzt. Das Format ähnelt
dem der hosts-Datei, jedoch stehen hier die
Netzwerknamen vor den Adressen (siehe Beispiel 22.7, „/etc/networks“).
Das Auflösen von Namen – das heißt das Übersetzen von Rechner- bzw.
Netzwerknamen über die resolver-Bibliothek –
wird durch diese Datei gesteuert. Diese Datei wird nur für Programme
verwendet, die gegen die libc4 oder die libc5 gelinkt sind; für aktuelle
glibc-Programme vgl. die Einstellungen in
/etc/nsswitch.conf! Ein Parameter muss in einer
eigenen Zeile stehen, Kommentare werden durch #
eingeleitet. Die möglichen Parameter zeigt
Tabelle 22.6, „Parameter für /etc/host.conf“.
Ein Muster für /etc/host.conf wird
in Beispiel 22.8, „/etc/host.conf“ gezeigt.
Tabelle 22.6. Parameter für /etc/host.conf
Legt fest, in welcher Reihenfolge die Dienste zum Auflösen eines Namens angesprochen werden sollen. Mögliche Argumente sind (durch Leerzeichen oder Kommata voneinander getrennt): | |
hosts: Durchsuchen der Datei
| |
bind: Ansprechen eines Nameservers | |
nis: Über NIS | |
Bestimmt, ob ein in | |
|
nospoof on | Diese Parameter beeinflussen das spoofing des Nameservers, haben aber weiter keinen Einfluss auf die Netzwerkkonfiguration. |
Der angegebene Domainname wird vor dem Auflösen des Rechnernamens von
diesem abgeschnitten (insofern der Rechnername diesen Domainnamen
enthält). Diese Option ist dann von Nutzen, wenn in der Datei
|
Mit der GNU C Library 2.0 hat der
Name Service Switch (NSS)
Einzug gehalten (vgl. man 5 nsswitch.conf, sowie
ausführlicher The GNU C Library Reference Manual,
Kapitel „System Databases and Name Service Switch“).
In der Datei /etc/nsswitch.conf wird festgelegt, in
welcher Reihenfolge bestimmte Informationen abgefragt werden. Ein Muster
für nsswitch.conf zeigt Beispiel 22.9, „/etc/nsswitch.conf“.
Kommentare werden durch
# eingeleitet. Dort bedeutet zum Beispiel der Eintrag
bei der Datenbank hosts, dass nach
/etc/hosts (files) eine Anfrage über
DNS (vgl. Kapitel 24, Domain Name System)
losgeschickt wird.
Beispiel 22.9. /etc/nsswitch.conf
passwd: compat group: compat hosts: files dns networks: files dns services: db files protocols: db files netgroup: files automount: files nis
Die über NSS verfügbaren Datenbanken sind in
Tabelle 22.7, „Über /etc/nsswitch.conf verfügbare Datenbanken“ genannt. Zusätzlich sind in Zukunft
automount, bootparams,
netmasks und publickey zu
erwarten.
Die Konfigurationsoptionen für NSS-Datenbanken sind in
Tabelle 22.8, „Konfigurationsmöglichkeiten der NSS-„Datenbanken““ aufgeführt.
Tabelle 22.7. Über /etc/nsswitch.conf verfügbare Datenbanken
|
Mail-Aliase, von |
| Ethernet-Adressen. |
|
Für Benutzergruppen, von |
|
Für Hostnamen und IP-Adressen, von |
|
Im Netzwerk gültige Liste von Hosts und Benutzern, um
Zugriffsrechte zu steuern; vgl. die Manualpage
man |
|
Netzwerknamen und -adressen, von |
|
Benutzerpasswörter, von |
|
Netzwerk-Protokolle, von |
|
Remote Procedure Call-Namen und -Adressen, von
|
|
Netzwerkdienste, von |
|
Shadow-Passwörter der Benutzer, von |
Tabelle 22.8. Konfigurationsmöglichkeiten der NSS-„Datenbanken“
|
direkt auf Dateien zugreifen, zum Beispiel auf
|
| über eine Datenbank zugreifen. |
| NIS, vgl. Kapitel 25, Benutzung von NIS. |
|
Nur bei |
|
Nur bei |
Über diese Datei wird der nscd
(engl. Name Service Cache Daemon) konfiguriert (vgl.
man 8 nscd und
man 5 nscd.conf). Per default
werden die Einträge von passwd und groups
gecached. Dies ist bei Verzeichnisdiensten wie
NIS und LDAP
essentiell für eine gute Performance, da ansonsten für jeden
Zugriff auf Namen oder Gruppen eine Netzwerkverbindung
durchgeführt werden muss.
hosts wird normalerweise nicht gecached, da sich
der Rechner dann nicht mehr auf „forward/reverse lookups“
dieses Namensdienstes verlassen kann. Statt dem
nscd diese Aufgabe zu übertragen, sollten sie
einen „caching“ Nameserver einrichten.
Wenn beispielsweise das Caching für passwd aktiviert ist,
dauert es in der Regel 15 Sekunden, bis ein neu angelegter lokaler
Benutzer dem System bekannt ist. Durch das Neustarten des
nscd mit dem Befehl rcnscd restart kann diese Wartezeit
verkürzt werden.
Neben den beschriebenen Konfigurationsdateien gibt es noch verschiedene Skripten, die während des Hochfahrens des Rechners die Netzwerkprogramme starten. Diese werden gestartet, sobald das System in einen der Multiuser-Runlevel übergeht Einige dieser Skripten werden in Tabelle 22.9, „Einige Startup-Skripten der Netzwerkprogramme“ vorgestellt.
Tabelle 22.9. Einige Startup-Skripten der Netzwerkprogramme
Dieses Skript übernimmt die Konfiguration der Netzwerkinterfaces. Die Hardware muss dazu bereits durch /etc/init.d/coldplug (via hotplug) initialisiert worden sein. Wenn der Service network nicht gestartet wurde, werden auch keine Netzwerkinterfaces beim Einstecken via Hotplug aufgesetzt. | |
Startet den xinetd. Der xinetd kann verwendet werden, um bei Bedarf Serverdienste auf dem System zur Verfügung zu stellen. Beispielsweise kann er den vsftpd starten, sobald eine FTP-Verbindung initiiert wird. | |
Startet den Portmapper, der benötigt wird, um RPC-Server verwenden zu können, wie zum Beispiel einen NFS-Server. | |
Startet den NFS-Server. | |
Kontrolliert den Postfix-Prozess. | |
Startet den NIS-Server. | |
Startet den NIS-Client. |