Open Source im professionellen Einsatz
Linux-Magazin 09/2006

Hotplug unter Debian, SLES 9 und RHAS 4 erweitern

Starterkabel

Von Haus aus taugt Debians Hotplug zu wenig mehr, als Treiber zu laden und Geräte zu konfigurieren. Mit den hier exklusiv vorgestellten Skripten reagiert Linux jedoch auch auf angeschlossene Netzwerkkabel sowie Handys in der Umgebung und lässt Anwender Hotplug-Events für eigene Zwecke nutzen.

819

Bei Debian Sage, Suse Enterprise Linux 9, Red Hat Advanced Server 4 und älteren Systemen ist der Hotplug-Daemon die zentrale Anlaufstelle für alle Ereignisse, die mit Geräten zusammenhängen. Jedoch leistet der Daemon kaum mehr, als nur die Treiber für neue Geräte zu laden. Schon die simple Aufgabe, auf ein angeschlossenes oder abgeklemmtes Netzwerkkabel zu reagieren, überfordert die Implementation der oben genannten Distributionen.

Dabei ist das Kernel-Hotplugging mit seiner Zweiteilung in Kernelfunktion und Hotplug-Daemon leicht erweiterbar, mit Hilfe weniger von der Redaktion entwickelter Skripte sowie dem Netplug-Daemon ist Hotplug durchaus in der Lage, vollautomatisch ein Backup auf einen gerade angeschlossenen USB-Stick zu starten, die MP3-Sammlung eines in der Nähe befindlichen Handys zu aktualisieren oder Netzwerkschnittstellen dynamisch zu konfigurieren.

Ist der Kernel mit der Option »CONFIG_HOTPLUG« übersetzt, legt die Pseudodatei »/proc/sys/kernel/hotplug« fest, welchen Daemon der Kernel aufrufen soll, wenn bestimmte Bustreiber ein neues Gerät am System anmelden (Abbildung 1). Das bedeutet nicht zwangsläufig, dass das betreffende Gerät, etwa »eth0«, soeben physikalisch mit dem Rechner verbunden wurde, Hotplug wird nur mitgeteilt, dass ein neues Gerät im System verfügbar ist.

Abbildung 1: Wann immer die Bustreiber ein neues Gerät im System anmelden, startet der Kernel über seine Hotplug-Funktion den Hotplug-Daemon. Hotplug bedient sich dann der für das jeweilige Bussystem zuständigen Agenten-Skripte aus dem Verzeichnis »/etc/hotplug«.

So erzeugt zum Beispiel der Netzwerkkartentreiber »tg3« einen Hotplug-Event, wenn er geladen wird und die passende Hardware in Form eines Broadcom-Chips vorfindet. Insofern ist Hotplug nicht nur für Hotplugging-Events zuständig, sondern auch für Coldplugging, wenn lediglich der passende Treiber ge- oder entladen wird und sich am Computer physikalisch nichts verändert.

Besitzt das Gerät selbst noch Hotplugging-Möglichkeiten, berücksichtigt das Kernel-Hotplugging diese jedoch nicht. Bestes Beispiel ist eine Netzwerkkarte: Laut Spezifikation ist es durchaus möglich, ein Netzwerkkabel im Betrieb zu entfernen, einzustecken oder auch den Rechner mit einem völlig anderen Netzwerk zu verbinden. Obwohl praktisch alle Treiber längst erkennen, wann eine Verbindung (Link) zu einem Switch oder anderen Netzwerkgeräten besteht, leiten sie diese Information nicht an Hotplug weiter. Der Grund dafür ist, dass ein Netzwerkkartentreiber nicht zu den Bussystem-Treibern zählt.

Kabelkontrolle

Die Verbindungserkennung bei Netzwerkanschlüssen übernimmt zum Beispiel »netplugd« von [1]. Der Entwickler Bryan O\'Sullivan sieht vor, den Daemon über »init« mit einer Maske der zu überwachenden Netzwerkanschlüsse aufzurufen. Nach dem Start überwacht dann jeweils ein »netplugd«-Prozess einen Anschluss. Wie »netplugd« auf eine Link-Veränderung am Anschluss reagiert, legt das Bash-Skript »/etc/netplug.d/netplug« fest, indem es zum Beispiel einen DHCP-Client startet, um eine neue IP-Adresse zu beziehen.

Für die Konfiguration des Netzwerkgeräts ist aber eigentlich Hotplug zuständig, genauer gesagt das Skript »/etc/ hotplug/net.agent«. Bei Ethernet-Devices startet das Skript »ifup«, das die IP-Adresse entweder statisch zuweist oder aber per DHCP besorgt. Noch dazu ruft das Init-Skript »/etc/init.d/networking« bei jedem Systemstart »ifup« auf und richtet sämtliche in der Konfigurationsdatei »/etc/network/interfaces« eingetragenen Netzwerkgeräte ein.

Diese Vorgehensweise ist wenig sinnvoll und führt zu erheblichen Verzögerungen beim Systemstart, etwa wenn auf einem Notebook ohne Netzwerkverbindung der DHCP-Client vergeblich auf eine Antwort wartet. Außerdem ist es aus Sicht eines Administrators nicht wünschenswert, die Systemkonfiguration auf zu viele Stellen zu verteilen. Mit Hilfe des Hotplug-Daemon lassen sich jedoch beide Probleme lösen.

Hotplug-Klasse

Zunächst muss der »ifup«-Aufruf im Init-Skript »networking« entschärft werden. Da ohnehin jeder Netzwerktreiber einen Hotplug-Event erzeugt, sobald er geladen wurde und die Hardware initialisiert hat, darf das Kommando »ifup -a« im Init-Skript lediglich die Loopback-Devices konfigurieren - sie erzeugen als einzige keine Hotplug-Events.

Dazu überarbeitet Listing 1 die Datei »/etc/network/interfaces« so, dass die Ethernet-Devices in der Klasse »hotplug« liegen und nicht mehr automatisch konfiguriert werden. Das Listing zeigt die Einträge für einen Rechner mit zwei Netzwerkkarten, eine per DHCP und eine statisch eingerichtet.

Listing 1:
Interface-Klassen

01 auto lo
02 iface lo inet loopback
03 
04 allow-hotplug eth0
05 iface eth0 inet dhcp
06 
07 allow-hotplug eth1
08 iface eth1 inet static
09   address 192.168.178.110
10   netmask 255.255.255.0
11   network 192.168.178.0
12   broadcast 192.168.178.255
13   gateway 192.168.178.1

Mit dem Schlüsselwort »allow-hotplug« an Stelle des üblichen »auto« ignoriert »ifup -a« diese Netzwerkgeräte. Beim Aufruf des Hotplug-Daemon übergeben die Netzwerktreiber die Umgebungsvariablen »ACTION« und »INTERFACE«. »ACTION« enthält entweder »register« und »unregister«, je nachdem, ob der Treiber ein Netzwerkgerät hinzugefügt oder entfernt hat, während »INTERFACE« den Namen des betroffenen Netzwerkgeräts enthält, etwa »eth0« oder »eth1«.

Im Fall einer statischen Netzwerkkonfiguration wie bei »eth1« in Listing 1 ist es Ansichtssache, ob Hotplug die Einrichtung durchführen soll, sobald das Device verfügbar ist, oder ob dies erst bei angeschlossenem Netzwerkkabel passiert. Bei Servern kann es durchaus interessant sein, den Netzwerkanschluss sofort mit IP-Adresse und Routing-Informationen zu versehen, wenn sich Serverprogramme wie etwa Apache, Bind oder auch Cups ihre Dienste sowohl lokal wie nach außen anbieten und beim Start an eine feste IP-Adresse binden.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5,5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Knoten knüpfen

    Statische Gerätedateien sind angesichts aktueller Hardware nicht mehr zeitgemäß. So erfordert Hotplugging an USB- und anderen Bussen dynamisches Gerätehandling. DevFS erfüllt zwar viele Ansprüche an eine solche Lösung, wird aber nun von Udev abgelöst.

  • Geräteverwalter

    Seit Ende Juni ist Dev-FS nun endlich Geschichte: Nachdem es mehr als drei Jahre auf dem Abstellgleis rangierte, verdrängte sein Nachfolger Udev den Geräteverwalter jetzt endgültig aus dem Kernel. Das Linux-Magazin blickt dem Sieger unter die Haube.

  • Raus. Rein. Passt!

    Geräte im laufenden Betrieb einstöpseln und sofort damit arbeiten - das ist für alle Linux-User ein angenehmer Luxus, für jeden Notebookbesitzer und viele Server dagegen ein Muss. Die komplexe Technik dahinter will aber beherrscht sein. Die Grundlage dafür rollt dieser Schwerpunkt aus.

  • Der eigene Mini-Mainframe

    Mainframes konnten es schon lange, dank Xen 3 beherrscht es nun auch der PC: Auf einer Hardware laufen viele virtuelle Rechner verschiedener Betriebssysteme. Wie das gelingt, welche Probleme zu lösen sind und wozu das alles gut ist, erklärt dieser Beitrag.

  • Kernel-News
comments powered by Disqus

Ausgabe 05/2017

Digitale Ausgabe: Preis € 7,62
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.