Automatisiertes Herunterfahren für Spezialfälle

Wir haben kürzlich ein Cisco Small Business NSS 326 angeschafft, um dessen Tauglichkeit für unsere Zwecke zu erkunden. Diese sind unter anderem Einbindung in unsere Domäne, um das NAS als CIFS-Ressource nutzen zu können. Um die Sicherheit unserer Daten zu gewähren ist es aber unbedingt notwendig, dass das NAS am USV hängt und im Ernstfall automatisch heruntergefahren wird. Zu diesem Zweck bringt das Cisco auch einen eingebauten Client mit, der eine SNMP-Trap oder eine per USB angeschlossene USV überwachen kann. Leider entspricht dies nicht ganz den Anforderungen unseres Systems, da wir zur USV-Überwachung bevorzugt einen unserer Server einsetzen. Ein wenig Graben in den Konfigurationsdateien fördert zutage, dass das NSS 326 sogar das gleiche Programm zur USV-Überwachung per USB nutzt wie es unsere Debian Machinen tun (apcupsd), dummerweise aber ohne die bei Debian einkompilierte Unterstützung für den Netzwerkdienst von apcupsd.

Die Krux mit geschlossenen Plattformen

Die sehr Endnutzer-orientierte Gestaltung des Cisco NAS macht es uns leider auch sehr schwer, eine eigene Version zu kompilieren bzw. überhaupt über die Shell Änderungen einfließen zu lassen, denn der Neustart setzt das Arbeitsdateisystem in seinen Ursprungszustand zurück; Änderungen sind praktisch nur über das Webinterface möglich. Um die benötigte Funktionalität herzustellen, sahen wir uns also gezwungen, benötigte Skripte immer erst hoch zu laden. Damit nicht genug stellt die Busybox nur eine arg beschnittene ash zur Verfügung und einige sonst gängige Programme fehlen ebenfalls. Darum musste viel getrickst werden, um die gewünschte Funktionalität zu erreichen. Umgesetzt wurde die Lösung mit Python für den USV-Server und Shell-Skripten für die NAS. Der minimalistische Charakter letzterer dürfte das Skript auf fast allen Systemen mit stark beschnittener Funktionalität nutzbar machen; benötigt werden lediglich SSH, grundlegende Shell-Fähigkeiten und die Programme poweroff, rm, touch, sleep sowie test. echo und date würden zwar für (temporäre) Logdateien benötigt, sind jedoch nicht erforderlich.

Herunterfahren wäre zu leicht

Das direkte Herunterfahren wäre keine große Hexerei; was wir jedoch bewerkstelligen möchten ist, dass das NAS erst nach den anderen Servern herunterfahrt. Da hiervon auch der zuständige Kontrollservers betroffen ist, können wir das NAS nicht direkt anweisen, herunterzufahren. Bei zwischenzeitlicher Wiederherstellung der Stromversorgung dieser Vorgang außerdem automatisch abgebrochen werden. Darum musste ein Weg gefunden werden, nur mit den sehr begrenzten Bordmitteln, einen Wartezustand herbeizuführen. Der Befehl shutdown stand hierfür leider nicht zur Verfügung.

Was, wie und wo?

Die Konfiguration erfolgt über zwei Konfigurationsdateien, tao-rpwrmgmt.conf und hosts.conf, die beide im Ordner /etc/tao-rpwrmgmt/ abgelegt werden. Erstere definiert generelle Einstellungen und die Standardwerte für Remote-Hosts, die zweite die Abweichungen für einzelne Maschinen. Die Optionen sollten selbsterklärend sein; die MAC-Adresse wird nur benötigt, wenn eine eventuell voreilig heruntergefahrene Maschine per Wake On Lan wieder hochgefahren werden soll. Für Python muss außerdem noch das Paramiko-Modul installiert werden, welches die nötige SSH-Funktionalität zur Verfügung stellt. Grund dafür ist, dass SSH keine Option zur geskripteten Anmeldung mit Passwort bietet, das NAS aber dummerweise keine Möglichkeit bietet, dauerhaft SSH-Schlüssel zu speichern. Anschließend müssen noch in den Dateien /etc/apcupsd/doshutdown und /etc/apcupsd/mainsback eine beziehungsweise zwei Anweisungen eingefügt werden, die entsprechenden Skripte auszuführen.