Zur Vorbereitung

Bevor die erste Code-Zeile geschrieben ist, tun RA-Autoren gut daran, ein paar Details abzuklären. Stets griffbereit sollte einerseits der OCF-Standard sein, der im Netz unter [1] zu finden ist. Nützlich ist im Zusammenhang damit auch der »OCF Resource Agent Developer's Guide« in der aktuellen Version 1.0.2 [2] , der aus der Feder von Florian Haas stammt. Er bietet in kürzester Zeit einen Überblick über alle Details, die zu beachten sind. Auch sollten RA-Autoren sich im Klaren darüber sein, welche Parameter ihr Resource Agent unterstützen soll. Das hängt freilich davon ab, welche Optionen die Software selbst bietet

Um diesen Artikel nicht zum reinen Trockenschwimmen werden zu lassen, demonstriert der Text im Folgenden den Eigenbau eines OCF Resource Agent für »asterisk« , den der Autor vor einigen Wochen in Zusammenarbeit mit mehreren anderen Entwicklern veröffentlicht hat. Asterisk eignet sich auf der einen Seite sehr gut, um die grundsätzliche Implementierung eines OCF-RAs zu diskutieren, andererseits lassen sich am Beispiel Asterisk aber auch sehr gut Ausnahmen demonstrieren, die applikationsspezifisch sind. In der einen oder anderen Art wird fast jede Applikation spezifische Eigenheiten aufweisen, die sich auch im OCF-RA wiederfinden.

Anhaltspunkte dafür, welche Optionen die Aufnahme in den RA wert sind, geben beispielsweise die »default« -Files in Debian, die üblicherweise in »/etc/default/« liegen ( Abbildung 2 ) und nach dem Programm benannt sind, für das sie sinnvolle Standardeinstellungen enthalten. Im Beispiel von Asterisk findet sich hier zum Beispiel die Festlegung, als welcher Benutzer und mit welchen Rechten Asterisk laufen soll oder wie viele Files Asterisk gleichzeitig öffnen darf. Debian verwertet diese Einstellungen im Asterisk-Init-Skript, und auch im OCF-Agent lassen sie sich als Parameter implementieren. Ein anderer Anhaltspunkt für Parameter ist üblicherweise der Aufruf eines Programms mit »--help« . Aus der Liste der Parameter, die das Binary selbst unterstützt, gewinnen Autoren von OCF-Agents einen Überblick über die unterstützten Konfigurationswerte.

Abbildung 2: Auf Debian-Systemen geben die Default-Files Auskunft darüber, welche Parameter ein Resource Agent sinnvollerweise unterstützt.

Im Beispiel ergeben sich die folgenden Parameter, die der Resource Agent für Asterisk unterstützen soll:

• »binary« legt fest, wo das eigentliche Asterisk-Binary liegt.
• »canary_binary« bestimmt den Ort des »astcanary « -Binaries und
• »config« die Stelle, an der »asterisk.conf« liegt.
• »user« und »group« wirken wie oben beschrieben.
• »additional_parameters« ermöglicht es, weitere Parameter händisch festzulegen, mit denen das Asterisk-Binary aufgerufen werden soll.
• »realtime« regelt, ob Asterisk im Realtime-Modus laufen soll oder nicht.
• »maxfiles« beschränkt die Telefonanlage hinsichtlich der Files, die diese gleichzeitig maximal geöffnet haben darf.

Der Header des Resource Agents

Damit kann es losgehen: Die erste Zeile des OCF Resource Agents ist dieselbe wie bei allen anderen Shellskripten auch – das Shebang. Es folgt eine allgemeine Beschreibung des Resource Agents und ein Copyright-Vermerk, danach sollte auch eine Liste der Parameter vorhanden sein, die dieser RA unterstützt, damit sie auf einen Blick ersichtlich sind. Der Header folgt dabei keiner spezifischen Syntax, für den Asterisk Agent könnte er also so aussehen wie in Listing 1 .

Im nächsten Schritt folgt die Initialisierung aller OCF-spezifischen Funktionen. Das geht so:

: ${OCF_FUNCTIONS_DIR=${OCF_ROOT}/lib/heartbeat}
. ${OCF_FUNCTIONS_DIR}/ocf-shellfuncs

Die Variable »OCF_ROOT« , auf die an dieser Stelle verwiesen ist, ist in der Pacemaker-Umgebung, in der das Skript später läuft, bereits gesetzt. Ab sofort stehen dem Agent sämtliche OCF-Funktionen zur Verfügung.