Managing OpenNMS with Redmine Herzlich willkommen, mein Name ist Marcel Fuhrmann. Ich arbeite in einer hier in Fulda ansässigen Firma und bin überzeugter OpenNMS Nutzer. Im Laufe der Zeit musste ich feststellen, dass die OpenNMS Konfigurationsdateien bzw. meine Anpassungen immer komplexer wurden und es somit nicht leichter wurde den Überblick zu bewahren. Bei OpenNMS Updates gab es immer genug Nacharbeit und ich hoffte immer, alle Änderungen noch halbwegs zusammen zu kriegen. Die Lösung für mein Problem fand sich relativ schnell. Unser Entwickler nutzt für seine Programmierarbeiten die OpenSource Produkte Redmine und Apache Subversion. Subversion ist für die Versionsverwaltung von Dateien und/oder Ordnern zuständig. Redmine wiederum ist ein sogenanntes Changemanagementsystem. Change Management wird lt. Wikipedia ungefähr so definiert: Ein Prozess, der das Ziel hat, dass alle Anpassungen einer IT-Infrastruktur kontrolliert, effizient und unter Minimierung von Risiken für den Betrieb bestehender Business Services durchgeführt werden. Klingt hochtrabender als ist ist. Sollte eigentlich selbstverständlich sein, wenn es um die Arbeit geht. Kurz gesagt bedeutet das für meinen Fall, dass ich immer einen guten Überblick über meine OpenNMS Konfigurationsdateien und deren Änderungen habe. Redmine wird wie viele Produkte heutzutage über den Browser definiert. Und diese grafische Oberfläche meines OpenNMS-Redmine-Projektes würde ich Ihnen gerne erläutern. Die Übersicht: Eine Übersicht darf nicht fehlen. Darüber gibt es auch nicht so viel zu erzählen. Es werden allgemeine Informationen, eine Übersicht der Tickets, die Mitglieder und News über das Projekt angezeigt.
Die Aktivitäten: Bei mir definitiv relativ einseitig, da ich der einzige Anwender bin, der Änderungen durchführt. Man sieht hier historisch alle Änderungen am Projekt. Das wären z.b. neue Tickets, Änderungen an Tickets oder neue Revisionen der NMS Konfigurationen.
Das Ticketsystem: Hier gibt es nur eine Regel. Und die habe ich in der Buchhaltung gelernt: Keine Buchung ohne Beleg!. D.h. Für jede Änderung an der Konfiguration wird ein Ticket angelegt. Damit man über die Tickets einen Überblick behält, werden diese einem Tracker, in meinem Fall gibt es nur Feature oder Fehler und einer Kategorie zugewiesen. Die Kategorien ergeben sich durch die Thematik des Anliegens. Die News: News werden werden in der Startseite des Redmine und des Projektes angezeigt. Wir nutzen diese Funktion für Eröffnungen von Wikis, neuen Funktionen oder sonst Nennenswertem. Einträge in der Newssektion werden auch per Mail rausgeschickt, damit Projektmitglieder informiert werden.
Das Wiki: Da ich der einzige bei uns bin, der NMS administriert, lege ich wert darauf, dass ein ein Nichtwissender relativ einfach ein Verständnis bekommt, was OpenNMS ist. Zur Dokumentation gehört natürlich die Installation der Software und die Grundeinstellungen am System selbst. Des Weiteren bestimmte Funktionen/Abläufe, Daemons, Begrifflichkeiten oder auch Strukturen in OpenNMS, damit man den Zusammenhang leichter versteht. Für viele Dinge genügen meist nur
ein paar Sätze und schon ist alles klar. Auch Updateszenarien oder Alltagsarbeiten wie Provisioning werden beschrieben, damit ein Neuling auch das bewältigen kann. Als Beispiel mal das Wiki Startseite. Für einen NMS Nutzer ist das natürlich Elementarwissen... Es besteht einfach aus Screenshots und kurzen Erläuterungen. HIER DAS GESAMTE WIKI DER STARTSEITE ABBILDEN
Die Dateien: Es besteht die Möglichkeit Dateien in das Projekt hinzuzufügen. Für das NMS Projekt nutze ich das nur, um vom Wiki darauf zuzugreifen (Screenshots). In anderen Projekten stelle ich darüber auch Handbücher, Clientprogramme oder div. Tools die benötigt werden zum download bereit. Und ja, an dieser Ordnung muss ich noch arbeiten. Denn die Namensgebung ist mehr als unübersichtlich. An sich ist das nicht schlimm, denn einmal richtig verklinkt, insteressiert es niemanden mehr. Ich einer Nacht- und Nebelaktion werde ich die mal alle umbenennen.
Das Projektarchiv: Hier sieht man alle Revisionen der NMS Konfiguration. Das heißt, jeder commit über den SVN Server. Paradebeispiel: Abschließen, damit alles einen Sinn ergibt, möchte ich gerne ein Ticket von Anfang bis Ende durchspielen. Angelegt wurde ein Ticket Strafeping Leitungsqualität visualisieren. NOCH EIN BILD VOM TICKET ANLEGEN REIN. Bei diesem Ticket war ich mir unschlüssig ob es eher der Kategorie provisiond oder pollerd zugeordnet werden muss. Ich glaube, dass in der aktuellsten Version von Redmine auch mehrere Kategorien zulässig sind. Als Beschreibung habe ich auf den passenden Wikieintrag verwiesen, der den Strafeping erklärt.
Danach sieht man, dass das Ticket die Status In Prüfung, Angenommen und In Bearbeitung durchlaufen hat, bis wirklich etwas geschieht. In größeren Szenarien macht das definitiv mehr Sinn, denn dort könnte auch jemand höhergestelltes ein Ticket ablehnen. Ich habe also Glück, da ich der einzige NMS Admin bin und konnte in meiner NMS Konfig den Strafeping einrichten. Dazu war eine provsiond Gruppe bzw. ein passender Detector nötig und in der pollerd Konfig ein passender Eintrag auf welchen IP Adressen/Bereichen gepollt werden soll. Einen passenden KSC Report dazu habe ich auch gleich angelegt. Auf der NMS Konsole ist ein svn commit -m '(OK #474) Strafeping implementiert /etc/opennms/ nötig um a) den SVN Server zu aktualisieren und b) einen Bezug zum Ticket zu bekommen. In Redmine sind diverse Begrifflichkeiten definiert, die in der SVN Beschreibung existieren können, um anhand dessen dem Ticket einen Status zu verleihen. So ist ein OK #474 z.b. Status GELÖST für Ticket 474. Gelöst bedeutet in unserem Fall immer: Änderungen sind gemacht und eingespielt. Wirklich erledigt wird ein Ticket erst, wenn es auch funktioniert. Wenn ich z.b. viel experimentiere benutze ich das Stichwort FEATURE anstatt OK. Damit ändert sich der Status eines Tickets nicht. HIER FEHLT NOCH EIN DIFF DER KONFIGS
GGFS. NOCH DER STRAFEPING GRAPH ODER DIE PROV GROUPS. UND NOCH DER VERWEIS ZU NEWS