Der Workshop in Heft 9/04[1] stellte Methoden vor, mit denen der interessierte Administrator die aktuell laufenden Dienste aufspürt. Damit weiß er aber noch nicht, wozu diese Dienste gut sind. Neben spannenden Entdeckungen in den Tiefen der Linux-Maschinerie beschert das Wissen über die wichtigen Daemons auch einen Sicherheitsvorteil: Die Kenntnis der Software, die auf einem typischen Linux-Server läuft, erlaubt das Erkennen fremder und potenziell gefährlicher Software.
Abbildung 1 zeigt ein Beispiel für die zahlreichen Prozesse, die Linux-Nutzer auf ihrem Rechner (hier eine nicht mehr ganz taufrische Suse-8.2-Installation) antreffen. Das Beispielsystem ist eine abgespeckte Workstation, bei der die meisten Netzwerkdienste deaktiviert sind - in einem voll ausgebauten Server spuken deutlich mehr Dämonen.
Abbildung 1: Das Kommando »ps ax« zeigt die laufenden Prozesse einer frisch gebooteten Suse 8.2 (hier gekürzt). Kernel-Threads sind an den eckigen Klammern erkennbar.
Die nach dem Booten anzutreffenden Prozesse gehören zwei Gruppen an: Unter Linux sind die so genannten Kernel-Threads von User-Prozessen zu unterscheiden. Erstere arbeiten im Kernelspace, im geheiligten Adressraum von Linux. Kernel-Threads entstehen in der Regel bei der Initialisierung von Modulen. User-Prozesse hingegen sind gewöhnliche Benutzerprozesse, die zum Beispiel durch den Aufruf eines Programms oder durch »fork()« entstehen.
Aller Anfang ist Init
Der »init«-Prozess (PID 1) ist die Mutter aller Prozesse. Wie in[2] beschrieben sorgt er dafür, dass ein Linux-System stets in einem angemessenen Betriebszustand arbeitet. Dazu startet und beendet Init andere Programme gemäß den Angaben in der Konfigurationsdatei »/etc/inittab«.
Kernel-Threads[4] sind an den eckigen Klammern um den Prozessnamen zu erkennen. Sie kümmern sich um essenzielle Arbeiten für den Kernel. Typische Beispiele für einen Linux-Kernel der 2.4er Reihe sind in Tabelle 1 zu sehen. Weitere Kernel-Threads sorgen für die Verwaltung von logischen Geräten (»mdrecoveryd« oder »raid*d«) oder spezieller Hardware (»ahd*« und »scsi*« oder »khubd«).
|
|
|
Thread
|
Erläuterung
|
|
keventd
|
Hilft bei der Verwaltung von Kernel-Threads selbst.
|
|
kapmd, kacpid
|
Kümmern sich um die Interaktion mit dem Powermanagement
des Computers (Advanced Power Management oder Advanced Configuration and Power Interface).
|
|
ksoftirqd
|
Sorgt für die Performance-freundliche Abarbeitung von
Interrupts (Soft-IRQs). Möglicherweise existiert dieser
Prozess unter verschiedenen Namen für die einzelnen Prozessoren.
|
|
pdflush, bdflush, kupdated, kjournald
|
Stellen sicher, dass auf Festplatte geschriebene Daten auch tatsächlich auf der Magnetschicht ankommen.
|
|
kswapd, kscand
|
Verlagern die zum jeweiligen Zeitpunkt nicht benötigten Daten aus dem Hauptspeicher auf die Festplatte.
|
Kernel-Threads entstehen, wenn sich die entsprechende Stelle des Kernels initialisiert, in der Regel also recht früh während des Bootvorgangs. Ausnahmen sind Module, die erst wesentlich später nachgeladen werden, zum Beispiel als Reaktion auf ein neu eingestecktes USB- oder Cardbus-Gerät. Im Gegensatz dazu werden die User-Prozesse erst nach und nach über die von »init« gestartete Programmkaskade aufgerufen. Das kann einige Minuten dauern und führt fast ausnahmslos zu höheren Prozess-IDs.
Ab ins Netz
Computer in professionellen Netzwerken müssen als eine der ersten Funktionen ihren Netzzugang einrichten. Meist liegen die erforderlichen Konfigurationsdaten nicht auf dem Endgerät, sondern eine Zentrale verteilt die Parameter über einen Mechanismus wie DHCP (Dynamic Host Configuration Protocol). In diesem Fall ist einer der frühesten User-Prozesse »dhcpcd« (DHCP Client Daemon), er hat auf dem Testsystem die PID 615. Achtung: Das zweite c vor dem d unterscheidet den Client- vom Server-Daemon »dhcpd«.
Der DHCP-Client besorgt essenzielle Daten wie die eigene IP-Adresse, Informationen über die Netzmaske sowie das Gateway und trägt diese Daten in die Routingtabellen des Kernels ein. Der Client aktualisiert die Parameter auch, wenn der DHCP-Server eine Änderung verlangt. Statt »dhcpcd« ist manchmal noch »pump« zu finden, die ältere Version eines DHCP-Clients mit fast identischen Aufgaben.
Privat genutzte Geräte, deren DSL- oder Kabel-Zugang ins Internet über einen separaten Router läuft, benötigen normalerweise ebenfalls einen »dhcpcd«. Wer ein manuell konfiguriertes LAN verwendet, sieht dagegen keinen eigenen DHCP-Prozess, da er die Konfigurationsdaten lokal speichert.
Modem- oder ISDN-Verbindungen nutzen heute fast immer das Point-to-Point-Protokoll mit einem Daemon namens »pppd«, den viele Anwender aus Kostengründen nur manuell starten. Direkte DSL-Anbindungen, bei denen der Linux-Computer das DSL-Modem über seine Ethernet-Karte ansteuert, verwenden entweder »dhcpcd« oder - in Deutschland häufiger - »pppd« in Verbindung mit »pppoe« (PPP over Ethernet).