Die eigenen oder die TYPO3-Installationen der Kunden stets auf dem aktuellen Stand zu halten und die Erreichbarkeit zu überwachen, ist sehr arbeitsintensiv. Darüber hinaus sollte man bei Veröffentlichung eines Sicherheits-Bulletins prüfen, wo die betroffenen Extensions oder die TYPO3-Core-Version im Einsatz ist. Seine wahre Stärke spielt der Caretaker [1] [2] insbesondere bei Agenturen und System-Administratoren aus, die viele TYPO3-Installationen im Blick behalten müssen. Aber schon bei einer einzelnen Installation kann der Caretaker von Nutzen sein.

Hauptaufgabe des Caretakers ist es, die ihm anvertrauten Installationen auf Erreichbarkeit und Aktualität zu überwachen. Dafür besteht das Caretaker-System im Kern aus zwei Komponenten: dem Caretaker und den Caretaker-Instanzen. Eine zentrale TYPO3-Installation mit der Extension „caretaker“ kann dabei beliebig viele TYPO3-Instanzen, beispielsweise die Kunden-Websites, überwachen. In jeder zu überwachenden Instanz wird die Extension „caretaker_instance“ installiert. Diese stellt der zentralen Caretaker-Installation eine Schnittstelle zur Verfügung, um Daten der Instanz abzufragen und so Tests auszuführen.

Im Backend der Caretaker-Installation konfiguriert man die zu überwachenden Instanzen. Diese können in Gruppen, etwa nach Kunden oder Servern, zusammengefasst werden. Außerdem legt man Konfigurationen für die einzelnen Tests an. Diese beinhalten neben allgemeinen Parametern, wie die Häufigkeit der Ausführung, auch testspezifische Optionen. Mit den beim Caretaker mitgelieferten Tests (siehe Tabelle) lassen sich die Instanzen umfassend überwachen.

So wie die Instanzen lassen sich auch die Tests in Gruppen zusammenfassen: „TYPO3-Basis-Tests“ beispielsweise oder „Tests für TYPO3 4.5“. Die Tests und Test-Gruppen werden schließlich den Instanzen zugewiesen, für die sie durchgeführt werden sollen.

Ein „Scheduler-Task“, die „rechte Hand“ des Caretakers, führt regelmäßig alle ausstehenden Tests für die einzelnen Instanzen aus. Dazu kontaktiert der Caretaker die Instanz über eine verschlüsselte Verbindung und fragt die benötigten Informationen ab. Der Test führt einfache Operationen in der Instanz aus, etwa „gib mir die Liste aller installierten Extensions“. Die Auswertung der Daten (bspw. Prüfung, welche der installierten Extensions als unsicher bekannt sind) und damit der Test selbst erfolgt in der zentralen Caretaker-Installation.

Ob die einzelnen Tests erfolgreich waren oder Probleme bei den einzelnen Instanzen festgestellt wurden, lässt sich im Caretaker-Backend im Modul „Overview“ feststellen. Dieses zeigt in einer übersichtlichen Baumstruktur den aktuellen Status der Tests und Instanzen. Außerdem kann man für jede Gruppe, Instanz und für einzelne Tests detaillierte Informationen über den letzten Durchlauf und Tests aus der Vergangenheit abrufen. Die Antwortzeiten des Ping-Tests werden beispielsweise als Diagramm dargestellt.

Doch über einige aktuelle Ereignisse und Statuswechsel möchte man direkt benachrichtigt werden, etwa wenn eine Instanz nicht mehr erreichbar ist oder ein Bulletin über eine unsichere Extension veröffentlicht wurde. Dazu bietet der Caretaker zwei Benachrichtigungssysteme an: Im Extension-Manager kann man das einfache „Simple notification system“ oder das komplexere „Advanced notifications system“ wählen.

In der farblich unterstützten Darstellung fallen Ausreißer sofort auf.

Das „Simple notification system“ deckt einfache Anforderungen ab und ist schnell zu konfigurieren: Jeder Instanz oder Instanz-Gruppe werden Kontakte zugewiesen. Bei einem Statuswechsel eines Tests (bspw. wenn ein Fehler auftritt oder ein bereits aufgetretener gerade behoben wurde) werden E-Mails an alle Kontakte aus den betroffenen Instanzen verschickt. Weitere Konfigurationsmöglichkeiten gibt es nicht. Für einfache Zwecke ist das aber vollkommen ausreichend.

Erst vor wenigen Wochen wurde das „Advanced notification system“ in den Caretaker implementiert. Aktuell befindet sich dieser Teil noch im „Beta“-Stadium, ein Einsatz sollte also genau geprüft werden. Das „Advanced notification system“ bietet deutlich mehr Möglichkeiten, um auf die unterschiedlichsten Situationen reagieren zu können. Die Konfiguration wird in so genannten Strategien definiert. Jede Strategie enthält mehrere Regeln, wobei diese jeweils Bedingungen und „ExitPoints“ enthalten. Ein ExitPoint definiert, wie die Benachrichtigungen verschickt werden sollen. Zurzeit stehen dafür E-Mail, Jabber/XMPP und ein Datei-Log zur Verfügung. Es ist aber auch denkbar, ExitPoints für SMS, Prowl (Push-Notifications für das iPhone) oder ein Ticket-System zu implementieren.

Den einzelnen Instanzen oder Instanz-Gruppen wird eine Strategie zugewiesen, die beim Ausführen der Tests angewandt werden soll. Für alle Regeln dieser Strategie werden die Bedingungen geprüft. Eine Bedingung kann etwa die Uhrzeit oder der Wochentag, die Art oder das Ergebnis des ausgeführten Tests sein. Sind sämtliche Bedingungen einer Regel erfüllt, werden die Benachrichtigungen über die entsprechenden ExitPoints verschickt.

Durch eine derart flexible Konfiguration könnte jeder Statuswechsel in einer Datei vermerkt, bei aufgetretenen Problemen eine E-Mail an den Techniker und am Wochenende zusätzlich eine SMS an den Notdienst verschickt werden (Listing 1).

logToFile.exit.file.filePath = fileadmin/caretaker.log
emailToAdmin {
	conditions {
		newState = warning,error
		onlyIfStateChanged = 1
	}
	exit {
		mail.roles = admin,emergency
		sms {
			conditions {
				schedule.saturday = 0-24
				schedule.sunday = 0-24
			}
			roles = emergency
		}
	}
}

Die Kommunikation zwischen dem Caretaker und der Instanz wird über eine asynchrone Verschlüsselung (Public/Private-Key-Verfahren) mit OpenSSL gegen Fremdzugriffe geschützt. Bei jeder Installation der „caretaker_instance“ wird also ein eigenes Schlüssel-Paar für diese Instanz generiert, dessen Public-Key im Caretaker in der Instanz-Konfiguration hinterlegt wird. Im Gegenzug erhält die Instanz den Public-Key des Caretakers.

Ein wichtiger Grundsatz bei der Entwicklung des Caretakers war, dass keine mitgelieferten Tests und Operationen der „caretaker_instance“ in der Instanz Daten oder Dateien verändern. Das Risko ist groß, dass durch ein automatisches Update einer Extension oder das Löschen vermeintlich alter Datensätze der
geregelte Betrieb der Seite gestört wird. Dieser Aspekt ist insbesondere bei der Erweiterung durch eigene Tests oder Operationen wichtig. Denn die Architektur der Extension erlaubt durchaus Eingriffe in die überwachten Installationen. Definierte Aufgabe des Caretakers ist deshalb lediglich das Überwachen der Installationen und nicht eine Fernsteuerung oder gar die automatische Behebung eines Fehlers.

Der Autor

Tobias Liebig lebt im Alten Land bei Hamburg, ist Diplom-Informatiker (FH), TYPO3-Core-Team-Member, Mitentwickler des Caretakers und Open-Source-Enthusiast. Seit 2004 arbeitet er mit TYPO3. Bei der networkteam GmbH in Kiel/Hamburg entwickelt er TYPO3-Extensions und FLOW3-Systeme.