© Iulian Dragomir / 123RF.com

Netzwerkgeräte wie Switches oder Router lassen sich oft nur mittels SNMP oder über proprietäre Ansätze überwachen. Thola tritt als Werkzeug mit einheitlicher Schnittstelle zu Monitoring-Tools wie Nagios oder Icinga an und verspricht hohe Performance sowie einfache Bedienung.

Klar: Monitoring ist für jedes IT-Setup der Gegenwart überlebenswichtig. Merken Kunden vor den eigenen Admins, dass etwas nicht stimmt, ist das im Einzelfall peinlich. Kommt das öfter vor, entstehen früher oder später hartnäckige Zweifel an der Professionalität einer Firma. Aus ureigenstem Interesse gestalten Unternehmen deshalb ihr Monitoring so gut und zuverlässig wie möglich – zumindest, was die Server angeht.

Betrachtet man aktuelle Monitoring-Setups, fällt eine Diskrepanz regelmäßig auf: Server, auf denen Linux läuft, haben die meisten Admins nach allen Regeln der Kunst im Blick. Hier gibt es eine Shell, hier lassen sich verschiedene Skripte und Programme sowie generell beliebiger Code ausführen, weil man es mit einem echtem Betriebssystem zu tun hat. Betrachtet man hingegen die Art und Weise, wie Unternehmen die Infrastruktur innerhalb ihrer Rechenzentren überwachen, gerät man oft ins Grübeln.

Infrastruktur meint dabei vorrangig die im Rack verbauten Komponenten, die für den Betrieb zwar nötig sind, bei denen es sich aber nicht um klassische Server handelt – also steuerbare Steckdosen (PDUs), Netzwerk-Switches und Router. Deren Funktionieren ist indes alles andere als egal: Den Servern im Rack kann es prächtig gehen – spielen die Switches verrückt, die die Racks an den Rest des Setups anbinden, hilft das alles nichts.

Ein Teil der Antwort auf die Frage, warum Admins Netzwerkgeräte oft so stiefmütterlich behandeln, liegt sicherlich darin, dass Switches in der Mehrzahl der Fälle eben keine Server mit Shell sind, auf denen sich beliebiger Code ausführen lässt. Abhängig vom Hersteller gibt es bei einzelnen Geräten ganz eigene Vorstellungen davon, wie Monitoring zu funktionieren hat.

Regelmäßig findet sich bei Netzwerkgeräten etwa die Überwachung per SNMP. Dabei werkeln in den Geräten eine Vielzahl von Sensoren, die ihre Werte über das SNMP-Protokoll und mithin über eine baumähnliche Struktur verfügbar machen. Deren einzelne Nodes tragen eher verwirrend wirkende Zahlenkolonnen als Bezeichnung. Generell lässt sich sagen: Wo sich bei konventionellen Geräten SNMP-Schnittstellen finden, würde man heute vermutlich eine ReST-API mit Ausgabe im JSON-Format bauen, um denselben Effekt zu erreichen.

So oder so bleibt die Integration von Daten aus solchen Monitoring-Werkzeugen mühsam. Nagios und Konsorten sind ab Werk gar nicht darauf ausgelegt, SNMP zu interpretieren. Sie kennen bei der Überwachung von Geräten nur die Werte OK, WARN und CRIT, je nach Ergebnis eines Tests. Neuere Monitoring-Lösungen wie Prometheus können zwar SNMP-Bäume in ihren Zeitreihen sinnvoll abbilden, finden sich aber längst nicht in jedem Setup.

Thola eilt zur Hilfe

Unzufrieden mit der Überwachung von Netzwerkgeräten durch klassische Monitoring-Systeme waren auch die Entwickler von Thola. Sie entschlossen sich dazu, das Problem an der Wurzel zu packen und ein Werkzeug zu verfassen, das SNMP-Daten interpretieren und an klassische Monitoring-Systeme weitergeben kann. Der Clou: Weil das Produkt auf Open-Source-Basis entsteht, ist die Anzahl der daran Mitarbeitenden praktisch unbegrenzt. Die Entwickler setzen also auf den Schwarm: Macht sich nur ein Admin die Mühe, Geräte eines bestimmten Herstellers (oder besser: deren SNMP-Baum) in Thola zu integrieren, lassen sich hinterher sämtliche Geräte des Typs oder Herstellers sinnvoll mit dem Werkzeug überwachen.

Erste Erfolge können die Entwickler dabei durchaus verbuchen: Thola unterstützt heute eine Vielzahl von Geräten der Marken Cisco, Juniper und Huawei, den aktuell mit Abstand größten Playern auf dem Markt der Netzwerkgeräte. Aber auch andere Hersteller kommen bei Thola zum Zug, wie etwa Brocade und Edgecore. Grund genug, sich Thola einmal genauer anzusehen: Wie funktioniert das Programm im Hinblick auf seine Architektur? Wie nimmt der Admin Thola in Betrieb, und welche Sonderfunktionen bietet die Lösung? Dieser Artikel gibt einen Überblick.

Keep it simple!

Wer hinter Thola ein komplexes Konstrukt aus vielen Mikrokomponenten erwartet, wie es der Trend in der Gegenwart eigentlich vorgibt, sieht sich schnell eines Besseren belehrt. Thola kommt ganz unprätentiös als einzelnes Binary in Go daher, das sich von der Kommandozeile jedes normalen Linux-Servers aus aufrufen lässt. Zusätzlich bietet Thola einen Daemon-Modus für den Betrieb einer ReST-API, auf den der Text später im Detail noch eingeht.

Im Zentrum steht wie beschrieben die Fähigkeit des Programms, sich mit verschiedenen Netzwerkgeräten zu verbinden, deren SNMP-Tabellen auszulesen, zu interpretieren und die Ergebnisse dann an andere Monitoring-Systeme weiterzugeben. Was Thola dabei im Detail tut, steuern Sie über die Parameter, die Sie dem Programm beim Aufruf mit auf den Weg geben.

Auch hier halten die Entwickler sich streng an ihr Motto “Keep it simple, stupid!”: Mehr als zwei Parameter benötigt Thola selten, um spezifische Details von einem Zielgerät auszulesen und zu verarbeiten. Der erste Parameter bestimmt dabei die Aktion, die Thola im nächsten Schritt ausführt.

Nur mal kucken

Thola unterscheidet grundsätzlich zwischen zwei Arten des Zugriffs auf ein entferntes Gerät. Die Kommandos »identify« und »read« sorgen dafür, dass Thola sich mit dem Gerät verbindet, die Daten ausliest und sie anschließend in einer YAML-ähnlichen Struktur ausgibt. Auf das Kommando »check« produziert Thola eine Ausgabe, die Nagios und dessen Abkömmlinge verstehen.

Der Funktionsumfang des Programms bietet Anlass, sich die diversen Optionen im Detail anzusehen. Der Parameter »identify« macht den Anfang. Lässt man Thola im Identifizierungsmodus auf eine Infrastrukturkomponente los, verbindet es sich zunächst per SNMP mit dem Ziel und versucht, anhand des vorgefundenen SNMP-Baums das Gerät zu identifizieren. Dabei greift es einerseits auf die vorgefundenen Daten und einzelne Felder darin zurück, andererseits auf die eigene Liste der unterstützten Geräte, in denen SNMP-Einträge zum Teil mit statischen Einträgen fix verbunden sind.

Im Anschluss gibt Thola zumindest die wichtigsten Details zum Gerät aus, wie den Hersteller, die Modellnummer, die Geräteklasse (ein Thola-interner Wert, dazu später mehr) sowie die Seriennummer und die Version des installierten Betriebssystems.

Nur mal lesen

Wesentlich leistungsfähiger als »identify« ist der »read«-Modus von Thola. Über ihn lassen sich bestimmte Details aus den Zielgeräten per SNMP auslesen, ohne die vorgefundenen Werte einer genaueren Prüfung zu unterziehen. Wer schon einmal versucht hat, einem entfernten Gerät via Snmpwalk zu Leibe zu rücken und aus der Ausgabe dann Rückschlüsse zu ziehen, der weiß, wie komplex das ist: SNMP produziert nicht unbedingt übersichtlichen Output.

Genau hier eilt Thola Ihnen zur Hilfe: Es fragt zwar dieselben Daten wie Snmpwalk ab, interpretiert sie aber und bereitet sie optisch übersichtlich und gut verständlich auf. Fast noch wichtiger: Thola filtert im »read«-Modus auch viele Daten aus dem kompletten SNMP-Zweig aus oder fragt überhaupt nur spezifische Nodes des Baums ab, was die Effizienz steigert und Ihnen das Leben ebenfalls erleichtert. Das manuelle Abfragen spezifischer Werte anhand der SNMP-Dokumentation eines Herstellers ist nämlich ziemlich kompliziert.

Die Reduktion der Komplexität der Ausgabe führt keineswegs dazu, dass das Tool unvollständige Daten ausgibt. Im »read«-Modus ist es stattdessen Ihre Aufgabe, genauer anzugeben, welche Informationen aus dem SNMP-Baum des Geräts Sie haben möchten. Thola kennt dafür eine große Menge von Parametern.

Netzwerkstatistiken

Wer etwa wissen will, wie viel Traffic ein Netzwerkgerät bisher verarbeitet hat, nutzt den Befehl »thola read count-interfaces«. Er liefert eine vollständige Liste sämtlicher Netzwerkschnittstellen des Geräts mitsamt den Traffic-Countern, also der Angabe, wie viel Datenverkehr in einem bestimmten Zeitraum über jeden einzelnen Port geflossen ist.

Sind Sie stattdessen lediglich auf eine Übersicht der vorhandenen Schnittstellen aus, nutzen Sie den Befehl »thola read interfaces«. Schlägt das Ausführen des Befehls fehl, hilft »thola read snmp«, die Erreichbarkeit des SNMP-Diensts des Geräts zu verifizieren. Klappt auch das nicht, verhindert vermutlich eine Firewall das Auslesen per SNMP, oder der Hersteller des jeweiligen Geräts deaktiviert dessen SNMP-Dienst ab Werk, sodass man ihn vor der Nutzung aktivieren muss. Das gelingt üblicherweise über das Konfigurationsmenü des Geräts. Sind alle Firewalls aus dem Weg geräumt und wurde SNMP sicher aktiviert, sollte »thola read snmp« zuverlässig funktionieren.

Dann lassen sich mit Thola auch diverse andere Statistiken auslesen. Eine Vielzahl der verfügbaren Parameter kennt man aus klassischen Monitoring-Systemen. Die Aufrufe »read disk«, »read cpu-load« oder »read memory-usage« geben grundlegende Systemparameter aus, die schnell einen Überblick über den allgemeinen Zustand des Geräts vermitteln.

Hier tritt eine der großen Stärken von Thola klar zutage: Hat der Admin einen heterogenen Zoo aus Netzwerkgeräten, muss er bei Thola nicht für jedes spezifische System dessen Parameter kennen und angeben. CPU-Last und Speicher eines Huawei-Switches lassen sich stattdessen mit exakt denselben Befehlen auslesen wie jene von Cisco- oder Juniper-Geräten, und die Ausgabe ist einheitlich, ganz gleich, von welchem Hersteller das Produkt stammt. Mit »thola read ups« zeigt das Programm, dass sich das Prinzip sogar auf andere Infrastrukturkomponenten anwenden lässt wie eben USVs.

Drum prüfe …

Der eine oder andere Admin denkt sich nun zu Recht: Geräte auslesen und die SNMP-Informationen optisch aufbereiten ist ja gut und schön, hilft in Sachen Monitoring allerdings nicht weiter. Will Thola also wie versprochen auch das Monitoring unterstützen, braucht es eine umfassende Integration in bestehende Monitoring-Werkzeuge.

Deren Markt teilt sich derzeit in zwei große Unterkategorien auf, die konventionellen Systeme wie Nagios oder Icinga einerseits und andererseits der modernere Ansatz, der auf Zeitreihendatenbanken (Time Series Databases) fußt. Thola plant zwar Unterstützung für Letzteres, richtet sich aktuell aber noch bevorzugt an die Betreiber der konventionellen Werkzeuge. Nagios und Konsorten gelten in Thola als First Class Citizens.

Das liegt daran, dass sich die Thola-Entwickler offensichtlich gut überlegt haben, wie sie die Monitoring-Funktion in ihrem Werkzeug implementieren wollen. Statt das Rad neu zu erfinden, setzen sie auf eine erprobte Technik, das Check-Plugin-Format: Diesen Namen haben sich die Thola-Entwickler zwar selbst ausgedacht, das Prinzip dahinter allerdings keineswegs erfunden. Viel eher dürfte das von Thola so titulierte Format den meisten Admins im Rahmen ihrer Karriere bereits begegnet sein.

Gemeint sind die bereits genannten Rückgabewerte OK, WARN und CRIT, anhand derer Monitoring-Dienste wie Nagios oder Icinga den Status eines Monitoring-Ziels erkennen. Ursprünglich war keineswegs die Einführung eines Standards für dieses Format geplant; stattdessen spiegeln die drei Begriffe ganz banal die Zustände wider, mit denen Nagios seit seinen ersten Tagen umgehen kann.

Weil Nagios eine ganze Weile lang als De-facto-Standard in Sachen Monitoring galt und viele Hersteller passende Plugins und Skripte anboten, um ihre Geräte zu überwachen, avancierte das Plugin-Format von Nagios ebenfalls zum faktischen Standard. Im “Monitoring Plugins Development Guide” der Nagios-Entwicklern systematisierte man es schließlich [1]; seither gilt es als formal kodifiziert (Abbildung 1).

Abbildung 1: Nagios führte die drei Rückgabewerte CRIT, WARN und OK ein, die viele Monitoring-Werkzeuge noch heute nutzen und die Thola unterstützt. Quelle: Wikipedia

Die Thola-Entwickler haben ihre Monitoring-Funktionen so gebaut, dass sie die standardisierten Rückgabewerte ebenfalls benutzen. Das macht Thola automatisch kompatibel zu Werkzeugen wie Nagios, Icinga, Zabbix und Check_mk, denn die verwenden oder unterstützen ihrerseits alle das Nagios-Format.

Anschluss ans Monitoring

Wie sich Thola mit einem Monitoring-System kombinieren lässt, das die Rückgabewerte von Icinga beherrscht, beschreiben die Entwickler ausführlich in ihrer Dokumentation. Vereinfacht dargestellt erstellen Sie zunächst zwei generische Templates für Check-Kommandos, die Thola aufrufen. Eines davon dient als Template für Checks, bei denen es weitere Parameter zu spezifizieren gilt, das andere für Checks, die keine weiteren Parameter akzeptieren.

Dann definieren Sie die tatsächlichen Thola-Checks, wobei Sie an den Thola-Aufruf nur »check« anfügen und auf die zuvor konfigurierten Templates zugreifen. Anschließend richten Sie für jeden Thola-Check noch die Service-Templates ein, die letztlich im Monitoring-GUI die einzelnen Tests repräsentieren. Am Ende lässt sich Thola direkt aus Nagios oder einem vergleichbaren Werkzeug heraus aufrufen, und die Rückgabewerte von Thola stellen die unmittelbaren Monitoring-Ergebnisse dar.

Alternative Ausgabe

Betreiben Sie Thola nicht im Kontext einer Nagios-kompatiblen Umgebung, bestimmen Sie über den Parameter »–format« andere Ausgabeformate. Thola unterstützt dabei alle Formate, die man gegenwärtig erwartet: XML steht ebenso zur Verfügung wie eine Pretty-Ausgabe, die die Monitoring-Informationen ansprechend formatiert anzeigt. Zusätzlich beherrscht Thola die Ausgabe in JSON, das sich auf der Kommandozeile bedarfsgemäß zudem sehr einfach in XML umwandeln lässt.

Überwachungsziele

Hinsichtlich der unterstützten Monitoring-Werte auf den Zielgeräten gibt sich Thola keine Blöße. Der größte Teil der Funktionen, der im »read«-Kommando zur Verfügung steht, lässt sich auch mit dem »check«-Schlüsselwort nutzen.

Um etwa die Informationen über die Betriebssystemversion mit der im Gerät hinterlegten zu vergleichen, nutzen Sie den Befehl »thola check identify« (Abbildung 2), wobei Sie per Parameter die gewünschten Werte für die einzelnen Felder angeben. »thola check snmp« prüft, ob sich ein Gerät per SNMP erreichen lässt und gibt bei Fehlern CRIT als Ergebnis zurück.

Abbildung 2: Thola fragt SNMP-fähige Geräte standardisiert ab und nimmt dem Admin so die mühselige Arbeit ab, SNMP-OIDs und Checks im Monitoring zu verknüpfen.

Die bereits erwähnten Parameter »cpu-load«, »memory-usage« und »disk« stehen wie schon beim »read«-Kommando ebenfalls zur Verfügung. Anders als bei »read« lassen sich hier auch obere und untere Schwellenwerte für jeden Parameter setzen. Dabei liegt der große Vorteil von Thola darin, dass sich mit einem Test-Kommando in Nagios, Icinga & Co. eine Vielzahl von Geräten abdecken lässt, denn die Thola-Entwickler haben ihre Parameter schlau entworfen. So kann man neben absoluten Zahlen auch Prozentwerte angeben. Ganz gleich, ob es sich um einen alten ProCurve von HP oder einen modernen Switch von Huawei handelt – soll Nagios Sie alarmieren, falls weniger als zehn Prozent RAM verfügbar sind, lässt sich das problemlos einrichten.

Für ReST vorbereitet

Mit seinem Fokus auf Rückgabewerte nach Nagios-Machart richtet sich Thola zumindest derzeit eher an die Admins konventioneller Monitoring-Systeme. Zugegeben, für Werkzeuge wie Prometheus drückt der Schuh auch nicht ganz so heftig. Die multidimensionale Art einer Zeitreihendatenbank, verschiedene Metrikdaten zu speichern, kommt der Struktur von SNMP eher entgegen. Für Prometheus gibt es etwa einen SNMP-Exporter [2], der von vorhandenen Geräten SNMP-Werte ausliest und als Metrikdaten in Prometheus einpflegt (Abbildung 3).

Abbildung 3: Prometheus kommt naturgemäß mit SNMP besser zurecht als klassische Systeme – OIDs mappen ist aber trotzdem mühsam. Quelle: Prometheus

Dabei liegt der Komfort allerdings spürbar niedriger als beim Thola-Ansatz: Der seitens der Prometheus-Entwickler angebotene SNMP-Exporter fragt bestimmte SNMP-Werte wie die verschiedenen Interface-Metriken der Netzwerkschnittstellen eben nicht autark ab. Hier muss der Admin pro abgefragtem Gerät stattdessen die SNMP-OIDs angeben, die der Exporter in Metrikdaten umwandeln soll. Dass Thola über seine Geräteklassen dem Admin einen Teil dieser Arbeit abnimmt, ist ein riesiger Vorteil, der hier deutlich zutage tritt.

Die Thola-Entwickler scheinen allerdings sehr wohl zu wissen, dass sie ihr Programm im Hinblick auf seine Zukunftsfähigkeit erweitern müssen. Schon heute unterstützt es einen eigenen Server-Modus, der den Thola-Client wie bisher vorgestellt um eine API nach dem ReST-Prinzip erweitert. Die dient als Datenbank für Ergebnisse, vor allem aber als Cache. Aus diesem können anfragende Clients die Ergebnisse von Monitoring-Aufrufen dynamisch abfragen.

Da hört der Prometheus-Admin die sprichwörtliche Nachtigall trapsen: Prometheus basiert bekanntlich auf dem Pull-Prinzip, der Prometheus-Server sammelt seine Metrikdaten bei den konfigurierten Backends ein. Biegen die Thola-Entwickler ihrer ReST-API eine Kompatibilitätsschnittstelle zu Prometheus bei, könnte Prometheus als Metrikdatensammler im Hintergrund auch Thola nutzen. Dann stünden auch dem Prometheus-Admin die Vorteile der Geräteklassen in Thola zur Verfügung, und er wäre von der lästigen Konfigurationsarbeit befreit, SNMP-OIDs auf Prometheus-Metriken zu transponieren. Kompatibilität mit Prometheus steht explizit auf der Roadmap des Programms, einen Termin nennen die Thola-Entwickler hierfür allerdings noch nicht. Die ReST-API ist aber per se eine perfekte Voraussetzung für eine wohl nicht mehr allzu ferne Unterstützung für Dienste wie Prometheus oder InfluxDB.

An der Konfiguration von Thola ändert sich übrigens nichts, wenn das Programm im API-Modus läuft. Man schickt Befehle zur Abfrage einzelner Geräte allerdings nicht mehr mittels eines »thola«-Aufrufs auf der Kommandozeile, sondern über den Befehl »thola-client«. Der verbindet sich mit der Thola-API und bringt sie dazu, die angeforderten Informationen von den Zielsystemen einzusammeln und anschließend an den Client auszuliefern (Abbildung 4). Dabei unterstützt »thola-client« dieselben Funktionen und Formate, die auch »thola« kennt.

Abbildung 4: Im API-Betrieb nutzt der Admin »thola-client«, um Werte abzufragen, darüber hinaus unterscheidet die Benutzung sich vom normalen Szenario aber nicht.

HTTP oder SSH

Aufbohren wollen die Entwickler auch die Art und Weise, wie Thola an seine Daten kommt. Im Fokus des Tools steht aktuell noch wie beschrieben SNMP, bald soll Thola aber auch per HTTP oder SSH an seine Daten kommen. Letzteres wäre in der Tat geboten, denn auf Admins, die Open-Networking-Switches wie jene von Mellanox mit Cumulus Linux nutzen, wirkt die Situation grotesk: Diese Geräte bieten eine normale Kommandozeile und alle Werkzeuge, die dem Admin dort üblicherweise zur Verfügung stehen.

Sinnvoll auslesen lassen sie sich mit Thola momentan aber nicht, weil Cumulus & Co. ab Werk ihre Daten nicht mittels SNMP zur Verfügung stellen. Ausgerechnet jene Geräte, die am einfachsten zu unterstützen wären, bedient Thola aufgrund seines aktuellen Designs also nicht. Auch hier scheint es aber nur eine Frage der Zeit, bis die Entwickler Abhilfe schaffen: In Go fällt es nicht weiter schwer, anstelle einer TCP- eine SSH-Verbindung zu implementieren.

Eigene Geräteklassen

Zu guter Letzt werfen wir noch einen Blick darauf, wie Thola sich für neue Geräte anpassen lässt. Die Entwickler haben die Unterstützung für die Komponenten verschiedener Hersteller in Device Classes aufgeteilt. Eine solche Klasse nimmt im Grunde ein Mapping einzelner SNMP-OIDs auf die Parameter vor, die Thola kennt (Abbildung 5).

Abbildung 5: Geräteklassen erweitern Thola bei Bedarf um Support für weitere Geräte – ihre Syntax lässt sich auch von Nicht-Entwicklern nachvollziehen.

Praktischerweise sind OIDs (zumindest in der Theorie) global eindeutig; OIDs von Cisco und Juniper sollten also im Normalfall nicht kollidieren. Ob wirklich jede OID weltweit offiziell oder inoffiziell nur einmal zum Einsatz kommt, lässt sich freilich nicht mit letzter Bestimmtheit sagen; dass die großen Hersteller ihre SNMP-OIDs im Griff haben, darf man jedoch getrost annehmen.

Auch Menschen, die nicht sattelfest in Go sind, stellt indes das Hinzufügen von Geräteklassen nicht vor unmögliche Hürden. Die Entwickler stellen in ihrer Dokumentation [3] ein Beispiel vor, das zeigt, worauf es ankommt: Neben der Definition des Klassennamens müssen die Dateien die SNMP-OIDs für die Komponenten der Switches festlegen. Um welche es sich handelt, verrät ebenfalls die vorbildliche Dokumentation [4].

Fazit

Klein aber oho – Thola kommt als schlankes Werkzeug vor allem Admins zupass, die in ihren Umgebungen regelmäßig auf Geräte treffen, die es per SNMP zu überwachen gilt. Das dürfte auf den größten Teil der aktuell existierenden RZ-Setups zutreffen, schon weil Geräte von Cisco, Juniper oder Huawei so weite Verbreitung genießen.

Thola nimmt dem Admin vor allem die extrem mühsame Arbeit ab, einzelne SNMP-Werte händisch in das Monitoring zu integrieren. Es abstrahiert die Ebene des Switch-Betriebssystems, sodass der Admin sich mit den Details der Hardware nicht befassen muss. Dadurch erleichtert es auch das Verwalten der Konfigurationsdatei des Monitoring-Systems, die nicht jede SNMP-OID für jedes betroffene Gerät enthalten muss. Obendrein lässt sich Thola leicht konfigurieren und benutzen.

Gelingt es den Entwicklern nun noch, Thola an moderne Zeitreihendatenbanken wie Prometheus anzukoppeln, gebührt dem Programm ein fester Platz im Werkzeugkasten eines jeden Admins, der den Betrieb seiner Umgebung sicherstellen muss. (jcb/jlu)