Hotplug unter Debian, SLES 9 und RHAS 4 erweitern
Starterkabel
von Mirko Dölle
Erschienen im Linux-Magazin
2006/09
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.
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.
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.
| Whitepaper |
|
The Role of Open Source in Data Integration
Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)
Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|