Automatisch gesteuerte Services

Ein unixoides System stellt in der Regel eine Vielzahl von Services bereit. Diese müssen beim Betriebssystemstart oder spätestens beim ersten Zugriff auf «ihren» Netzwerk-Port gestartet werden. Einfache Netzwerk-Dienste werden in der Regel über (x)inetd gestartet, der bei der Anfrage auf einen Port die konfigurierte Service-Instanz startet und nach Beantwortung der Anfrage wieder stoppt. Komplexere Dienste oder solche ohne Netzwerk-Zugriff werden in der Regel über ein Init-Script gestartet, wobei BSD-Derivate ein einziges mono­lithisches Script (/etc/rc oder /etc/rc.local) für alle Services haben und von System V abgeleitete Unices wie Linux einzelne Scripts pro Service in /etc/init.d.



Beide Methoden haben das Problem, dass Dienste im Falle eines Absturzes nicht überwacht und gegebenenfalls neu gestartet werden. Auch Abhängigkeiten – beispielsweise Services, die von einem zweiten Daemon abhängen – werden nicht abgebildet. Ebenso kann man nicht ohne weiteres ermitteln, welche Prozesse zu welchem Init-Script gehören.

SMF-Architektur

Ersatz gesucht

Aus diesen Gründen sind Init-Scripts nicht mehr ganz zeitgemäss, und es gibt viele Initiativen, um die Init-Scripts zu erweitern oder gar ganz zu ersetzen. Sun hat zu diesem Zweck mit Solaris 10 das sogenannte Service Management Facility (SMF) eingeführt. Bei SMF handelt sich um ein Framework, welches die Nachteile von System V Init und (x)inetd beheben soll. Kurz zusammengefasst gibt es ein XML-basiertes Regelwerk, welches die Abhängigkeiten von Services (Diensten) untereinander beschreibt, wie Prozesse gestartet oder gestoppt werden und wie reagiert werden soll, wenn der Prozess beendet ist oder abstürzt.

Damit Dienste und Daemons vom System verwaltet werden können, muss es eine ganze Menge mehr wissen, als wenn ein Dienst einfach nur «dumm» gestartet wird. So ist ein gewisser Aufwand damit verbunden, eigene Services auf SMF zu portieren. Solaris unterstützt deshalb nach wie vor das System-V-Init-Konzept, damit ältere Dienste von Drittanbietern oder selbst geschriebene Scripts immer noch funktionieren können. Den inetd gibt es zwar nicht mehr, aus Kompatibilitätsgründen wohl aber noch die Konfigurationsdatei /etc/inetd.conf. Wird ein Eintrag in dieser Datei vorgenommen, gibt es das Tool inetconv, welche diesen dann in eine SMF-kompatible Form bringt. Vergisst man dies, warnt einen SMF via syslog.

Dienste und Instanzen

Die Service-Konfiguration besteht bei SMF aus zwei Teilen. SMF unterscheidet zwischen einem Dienst (Service) und einer Dienst-Instanz (Service Instance). Der Dienst beschreibt generell, wie ein Prozess gestartet wird – etwa der Secure Shell Daemon (sshd). Die Dienst-Instanz weiss hingegen unter anderem, wo die Konfigurationsdateien zu finden sind,
welche Abhängigkeiten benötigt werden (wie ein initialisiertes Netzwerk), wie und ob ein Prozess beim Beenden neu gestartet werden soll und an welchem Port der Dienst lauschen soll. Man kann für einen Dienst mehrere Instanzen konfigurieren, etwa einen weiteren SSH-Daemon, der an einem anderen Port lauscht.



Jeder Dienst und seine zugehörige Instanz sind dem System mit einem eindeutigen Namen bekannt. Dieser Name besteht aus drei Teilen: einer Definition, um was es sich handelt – im Fall von SSH um einen Service (Dienstprozess) –, einem Namen für den Service und dem dritten Teil, dem Namen der Instanz. Standardmässig lautet dieser Name «default». Im Beispiel des SSH-Daemon würde der komplette Name also wie folgt aussehen: svc:/network/ssh:default. Dieser eindeutige Name wird als Fault Manager Resource Identifier (FMRI) bezeichnet. Anhand des FMRI weiss der fmd (Fault Management Daemon), um welchen Prozess es sich
handelt.

Dies ist wichtig, denn der fmd ist dafür zuständig, auf einen Prozess mit einem Problem («ist abgestürzt», «kann nicht gestartet werden» usw.) zu reagieren. Wie er zu reagieren hat, wird in groben Zügen durch verschiedene Service-Modelle bestimmt:



- Transient Service: einmalig aufzurufender Prozess, der keinerlei weiteren Behandlung bedarf; beispielsweise ein Script, das beim Betriebssystemstart einmal ausgeführt werden soll.


- Standard Service: startet und überwacht Services; bei Problemen werden sie neu gestartet.


- Contract Service: ist das Standard-Modell. Die einzelnen zu überwachenden Prozesse werden durch einen speziellen Mechanismus von Solaris, den «Contracts», überwacht. Eine detaillierte Beschreibung von Contracts würde hier zu weit führen. Hier sei nur erwähnt, dass der Kern die Möglichkeit hat, Abhängigkeiten zwischen Vater- und Kind-Prozessen zu beschreiben und Events (wie «Prozess hat sich beendet», «Prozess hat ein Signal bekommen», «Es gibt einen Hardwarefehler», «Der Prozess hat einen Core-Dump generiert») zu generieren und an Listener (beliebige Prozesse, die auf solche Events reagieren können) zu verteilen. SMF benutzt diese Events und kann dann auf diese entsprechend reagieren. Der Vorteil der Contracts ist, dass es keinen (potentiell abstürzbaren) Dienst gibt, der die Events der Programme überwacht und besondere Rechte (Stichwort Sicherheit) haben müsste: Alles läuft über den Kern, der nicht isoliert abstürzen kann und über die Rechte für die nötigen Zugriffe verfügt.

Problemschau

Um Informationen zu den registrierten Services abzufragen, dient das Werkzeug svcs. Mit svcs -a lässt sich beispielsweise eine Liste der vorhandenen Dienste ausgeben, die über den Zustand der Dienste (Services State) informiert und seit wann dieser Zustand besteht. SMF kennt dabei eine Reihe von Service States:



- degraded: Der Dienst läuft eingeschränkt. Das Starten des Dienstes hat geklappt, ein Teil davon läuft aber nicht.

- disabled: Der Dienst ist nicht gestartet und vom Systemadministrator deaktiviert.

- online: Der Dienst arbeitet ohne Probleme.

- offline: Der Dienst ist aktiviert, aber nicht gestartet. Ein eventuell vorhandener Stern weist darauf. hin, dass der Dienst gerade startet.

- maintenance: Der Dienst konnte nicht gestartet werden.

- legacy_run: Der Dienst wurde über System V Init gestartet und wird nicht von SMF überwacht.



Mehr Informationen über einen einzelnen Dienst bekommt man mit svcs -x ‹FMRI›. So wird unter anderem der Grund angegeben, weshalb sich der Service im aktuellen Zustand befindet.

Verwaltung

Gesteuert wird ein Dienst mit dem Befehl svcadm. Er ermöglicht unter anderem das Aktivieren, Deaktivieren und Neuladen eines Service. Ausserdem erlaubt er, das System zu einem Meilenstein zu versetzen. Ein Milestone ist grob mit den unter System V bekannten Init States verwandt, die man sich als eine Gruppe von Diensten vorstellen kann. Sind alle in einem Milestone als zwingend definierten Dienste erfolgreich gestartet, wird in den nächsten Milestone gewechselt. Der System V Runlevel S entspricht beispielsweise dem Milestone «single-user», Runlevel 2 «multi-user». Solaris kennt aber noch andere Milestones, etwa «devices». Er richtet alle im Server eingebauten Devices ein.



Der Milestone «network» bedeutet, dass alle für einen Netzwerkdienst erforderlichen Komponenten intitialisiert wurden. Nebst den vorhandenen Standard-Meilensteinen können auch eigene definiert werden. So wäre es etwa denkbar, einen Milestone «database» einzuführen, welcher erreicht wird, sobald alle Datenbanken hochgefahren sind. Ein Webserver,
welcher auf die Datenbanken zugreifen soll, könnte nun von diesem Milestone abhängen und erst dann gestartet werden, wenn alle Datenbanken laufen.




Schneller Start dank Milestones und Abhängigkeiten

Selbstverwaltung

Um eigene Dienste an die Service Management Facility zur Verwaltung übergeben zu können, ist eine grundlegende Kenntnis von XML von Vorteil. Die Konfiguration eines Dienstes wird nämlich anhand sogenannter XML-basierter Manifest-Dateien getätigt. Die im System bekannten Manifeste liegen unter /var/svc/manifest. Um ein eigenes Manifest zu schreiben, kopiert man am besten eine Datei irgendwo auf das System und editiert sie. Hat man diese an die eigenen Vorstellungen angepasst, muss man sie noch SMF bekannt machen. Dies geschieht aber nicht, indem man sie selber nach /var/svc/manifest kopiert, sondern mit Hilfe des Programms svccfg, mit dem das Manifest vor dem Import validiert werden kann:



# svccfg


svc:> validate /tmp/mein_ssh.xml

svc:> import /tmp/mein_ssh.xml

svc:> quit



Anschliessend ist der Dienst betriebsbereit und kann via
svcadm aktiviert werden. Wenn alles richtig gemacht wurde, kann man seinen neuen Dienst testweise killen und beobachten, wie er automatisch neu gestartet wird.



Beispiel für Service-Manifest

Sinnvolle Neuerung

Wie man sieht, ist SMF eine sinnvolle Neuerung für (Open)Solaris und bietet dem Systemadministrator einige Vorteile. Statt sich Start- und Überwachungsscripts selber basteln zu müssen, erledigt das das Betriebssystem von selber. Man muss ihm nur per Konfigurationsdatei sagen, was es zu tun hat. Durch die Abhängigkeiten funktioniert dies nicht nur über mehrere Services hinweg, in Kombination mit den Milestones kann auch noch das Betriebssystem schneller booten. So kann der Webserver beispielsweise parallel zum SSH-Server gestartet werden, sobald das Netzwerk bereit ist.

Der Autor

Gregor Longariva (lonagriva@softbaer.de) ist Solaris-Administrator am Rechenzentrum der Universität Erlangen-Nürnberg.