Anfordungsanalyse

Bestehende Probleme

• Inkonsistenz (Zustand in einem Runlevel z.T. abhängig von
  "`Vorgeschichte"')
• uneinheitliche Semantik der Start- und Stoppskripte
• Bootvorgang unstrukturiert und unübersichtlich
• unklares Verhalten im Fehlerfall
• administrative Aufgaben schlecht automatisierbar

Anforderungsprofil erforderlich

Subsysteme

Eine logische Einheit bildet ein Subsystem (auch mehrere Kommandos, z. B.: rpc.mountd, rpc.nfsd bei nfs).

• ein rc-Skript pro Subsystem
• Locking-Mechanismus auf Subsystemebene
• Subsystem kann gestart und gestoppt werden
• Restart sollte möglich sein (z.B. nach Software-Update)
• Einheitliche Konsolenmeldung bei Start und Stopp
• Definition von Abhängigkeiten

Abhängigkeiten

• Definition der Abhängigkeiten (z.B. amd nach Netz)
• automatische Generierung der Start- und Stopp-Reihenfolge der Subsysteme
• Definition (virtueller) Services, Skriptnummer ab der verfügbar
• Abhängigkeiten von Subsystemen (`provides', `requieres')
• Tool, das Subsysteme automatisch einfügt

Konsistenz

Zustand in einem Runlevel muß immer gleich sein (unabhängig von der "`Vorgeschichte"').

Beispiel für Inkonsistenz:

Runlevel 3 und 5 seien gleich, bis auf Startskript für xdm in rc5.d.

Kommando Runlevel Aktion

initdefault 5 5 xdm läuft

telinit 3 3 xdm läuft

initdefault 3 3 xdm läuft nicht

Definition einer Semantik

In jedem Runlevel müssen alle verwendeten Subsyteme entweder gestartet oder gestoppt werden. In jedem Runlevel entweder Starts- oder Stoppskript

Neuer Runlevel:

• Subsysteme stoppen:
  • die im neuen Runlevel nicht mehr laufen sollen
  • und die bereits laufen
• Subsysteme starten:
  • die im neuen Runlevel laufen sollen
  • und die noch nicht laufen

Man beachte die nicht notwendig zwingende Semantik!

Konformität mit Standards

• FSSTND (FHS)-compliant
• Verhalten und Aufbau sollte Standards entsprechen (POSIX, SVID, andere Unices)
• Kompatibilität zu vorhandenen Tools, existierende Pakete (z.B. RPMs) sollten weiterhin installierbar sein.
• Portierbarkeit
• Problem: Widerspruch verschiedener Ansätze

Nach Linux Filesystemstandard 1.2 sind als Platz für die rc-Skripte sowohl

• das System V-Modell (/etc/rc.d/*)
• als auch das BSD-Modell (/etc/rc.*)
• sowie eine Kombination aus beiden

zugelassen.

Es sollten aus Portierbarkeitsgründen keine non-Standard Features (wie z.B. bash, /usr) in inittab, rc und rc.sysinit verwendet werden.

Behandlung von Ausnahmefällen

• Nach shutdown sollten Lockfiles entfernt sein
• Überprüfen von "`Stale Locks"' beim Booten
• Bail out in Maintenance Mode bei Fehlern (z.B. fsck)
• Paßwortschutz aus Sicherheitsgründen

Simulation

Simulation ermöglichen:

• Was ändert sich beim Wechsel zu Runlevel N?
• Welche Subsysteme werden gestartet, gestoppt?

Automatisierbarkeit

• Subsysteme hinzufügen, löschen (z.B. per RPM)
• Administrative Aufgaben
  

  dauerhaft: Subsysteme aktivieren, deaktivieren

  einmalig: Subsysteme starten, stoppen, neustarten

• Konsistenzchecks bzgl. definierter Runlevelsemantik
• weiterhin mit herkömmlichen Mitteln wartbar

Schnittstellen

Definierte Schnittstelle zur Anbindung anderer Software, z.B. grafisches Frontend

• bei formatierter Ausgabe ist Parsing der Boot-Ausgaben möglich
• Einzelskripte ermöglichen gezielte Manipulation von Subsystemen
• Status kann über Lockfiles eingesehen werden

Frontend

Zustandsmanager, User-Interface, ...