Dienste können unter Linux grundsätzlich auf zwei verschiedene Arten gestartet werden. Entweder sie sind grundsätzlich schon im Arbeitsspeicher geladen und warten auf Aufträge, die sie abarbeiten sollen, oder sie werden – jeweils wenn sie gebraucht werden – vom inetd aufgerufen. Beide Techniken haben ihre Vor- und Nachteile die Fall für Fall abgewogen werden sollten, um zu entscheiden, auf welche Weise ein bestimmter Dienst gestartet werden soll. Meist ist die Voreinstellung der Distributionen ein guter Anhaltspunkt, um zu entscheiden, ob ein Dienst immer laufen soll oder nicht.

Stand-alone Dienste konfigurieren

Dienste, die ständig im Arbeitsspeicher geladen sein sollen, werden als stand alone Dienste bezeichnet. Die modernen Linux-Distributionen verwalten diese Dienste auf immer gleiche Arten und Weisen, die sich im Detail etwas voneinander unterscheiden, prinzipiell aber sehr ähnlich sind.

Nachdem das Starten von Diensten oft mehr als ein Kommando benötigt, werden die Dienste mittels Shell-Scripts gestartet. Diese Scripts liegen alle in einem bestimmten Verzeichnis, meist /sbin/init.d bzw. bei neueren Distributionen nach den Richtlinien des Filesystem Hierarchy Standard 2.0 jetzt /etc/init.d

In diesem Verzeichnis befinden sich auch Unterverzeichnisse für jeden Runlevel, die symbolische Links auf die Scripts enthalten und so bestimmen, welche Dienste in welchem Runlevel gestartet werden sollen.

Um ein konkretes Beispiel anzuführen soll hier jetzt die Server-Startprozedur von SuSE-Linux besprochen werden, bei anderen Distributionen ist die Technik ähnlich, aber nicht exakt deckungsgleich.

Wenn bei SuSE Linux ein Paket installiert wird, das einen stand alone Dienst enthält, werden neben den einzelnen Programmdateien für diesen Dienst auch noch folgende Zusätze installiert:

  • Eintrag in /etc/rc.config
    In der zentralen Konfigurationsdatei /etc/rc.config wird ein Eintrag angehängt, der in der Regel die Form START_XXX=“yes“ hat. Dabei steht das XXX für den jeweiligen Dienst. Also etwa START_SMB oder START_HTTPD. Der Wert dieses Eintrages kann yes oder no sein, je nachdem, ob der Dienst gestartet werden soll oder nicht.
  • Startscript
    Im Verzeichnis /etc/init.d (oder früher /sbin/init.d) wird ein Script abgelegt, das meist so heisst, wie der Dienst, mit dem der Dienst selbst gestartet werden kann. Die Syntax zum Aufruf dieses Scripts ist immer gleich. Das Script wird aufgerufen mit einem der Parameter start, stop oder restart. Somit können die Dienste gestartet, gestoppt oder neu geladen werden. Bevor das Script aber den Dienst jeweils startet, überprüft es in der Datei /etc/rc.config, ob der Eintrag START_XXX für diesen jeweiligen Dienst überhaupt auf „yes“ gesetzt ist. Wenn nicht, wird das Script abgebrochen.
  • Runlevel-Links
    Im selben Verzeichnis wie die Scripts befinden sich die Verzeichnisse rc0.d, rc1.d, rc2.d … – für jeden Runlevel ein Verzeichnis. In diese Verzeichnisse werden jeweils Links installiert, die entweder mit einem S oder K beginnen, von einer Nummer gefolgt sind und dann den Namen des Dienstes haben, den sie beschreiben. Es handelt sich dabei einfach nur um Symlinks, die auf das Script zeigen, das den Dienst startet oder stoppt. Die Links mit dem S am Anfang des Namens dienen zum Starten des Dienstes in diesem Runlevel, die mit K dienen zum Stoppen (Kill) des Dienstes. Die Nummer legt die Reihenfolge der Abarbeitung fest.

Um also mit SuSE-Linux einen Dienst zu aktivieren, wird der Dienst zunächst installiert (mittels YaST), anschließend wird der Eintrag START_XXX in /etc/rc.config auf yes gestellt und danach einmal das Script in /etc/init.d mit dem Parameter start aufgerufen. Spielen wir es durch:

Der Webserver apache soll installiert werden. Wir rufen den YaST auf, markieren den Eintrag von Apache und installieren die Dateien auf die Festplatte. Jetzt wird Yast beendet.

Als nächstes editieren wir die Datei /etc/rc.config. Darin suchen wir den Eintrag START_HTTPD=… und verändern ihn in START_HTTPD=“yes“. Jetzt sichern wir die Datei und verlassen den Editor.

Beim nächsten Neustart würde der Apache-Webserver jetzt automatisch geladen. Damit wir aber jetzt nicht das System neu booten müssen – wir arbeiten ja schließlich nicht mit Windows – wechseln wir ins Verzeichnis /etc/init.d (bzw /sbin/init.d). Dort finden wir eine ausführbare Datei mit Namen apache. Das ist das Startscript. Rufen wir es auf mit

  ./apache start

schon wird der Webserver geladen und steht uns zur Verfügung. Fertig!

Natürlich muß jeder Dienst noch jeweils konfiguriert werden, das soll ja der Inhalt dieses Kurses vermitteln. Das Starten der Dienste läuft aber immer nach diesem Schema ab.

Inetd Dienste konfigurieren

Wenn Dienste über den inetd gestartet werden sollen, dann verhält sich der Startvorgang etwas anders. In diesem Fall wird der Dienst ja eben nicht beim Booten (bzw. Runlevelwechsel) automatisch in den Speicher geladen, sondern nur dann aufgerufen, wenn er gerade gebraucht wird.

Der Inetd hört auf verschiedene TCP und UDP Ports und startet jeweils den entsprechenden Dienst, sobald eine Anfrage auf einem der Ports eingeht. Dazu müssen zwei Voraussetzungen erfüllt sein.

  1. Eintrag der Portnummer in /etc/services
    In der Datei /etc/services stehen die Portnummern und dazu passende symbolische Namen. Für die normalen Dienste sind alle nötigen Einträge bereits vorhanden, wenn aber ungewöhnliche (z.B. selbstgeschriebene) Dienste gestartet werden sollen, so muß hier ein entsprechender Eintrag vorgenommen werden. Die Form ist immer gleich: Symname Portnummer/Protokoll also etwa ftp-data 20/tcp # File Transfer [Default Data] ftp-data 20/udp # File Transfer [Default Data] ftp 21/tcp # File Transfer [Control]
  2. Eintrag in /etc/inetd.conf
    Um den entsprechenden Dienst dann tatsächlich zu starten, muß jetzt noch ein Eintrag in /etc/inetd.conf vorgenommen werden. Auch hier stehen die meisten Einträge bereits fertig zur Verfügung und müssen nur noch auskommentiert werden. Die grundsätzliche Form ist hier Symname Socket-Typ Protokoll Flags User Server-Pfad Argumente Wobei aber meist – wie schon im Unix-Netz Kurs gezeigt – als Server-Pfad nochmal der TCP-Daemon /usr/sbin/tcpd angegeben wird, damit über /etc/hosts.allow und /etc/hosts.deny noch zusätzliche Zugriffssteuerungen vorgenommen werden können. Eine typische Zeile wäre also: ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd Der Symname entspricht dem, in /etc/services definierten Namen für die entsprechende Portnummer. Wird also jetzt eine Anfrage auf Port 21 empfangen, so startet der inetd unter der UserID von root – im Hintergrund (nowait) – das Programm /usr/sbin/tcpd mit dem Parameter in.ftpd. Falls die Überprüfung via hosts.allow und hosts.deny ergeben hat, dass alles in Ordnung ist, startet tcpd jetzt den in.ftpd und die Verbindung kommt zustande.
  3. Neustart von oder HUP-Signal an inetd
    Damit der inetd die Veränderungen an seiner Konfigurationsdatei auch mitbekommt muß er entweder neu gestartet werden (als Stand-alone Dienst in /etc/init.d/inetd restart) oder, es muß dem laufenden inetd das HUP-Signal geschickt werden. (kill -HUP PID)

Auch hier gilt – wie schon bei den Stand-alone Diensten, dass die eigentliche Konfigurationsarbeit für den Dienst natürlich noch separat geleistet werden muß. Welcher Dienst wie konfiguriert wird, ist dem entsprechenden Kapitel dieses Kurses zu entnehmen.

Typische Vertreter der beiden Techniken

Um eine Vorstellung zu bekommen, welche Dienste normalerweise wie gestartet werden, folgt hier noch eine kurze Auflistung der üblichen Starttechniken für oft benutzte Dienste:

Stand-Alone Dienste

  • DHCP-Server
  • Webserver
  • Firewall
  • Masquerading
  • Der inetd selbst
  • Druckserver
  • Samba
  • Nameserver
  • Proxy-Server
  • SSH
  • Sendmail

Inetd gestartete Dienste

  • FTP
  • Telnet
  • R-Befehle
  • Pop3 Server
  • SWAT
  • finger

Schreibe einen Kommentar