SDB:SUSE Linux Geräte- und Schnittstellenkonfiguration

aus openSUSE, der freien Wissensdatenbank

Version: 9.1 -

SUSE Linux Geräte- und Schnittstellenkonfiguration

Dieses Dokument beschreibt ein neues Konzept für die Geräteinitialisierung und die Schnittstellenkonfiguration. Die speziellen Konfigurationsdateien anderer Dienste und Prozesse, die ebenfalls im Verzeichnis /etc/sysconfig liegen, werden in separaten Dokumenten erläutert, die mit den jeweiligen Paketen ausgeliefert werden.

Im ersten Teil dieses Dokumentes wird das benötigte Hintergrundwissen bereitgestellt, um die vorgenommenen Änderungen zu verstehen. Im zweiten Teil werden die Geräteinitialisierung und die Schnittstellenkonfiguration erläutert.

Allgemeines Konzept und Hintergrund

Einführung, Terminologie und ein altes Problem

Mit SUSE Linux 9.1 und allen Produkten, die darauf basieren, wurde die Geräteinitialisierung und Schnittstelleneinrichtung überarbeitet. Sie basieren jetzt auf Hotplug und dem neuen sysfs in Kernel 2.6. Das neue Konzept wird über die nächsten Versionen schrittweise implementiert werden.

Zum besseren Verständnis dieses neuen Konzeptes ist es wichtig, die Bedeutung der Begriffe 'Gerät (device)' und 'Schnittstelle (interface)' zu kennen:

• Ein Gerät ist ein physisches Ding; etwas, das kaputtgehen kann, wenn man es fallen lässt. Ein Gerät muss gewöhnlich durch einen Treiber initialisiert werden. Nach der Initialisierung erzeugt der Treiber eine Schnittstelle zu diesem Gerät.
• Eine Schnittstelle ist Software; sie hat einen Namen und verfügt über einen Satz von Funktionen. Es kann mehrere Schnittstellen pro Gerät geben.

Normalerweise bilden ein Gerät und seine Schnittstelle eine Einheit. Zum Beispiel ist eine PCI-Netzwerkkarte eine Einheit, die aus einem PCI-Gerät und einer Netzwerkschnittstelle besteht. Was in den Kernelversionen vor 2.6 fehlte, war die Information, welche Schnittstelle zu welchem Gerät gehört. Wenn ein Gerät initialisiert wurde, wurde die neue Schnittstelle vom Kernel nummeriert. Diese Nummer hing jedoch nicht vom Gerät für die Schnittstelle ab, sondern davon, welche anderen Schnittstellen derselben Klasse bereits initialisiert wurden.

Die einzige Beziehung zwischen Geräten und Schnittstellen waren Aliaszeilen in der Datei modules.conf. Diese konnten jedoch nie etwas garantieren. Zum Beispiel konnte dort stehen:

  alias eth0 driver0 # for device0
  alias eth1 driver1 # for device1

Wenn device0 nicht initialisiert werden konnte, dann würde eth0 nicht registriert werden. Ein ifup eth1 würde dann das Laden von driver1 auslösen. Aber die neue Schnittstelle erhielte den Namen eth0 und nicht eth1. In der Vergangenheit kam dies selten vor, aber mit immer mehr Geräten, die während des Betriebes gewechselt werden konnten, wurde dies zu einem wirklichen Problem.

Dasselbe geschah mit anderen Geräten, z.B. mit Speichergeräten. Der Kernel wies Schnittstellennamen wie /dev/sd<X> zu, die über keine feste Zuordnung zu bestimmten Geräten verfügten. Der Kernel nummerierte sie in der Reihenfolge ihres Bekanntwerdens durch. Stellen Sie sich vor, die zweite von vier SCSI-Platten fällt aus und der Kernel vergibt für die bisherigen sdc und sdd die Namen sdb und sdc.

Sysfs und persistente Namen

Mit sysfs wurde nun die Vergabe von persistenten Schnittstellennamen möglich. Vor allem die Unterverzeichnisse /sys/devices/, /sys/bus, /sys/class und /sys/block sind für sysfs von Interesse. /sys/devices und /sys/bus sind zwei verschiedene Sichten auf die Hardware (die Geräte). /sys/class und /sys/block enthalten alle Schnittstellen, die von Anwendungen angesprochen werden können. (Auch wenn Sie bisher gewohnt waren, /dev/sda eine Gerätedatei zu nennen, in unserer Terminologie ist dies die Schnittstelle zu einem Speichergerät).

Der Hauptschlüssel zu diesem neuen Konzept sind Verweise mit dem Namen 'device', die von einem Schnittstellenunterverzeichnis in /sys/class oder /sys/block auf ein Geräteunterverzeichnis in /sys/devices zeigen. Nur wenn dieser Verweis existiert, kann man wissen, welche Schnittstelle zu welchem Gerät gehört:

    /sys/block/sda/device ->
        ../../devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1:1.0/host0/0:0:0:0
    /sys/block/sdb/device ->
        ../../devices/pci0000:20/0000:20:01.1/host1/1:0:0:0
    /sys/class/net/eth0/device ->
        ../../../devices/pci0000:00/0000:00:1e.0/0000:02:00.0
    /sys/class/net/eth2/device ->
        ../../../devices/pci0000:00/0000:00:1e.0/0000:02:01.1/0000:07:00.0

Jetzt, da diese Beziehungen bekannt sind, kann man den Schnittstellen persistente Namen zuweisen. Hierzu benötigen wir eine Tabelle, die das Gerät auf die Schnittstellennamen abbildet. Für alle Geräte mit /dev/*-Knoten als Schnittstellen, kann dies in /etc/udev/udev.conf geschehen. Für Netzwerkgeräte müssen die Namen der Konfigurationsdateien /etc/sysconfig/network/ifcfg-* eine Hardwarebeschreibung aufnehmen. Zum Beispiel wird die Konfiguration ifcfg-id-00:e0:98:a0:83:c2 immer für das Gerät mit der MAC-Adresse 00:e0:98:a0:83:c2 benutzt; innerhalb dieser Konfiguration kann ein persistenter Name angegeben werden.

Umkehrung der Reihenfolge von Geräteinitialisierung und Schnittstellenkonfiguration

Die Einrichtung von Netzwerkschnittstellen begann bisher mit der Schnittstelle. Es gab eine Konfiguration für eine Netzwerkschnittstelle, die nicht zu existieren brauchte. Eine ifup-Schnittstelle löste ein modprobe für das in modules.conf aufgeführte Modul aus. Der Treiber suchte nach Hardware mit der er umgehen konnte und registrierte alle von ihm erzeugten Schnittstellen. Die einzigen Ausnahmen waren USB und PCMCIA, die im laufenden Betrieb zugeschaltet werden konnten.

Da die Beziehung zwischen Geräten und Schnittstellen bekannt ist, startet der Prozess ab jetzt vom anderen Ende, nämlich bei den Geräten. Während des Bootens wird eine Suche nach verfügbaren Geräten ausgeführt und jedes gefundene Gerät löst einen Hotplugevent aus. Geräte, die zur Laufzeit angeschlossen werden, lösen ebenfalls einen Event aus. Hotplug kümmert sich um diese Events und ruft die entsprechenden Agenten zur Geräteinitialisierung auf. Mit anderen Worten: es lädt den Treiber. Wenn der Treiber neue Schnittstellen registriert, werden wieder Hotplugevents ausgelöst, diesmal für die Schnittstellen. Um diese Events kümmert sich einer der Schnittstellenagenten.

Die Aliaszeilen in modprobe.conf werden deshalb nicht mehr benötigt. Von ihrer Verwendung wird abgeraten, da sie seltsame Effekte auslösen können. Früher halfen diese Aliase bei der automatischen Initialisierung eines Gerätes, wenn irgendeine Operation von einer nichtexistenten Schnittstelle angefordert wurde. Jetzt ist das Gerät initialisiert und die Schnittstelle wird automatisch eingerichtet. Stellen Sie sich vor, Sie wollen mit ifconfig (*) testen, ob eine bestimmte Schnittstelle zur Verfügung steht, und diese ist gegenwärtig nicht vorhanden; für dieses Gerät wurde also kein Treiber geladen. Wenn dann 'ifconfig eth1' aufgerufen wird, führt es ein 'modprobe eth1' aus, das den in der alias-eth1-Zeile angegebenen Treiber lädt. Dieser Treiber löst einen Event aus, der die Schnittstelle mittels ifup einrichtet. Das war jedoch nicht das, was Sie beabsichtigten.

'ifup' lädt Module, es wirkt auf existierende Schnittstellen. Normalerweise werden alle verfügbaren Geräte während des Bootens initialisiert, so dass es keinen Grund gibt, dies später zu tun. Wenn das System so konfiguriert wurde, dass ein bestimmtes Gerät uninitialisiert bleibt, kann es später durch manuelles Starten von hwup initialisiert werden. Wenn die Schnittstelle für das Gerät über einen 'auto' Startmodus verfügt, wird sie automatisch eingerichtet.

(*) Von der Benutzung von 'ifconfig' wird ebenfalls abgeraten, jedoch aus
anderen Gründen. Stattdessen kann jetzt 'ip' benutzt werden. Es wird jedoch
empfohlen ifup, ifstatus und ifdown zu benutzen.

Geräteinitialisierung

Normalerweise sollten Geräte mittels hwup und hwdown gestartet bzw. gestoppt werden. Die Gerätekonfigurationen finden Sie in /etc/sysconfig/hardware. Die meisten dieser Skripte werden von Hotplugagenten aufgerufen. Der Profilmanager (SCPM) oder die Energieverwaltung können ebenfalls Geräte stoppen und starten. Ein hwup auf einen Knoten des Hardwarebaumes sollte die Initialisierung aller mit diesem Knoten verbundenen Geräte mittels Hotplug auslösen. Ein hwdown auf einen Knoten sollte zuerst angeschlossene Geräte stoppen, bevor der Knoten gestoppt wird. Ein Problem dieses Konzeptes besteht darin, dass ein einzelnes Gerät häufig nicht initialisiert werden kann, wenn es mehrere Geräte gibt, die vom gleichen Kernelmodul bedient werden. Das wird sich in Zukunft wahrscheinlich ändern.

In SUSE Linux 9.1 ist dieses Konzept nicht sehr entwickelt. hwup wird zwar für Hotplug benutzt, aber wenn es für ein Gerät keine Konfiguration gibt, versucht das System einen Treiber automatisch zu finden.

Gegenwärtig lädt hwup nur Kernelmodule und ruft mögliche Helferskripte auf. hwup wird von Hotplug mit einer Beschreibung des Gerätes (zumeist sysfs devpath) aufgerufen. hwup benutzt getcfg, um eine passende Konfiguration zu finden und wendet diese dann an. Weitere Informationen finden Sie unter man 8 hwup. Einer Konfiguration kann auch ein Startmodus hinzugefügt werden. Damit ein Gerät während des Bootens oder beim Anschließen uninitialisiert bleibt, setzen Sie in der Konfigurationszeile STARTMODE=manual (oder off).

Die Konfigurationsdateien sind /etc/sysconfig/hardware/hwcfg-<Konfigurationsname>.