Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Die Meta-Daten des Resource Agents

An dieser Stelle wird es zum ersten Mal wirklich haarig: Der Resource Agent muss das Target »meta-data« unterstützen – die Ausgabe des Targets nutzt Pacemaker, um herauszufinden, welche Parameter der Resource Agent unterstützt und welche Operationen er ermöglicht (Abbildung 3). Letztlich tut der Meta-Data-Befehl kaum etwas anderes als die »usage« -Funktion, nämlich Text ausgeben. Allerdings kommt es bei »meta-data« darauf an, dass der ausgegebene Text einer Syntax auf XML-Basis entspricht (Abbildung 3). Eingeleitet wird die Ausgabe von diesen Zeilen:

Abbildung 3: Die Information, die
<?xml version="1.0"?>
<!DOCTYPE Resource Agent SYSTEM "ra-api-1.dtd">
<Resource Agent name="asterisk">
<version>1.0</version>

Dann folgt eine Beschreibung des Resource Agents, eingerahmt vom XML-Tag »<longdesc lang="en">« und eine Kurzbeschreibung, die von »<shortdesc lang="en">« umrahmt ist – beide Tags sind freilich am Ende wieder mittels »</longdesc>« oder »</shortdesc>« zu schließen. »<parameters>« leitet den Abschnitt ein, in dem für jeden einzelnen Parameter Name und Typ sowie eine Lang- und eine Kurzbeschreibung festgelegt werden. Ein Beispiel, um den Parameter namens »binary« zu definieren, wäre das in Listing 4.

Listing 4

Die Meta-Daten des binary-Parameters

 

Der Parameter »name« bestimmt den Namen des Parameters und »required« legt fest, ob der Parameter vom Admin angegeben werden muss. Im »content« -Bereich legt »type« fest, um welche Art von Wert es sich handelt. Mögliche Typen sind neben »string« auch »integer« und »boolean« .

Im Asterisk-Beispiel wäre »maxfiles« ein Wert des Typs »integer« und »realtime« ein Wert des Typs »boolean« . Ist für jeden Parameter ein entsprechender Eintrag vorhanden ist, schließt »</parameters>« die Parameter-Liste. Dann folgt noch eine Übersicht über die Operationen, die der Agent beherrscht:

<actions>
<action name="start" timeout="20" />
<action name="stop" timeout="20" />
<action name="status" timeout="20" />
<action name="monitor" timeout="30"interval="20" />
<action name="validate-all" timeout="5" />
<action name="meta-data" timeout="5" />
</actions>

Die Werte legen die Default-Timeouts fest, nach denen Pacemaker einen Fehler melden soll, und für die Monitor-Operation auch das Standard-Intervall. Alle Werte lassen sich in der CRM-Shell später überschreiben.

Der Eintrag »</Resource Agent>« zeigt Pacemaker an, dass die Meta-Daten des Agents damit vollständig ausgegeben sind. Ein syntaktisch korrektes jedoch unvollständiges Beispiel für eine standardkonforme »meta-data« -Funktion des Asterisk-RAs findet sich im Listing 5. Einen Fallstrick gibt es noch: In den Beschreibungen der Parameter muss man &lt; und &gt; anstelle der Zeichen "<" und ">" verwenden, schließlich handelt es sich um XML-Syntax.

Listing 5

Die Meta-Data-Funktion

 

Die Validate-Funktion

Jeder Resource Agent nach OCF-Standard braucht eine Validate-Funktion. Im vorliegenden Beispiel muss sie herausfinden, ob Asterisk mit der angegebenen Konfiguration überhaupt zu starten ist. Die Funktion überprüft beispielsweise, ob die per Parameter festgelegte Konfigurationsdatei existiert und ob es den Benutzer und die Gruppe, mit deren Rechten Asterisk laufen soll, auf dem lokalen System gibt. Der Resource Agent muss auch sicherstellen, dass er selbst funktionieren kann. Nutzt der Resource Agent Binaries, deren Existenz nicht auf jedem System vorauszusetzen ist, so hat er bereits in der Validate-Funktion zu testen, ob diese Binaries vorhanden sind – und muss gegebenenfalls mit einem Fehler den Dienst quittieren. Das Listing 6 enthält eine Validate-Funktion, wie sie für Asterisk funktioniert – bis auf den Teil mit »sipuri« ist diese Funktion allerdings sehr generisch, sodass sie sich so ähnlich für nahezu jedes Programm verwenden ließe.

Listing 6

Die asterisk_validate-Funktion

 

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

Ausgabe /2021