Service Management Facility (SMF) von Open Solaris

© Steve Cukrov, Fotolia

Dienstbare Geister

Wer von Linux kommend zu Open Solaris wandert, muss sich zum Teil stark umstellen. So verwendet es eine Weiterentwicklung des klassischen Init-V-Systems für das automatische und manuelle Starten und Stoppen von Systemdiensten.
High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Den meisten Linux-Admins ist es nach längerer Zeit in der Praxis schon in Fleisch und Blut übergegangen: Sie tippen »/etc/init.d/« und drücken dann die [Tab]-Taste, wenn sie einen Serverdienst starten oder stoppen wollen. Bei (Open) Solaris übernimmt dies das Service Management Facility (SMF), das unter anderem Hintergrundprozesse (Daemons) verwaltet. Es löst damit die klassischen RC-Skripte ab, die Linux-Benutzer gewohnt sind. Ihre Funktionalität reicht aber noch weiter. Das SMF dient zusätzlich auch der Handhabung von Geräten und den Milestones, also von den Runlevels abgeleiteten Services.

Identifizierung

Das SMF ermöglicht die einheitliche Verwaltung der Services für den Start, das Beenden und die Fehlerbehandlung. Dabei identifiziert der Fault Management Resource Identifier (FMRI) einen Dienst im System. Der FMRI enthält den Service- und Instanznamen, er ist in der Form

svc:/Service:Instanz

aufgebaut. In folgendem Beispiel

svc:/network/login:rlogin

bezeichnet »/network/login« den Service und »rlogin« die Service-Instanz. Die Angaben werden immer mit »svc:« eingeleitet. Der Daemon »svc.startd« ist der Masterprozess-Starter und -Restarter für das Betriebssystem. Die Services werden in die Kategorien

  • application,
  • milestone,
  • platform,
  • device,
  • network,
  • site,
  • system

eingeteilt. Diese Einteilung zu beachten ist für jene Administratoren wichtig, die Anwendungen außerhalb des Paketsystems installieren und mittels SMF verwalten wollen. Jeder eingetragene Service besitzt automatisch auch einen Status (Tabelle 1).

Tabelle 1

Service-Status

Status

Bedeutung

online

Service wurde aktiviert und erfolgreich gestartet

offline

Service wurde aktiviert, aber nicht gestartet

degraded

Service wurde aktiviert, aber mit eingeschränkten Ressourcen gestartet

maintenance

Service wurde aktiviert, beim Start trat ein noch zu klärender Fehler auf

uninitialized

Ausgangsstatus aller Services vor dem Einlesen der Konfiguration

legacy run

Start über klassisches RC-Skript, nur Überwachung durch SMF möglich

disabled

Service ist nicht aktiviert und nicht gestartet

Die RC-Skripte legt der Open-Solaris-Administrator unter »/etc/init.d« mit Symlinks im passenden Runlevelverzeichnis ab (»/etc/rc.Runlevel.d« ). Sowohl der Start beim Hochfahren des Systems als auch die manuelle Vorgehensweise funktionieren wie üblich. Auf diese Weise gestartete Prozesse stellen die SMF-Werkzeuge in der Form »lrc:/etc/RC-Verzeichnis/RC-Skript« dar.

Runlevel und Milestones

Open Solaris kennt nach wie vor die klassischen Runlevels. Mit Hilfe von »init Runlevel« beziehungsweise mit dem entsprechenden Befehl (etwa »reboot« ) wechselt es wie jedes andere Unix-artigen Betriebssystem den Runlevel, startet das System neu oder fährt es herunter. Milestones kennzeichnen ähnlich wie Runlevels einen definierten Stand an aktiven oder nicht aktiven Services. Einige entsprechen Runlevels. Das Handbuch rät allerdings (noch) davon ab, mittels SMF die bisherige Handhabung der Runlevels zu ersetzen, obwohl dies teilweise möglich wäre.

Der Standard-Runlevel ist 3, der Standard-FRMI heißt »milestone:/multi-user -server:default« . Mittels »/usr/bin/who -r« kann am laufenden System der aktuelle Runlevel ermittelt werden:

/usr/bin/who -r
  .   run-level 3  Jan 22 19:07   3     0   S

In diesem Beispiel ist der aktuelle Runlevel »3« . Dies zeigt das Kommando doppelt an, zusammen mit dem Zeitpunkt, seit wann der aktuelle Runlevel aktiv ist. Die folgende Angaben verraten, wie oft seit dem letzten Reboot dieser Runlevel erreicht wurde (0-mal) und welcher der vorhergehende war (S).

Tabelle 2

Runlevel und Milestone

Runlevel

FMRI

Zweck

0

Herunterfahren des Systems, ohne abzuschalten

s/S

milestone:/single-user:default

Ein-Benutzer-Modus mit teilweise eingehängten Dateisystemen

1

Wie »s« , Anmeldung nur für Root möglich

2

milestone:/multi-user:default

Mehr-Benutzer-Modus, alle Services außer NFS gestartet

3

milestone:/multi-user-server:default

Wie »2« , mit NFS

4

Weiterer Mehr-Benutzer-Modus, für eigene Erweiterungen

5

Herunterfahren und Abschalten des Systems

6

Neustart des Systems

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019