"Der Checker"

Als NETWAYS schreiben wir uns selbst ein sehr hohes Icinga/Nagios KnowHow auf die eigene Fahne. Aber auch wir haben, wie 99,99% aller Icinga/Nagios Anwender, immer wieder den ein oder anderen Fallstrick zu bewältigen.
Ein Problem, welches sehr häufig Auftritt, das richtige maskieren von Sonderzeichen in Check-Definitionen.
Ein ganz simples Beispiel: Mit wie vielen Backslashes (\) muss man die Pfadangaben eines Shares maskieren, damit Icinga/Nagios diese richtig interpretiert?
Wie ist das vorgehen in einem solchen Szenario? Richtig, man ändert so lange und so oft die Definition, führt jedes mal einen Icinga/Nagios Reload aus und führt den Check neu aus bis man irgenwann das gewünschte Ergebnis hat… Das dies mitunter längere Zeitspannen in Anspruch nimmt ist vielen durchaus bewusst, uns auch!
Icinga/Nagios besitzt im Core ca. 10 Zeilen, welche für das maskieren von Sonderzeichen verantwortlich sind. Dieses kleine Snippet/Wrapperplugin hilft uns nun dabei unsere Checks im vorhinein schon richtig zu bauen und zu testen, um sie anschließend in die jeweilige Definition zu übernehmen.
Ein Aufruf des Wrapperplugins sieht wie folgt aus:

# ./check_executor /opt/icinga/libexec/check_http -H icinga -u "/icinga-web"
Executing command /opt/icinga/libexec/check_http -H icinga -u /icinga-web
Check output: HTTP OK: HTTP/1.1 301 Moved Permanently - 305 bytes in 0.001 second response time |time=0.001075s;;;0.000000 size=305B;;;0

Executing command gibt den eigentlichen Pluginaufruf aus, wie er duch Nagios/Icinga ausgeführt wird.
Check output beschreibt die eigentliche Ausgabe, wie sie u.a. auch in der Weboberfläche sichtbar wäre.
Zu finden ist das ganze in unserem GIT: https://git.netways.org/plugins/collection/trees/master/plugins/check_executor
Um Verwechslungen grundsätzlich aus dem Weg zu gehen: “Der Checker” kümmert sich natürlich um schöne Autos, unser “Checker” um Icinga/Nagios Plugins.

Serie NSClient++ – Teil 9: Registry

Konfigurationsdatei

Die Konfiguration von NSClient++ wird im Standard in der Datei nsc.ini vorgenommen.
NSClient++ bietet neben dieser Konfigurationsmethode auch die Möglichkeit die Konfiguration in die System Registry auszulagern.
Ein verlagern der Konfiguration aus der Konfigurationsdatein in die Registry bietet u.a. in großen Deployments den Vorteil das man die Konfiguration z.B.: über eine Gruppenrichtlinie verwalten und steuern kann.
Konfigurationsobjekte befinden sich dann unter HKEY_LOCAL_MACHINE\Software\NSClient++ und können von dort aus bearbeitet werden.

Konfiguration auslagern

In der bestehenden Konfigurationdatei muss neben dem Parameter “use_file=1” der Parameter “use_reg=1” ergänzt werden.
Nachdem die nsc.ini diese Option im Bereich “[Settings]” enthält, kann die Konfiguration in die Registry importiert werden.
Für den Import der Konfiguration in die Registry wird das Module RemoteConfiguration verwendet.

C:\Program Files\NSClient++>"nsclient++.exe" -noboot RemoteConfiguration ini2reg
NSCore not loaded...
Archiving crash dumps in: C:\Users\Administrator\AppData\Local\NSClient++\crash dumps
Migrating to registry settings...
importing: modules/FileLogger.dll=
importing: modules/CheckSystem.dll=
...

Nach dem Import finden sich die Objekte, wie bereits erwähnt, unter HKEY_LOCAL_MACHINE\Software\NSClient++ in der Registry wieder.
Damit NSClient++ nun nicht weiterhin die Konfigurationsdatei nutzt muss die Option “use_file=” deaktiviert werden (“use_file=0”) und der NSClient++ Service neugesartet werden.

net stop nsclientpp
net start nsclientpp

Die Einstellungen der Registry können nun auf andere Windows-Server verteilt werden (z.B.: mittels GroupPolicy oder SoftwareDeployment Lösung). NSClient++ benötigt jedoch weiterhin einen gewissen Teil der nsc.ini, die Einstellungen in der Sektion [Settings] und die Auflistung der zu ladenden Module.

Serie NSClient++ – Teil 8: Eigene Skripte

NSClient++ verfügt über eine Vielzahl von Abfragemöglichkeiten um Windows Server zu überwachen.
Viele der Überwachungsmöglichkeiten und Konfigurationsparameter für diese wurden bereits in der NSClient++ Serie vorgestellt.
Immer dann wenn weitere Applikationen, Hardware, Logdateien etc. überwacht werden sollen stoßen die NSClient++ Module überwiegend an die Grenzen ihrer Möglichkeiten. Eigene Skripte müssen her…
Das Modul CheckExternalScripts ist genau für diesen Zweck gedacht und dient als Wrapper um eigene Skripte auszuführen. Vorrausetzung hierfür ist das Windows die Skriptsprache unterstützt und das jeweilige Skript einen validen Icinga/Nagios Returncode zurückliefert.

NSClient++ und externe Skripte

In der NSC.ini beeinflussen die Folgenden Sektionen das verhalten der “ExternalScripts”:
[External Script] beschreibt das verhalten beim ausführen der Skripte. Mit “command_timeout=” wird der maximale Ausführungszeitrahmen (in Sekunden) eines Skripts/Plugins durch NSClient++ definiert. Achtung: NSClient++ bricht danach die Ausführung ab, unter Umständen kann das Skript jedoch weiterlaufen. Die Optionen “allow_arguments=” und “allow_nasty_meta_chars=” definieren ob beim ausführen von Icinga/Nagios Seite aus Argumente mit übergeben werden dürfen und ob “unangenehme” Zeichen übermittelt werden dürfen (z.B.: |`&><'"\[]{} ). Unter [Script Wrappings] werden die Interpreter für die verschiedenen Dateieindungen der Skripte konfiguriert. Mit den Variablen %SCRIPT% und %ARGS% wird definiert an welcher Stelle das Skript ausgeführt werden soll und wo beim Aufruf die Argumente übergeben werden.

vbs=cscript.exe //T:30 //NoLogo scripts\lib\wrapper.vbs %SCRIPT% %ARGS%
ps1=cmd /c echo scripts\%SCRIPT% %ARGS%; exit($lastexitcode) | powershell.exe -command -

[External Scripts] gibt nun schlussendlich die eigentlichen Skripte und ihre Ausführungsparameter an:

check_icinga.bat=scripts\icinga.bat

Oder auch, ohne den Skriptwrapper zu nutzen:

check_powershell_exchange=cmd /c echo scripts\exchange.ps1 | powershell.exe -command -

Sollen Skripte verwendet werden, die außerhalb des NSClient Verzeichnisses liegen muss jeweils der absolute Pfad verwendet werden.

Perlskripte unter Windows

Um Perl Skripte über den NSClient++ auszuführen benötigt man unter Windows entweder einen Perl Interpreter, z.B.: Strawberry Perl oder man kompiliert die jeweiligen Plugins zuvor mit dem Perl Modul PAR::Packer zu ausführbaren .exe Dateien:

$ perl -MCPAN -eshell
cpan> install Bundle::libwin32
cpan> install PAR::Packer
$ pp -o check_test.exe check_test.pl

Wer bei der Installation von PAR::Packer auf einen Fehler stößt: http://www.nntp.perl.org/group/perl.par/2012/03/msg5306.html

Serie NSClient++ – Teil 7: NSCA

In den vorherigen Teilen der NSClient++ Serie wurden die Möglichkeiten der aktiven Überwachung eines Windows Servers mit NSClient++ aufgezeigt.
NSClient++ verfügt, neben den Modulen für aktive Abfragen (NSClientListener, NRPEListener), auch über ein Module für passive Abfragen, NSCAAgent.
NSCA (Nagios Service Check Acceptor) ist ein Nagios/Icinga Add-On bestehend aus zwei Komponenten:
* NSCA Server: Der NSCA Daemon auf dem Monitoringsystem welcher passive Checkergebnisse an nimmt und diese in die Nagios- bzw. Icinga-Commandpipe schreibt.
* NSCA Agent: Der NSCA Agent auf dem Clientsystem welcher die Checkergebnisse an den NSCA Server weiterleitet.
Eine gute Anleitung für die Installation des NSCA Servers findet man in der Icinga Dokumentation: http://docs.icinga.org/latest/de/nsca.html#id3878652
NSClient++ verlangt einige Einstellungen in der NSC.ini um NSCA zur Aktivierung und Konfiguration.
Zuallererst muss das NSCAAgent Modul geladen werden:

; NSCA Agent if you enable this NSClient++ will talk to NSCA hosts repeatedly (so dont enable unless you want to use NSCA)
NSCAAgent.dll

Anschließend muss NSCA konfiguriert werden. Wichtig ist hierbei zu wissen welche encryption_method und ggf. welches password auf der Seite des NSCA Servers (nsca.cfg) definiert wurde. Beide Optionen, Verschlüsselung und Passwort, müssen mit der NSCA Agent Konfiguration übereinstimmen.

[NSCA Agent]
;# CHECK INTERVALL (in seconds)
;   How often we should run the checks and submit the results.
interval=120
;# ENCRYPTION METHOD
encryption_method=1
;# ENCRYPTION PASSWORD
;  This is the password/passphrase that should be used to encrypt the sent packets.
password=icinga
;# LOCAL HOST NAME
;  The name of this host (if empty "computername" will be used.
hostname=windows-server
;# NAGIOS SERVER ADDRESS
;  The address to the nagios server to submit results to.
nsca_host=icinga.training.netways.de
;# NAGIOS SERVER PORT
;  The port to the nagios server to submit results to.
nsca_port=5667

Der hostname muss mit dem in Nagios/Icinga definierten Hostobjekt übereinstimmen.
Nach der Konfiguration des NSCA müssen die NSCA Commands definiert werden, jene Checks die NSClient++ ausführen soll und an den Monitoringserver senden soll. Hierbei muss jeweils das Checkcommand mit den dazugehörigen Argumenten angegeben werden:

[NSCA Commands]
CPU=CheckCPU warn=80 crit=90 time=15m time=10m time=5m ShowAll=long
Memory=checkMem MaxWarn=80% MaxCrit=90% ShowAll=long type=physical
Disk-C=CheckDriveSize MaxWarn=80% MaxCrit=90% ShowAll=long Drive=c:

Die Namen der Commands müssen mit den in Nagios/Icinga definierten Serviceobjekte übereinstimmen.
Damit der NSCA Server die empfangenen Checks auch richtig an Nagios/Icinga weiterleiten kann muss dort der jeweilige Service, als passiver Service, definiert werden.
Beispiel:

define service{
        use                     generic-service
        host_name               windows-server
        service_description     CPU
        check_command           check_dummy!3 "No results received, check NSCA"
        active_checks_enabled   0
        check_freshness         1
        freshness_threshold     600
        }

Serie NSClient++ – Teil 6: Dateiattribute

Im sechsten Teil der NSClient++ Serie geht es um die Überwachung von verschiedenen Dateiattributen. Hierzu zählen unter anderem Dateigröße, Dateialter sowie Dateiversion.
Das NSClient++ Modul check_disk.dll verfügt über den Befehl CheckFiles, welcher es ermöglicht verschiedene Dateiattribute abzufragen. CheckFiles ist seit NSClient++ 0.3.9 verfügbar.
Dateigröße
Die Dateigröße von Dateien oder Dateien eines Verzeichnisses lässt sich ebenfalls über CheckFiles überwachen. Hierbei können bestimmte Dateien zur Überwachung angegeben werden, Dateien mit einer bestimmten Dateiendung bis hinzu Dateien die in einem Verzeichnis in mehreren Ordnertiefen liegen.
Eine Abfrage auf Dateien die größer als 1 MB im Verzeichnis c:/temp sind sieht wie Folgt aus:

$ ./check_nrpe -H 192.168.119.3 -c CheckFiles -a path=c:\\temp filter="size > 1M" "syntax=%filename%: %size%" MaxWarn=1 MaxCrit=2
vm.log: 2.67M, found files: 1 > warning|'found files'=1;1;2

MaxWarn und MaxCrit definiert den Warning- bzw. Critical-Schwellwert und mit syntax wird das Ausgabeformat vorgegeben.
Dateialter
Das Alter einer Datei oder mehrerer Dateien in einem Verzeichnis lässt sich mit definierten Schwellwerten wie folgt überwachen:

$ ./check_nrpe -H 192.168.119.3 -c CheckFiles -a path=c:\\temp  filter="written <-2d" "syntax=%filename%" MaxWarn=1 MaxCrit=2
old_nsc.ini, vm.log_20120521_133739.log, vm.log_20120521_133739.log, found files: 3 > critical|'found files'=3;1;2

Die Filtereinstellungen bewirken, dass Dateien, deren Änderungszeitpunkt älter als 2 Tage ist, herausgefiltert werden. Die Angabe von d steht in diesem Fall für Tage. Folgende Zeitdefinitionen gibt es für die time-expression:
s (second), m (minute), h (hour), d (day), w (week)
Dateiversion
Die Version einer Datei kann über den Filter version abgefragt werden:

$ ./check_nrpe -H 192.168.119.3 -c CheckFiles -a path=c:\\temp pattern=*.exe  "filter=version > 1" "syntax=%filename%: %version%" MaxCrit=1
explorer.exe: 6.1.7601.17567, found files: 1 > critical|'found files'=1;0;1

Der Filter für version arbeitet mit numeric-expression.
Die Schwellwerte können entweder über MaxWarn und MaxCrit definiert werden um so auf die Anzahl der Dateien zu schauen oder mit warn und crit definiert werden um so eine genauere Warning- bzw. Criticalschwelle zu definieren:

...warn=gt:1 crit==1...

Weitere Möglichkeiten des Commands CheckFiles sind im NSClient++ Wiki zu finden: http://nsclient.org/nscp/wiki/CheckFiles

Serie NSClient++ – Teil 5: Neue Version NSCP 0.4.0

NSClient++ wurde anfang des Monats in einer neuen Version veröffentlicht; NSClient++ 0.4.0.
Die größte Veränderung zur Version 0.3.9 ist der neue, veränderte “Core”. Das Herz des NSClient wurde dahingehend erwetitert das es um eine neue Commandline Syntax, neue Module und Checks sowie neue, integrierte Bibliotheken erweitert wurde.
Bis dato war es möglich beliebige Skripte durch den NSClient ausführen zu lassen, soweit ein Interpreter auf dem System vorhanden war.
Konnte der Windows Server PowerShell Skripte ausführen, konnte NSClient++ dies auch. In der akutellen Version kann NSClient++ von Hause aus Skripte in Python, LUA, .NET und C Plugins (C, C++, etc) ausführen.
Die “alte”, klassische nsc.ini wurde durch eine neue, “aufgeräumte” Konfigurationsdatei erstetzt. Außerdem ist es weiterhin möglich die Konfiguration in die Registry auszulagern um diese beispielsweise über eine Grouppolicy zu verteilen.
Die neue nsclient.ini hat folgendes Konfigurationslayout:
Einstellungen werden nicht mehr ein- oder auskommentiert, sondern aktiviert oder deaktivert.

[/modules]
; CheckDisk - CheckDisk can check various file and disk related things. The
current version has commands to check Size of hard drives and directories.
CheckDisk = 1
; Event log Checker. - Check for errors and warnings in the event log. This is
only supported through NRPE so if you plan to use only NSClient this wont help
you at all.
CheckEventLog = 0

Defaultwerte sind nicht mit in der nsclient.ini enthalten sondern müssen nur noch bei Abweichungen eingetragen werden.
Diese haben allerdings nicht mehr das alte Format sondern es wurden alle _ (underscores) durch Leerzeichen ersetzt.

; Undocumented section
[/settings/default]
; ALLOWED HOSTS - A comaseparated list of allowed hosts. You can use netmasks (/syntax) or * to create ranges.
allowed hosts = 192.168.119.145
; Section for NRPE (NRPEListener.dll) (check_nrpe) protocol options.
[/settings/NRPE/server]
allow arguments = 1
allow nasty meta chars = 1
use ssl = 1

Für die Kommunikation mit dem NSClient++ empfehlen wir, wie auch schon in den voherigen Blogposts dieser Serie, die NRPE Schnittstelle.
Für kommende Versionen ist eine native WMI Schnittstelle sowie der Linux Support geplant.
Wie der aktuelle Entwicklungsstand ist und was noch auf der TODO Liste steht kann aus dem Changelog entnommen werden: http://nsclient.org/nscp/browser/nscp/changelog?order=name

Icinga Training in Düsseldorf, die Erste….

Icinga Availibility Monitoring
Eigentlich war mein Ziel des Blogposts für diese Woche die NSClient++ Serie, die nun schon seit zwei Jahren ruht, endlich fortzusetzen. Dies wird auch in nächster Zeit geschehen, der Draft dazu befindet sich in der Vollendung, versprochen! Aber nun zum aktuellen Post für diese Woche:
Im letzten Jahr haben wir uns entschlossen unser Schulungsprogramm neben Nürnberg auf weitere Standorte auszuweiten, nämlich Zürich und Düsseldorf. Leider mussten wir das erste Puppet Training in Zürich krankheitsbedingt, absagen. Das nächste Puppet Training in Zürich ist aber bereits datiert und findet vom 26. Juni bis 28. Juni statt.
Schulungslocation DüsseldorfIn Düsseldorf fand letzte Woche aber unser erstes Icinga/Nagios Availability Monitoring Training statt und für die Kollegen aus dem Event Bereich als auch für unsere Trainer ist das erste Training an einem neuen Standort natürlich immer mit einem großen organisatorischem Aufwand verbunden. Daher haben wir uns sehr über das gute Feedback der Teilnehmer (nach Schulnoten gab es eine 1,5) gefreut.
Bei allen unseren Trainings ist es uns wichtig, dass sich die Teilnehmer wohlfühlen und während der Schulungstage eine gute Atmosphäre herrscht. Bei den Nagios/Icinga Trainings reisen die Teilnehmer so schon am Vortag an damit am ersten Tag des Trainings stressfrei und ausgeruht gestartet werden kann. Und neben dem theoretischen Teil des Schulungsinhaltes ist es unser Ziel den Teilnehmern die ersten Schritte mit Icinga/Nagios durch viele praxisnahe Aufgaben leichter zu machen: Wie überwache ich meine Linux/Unix Server? Wie definiere ich Businessprozesse, um diese anschließend zu überwachen?
Abendveranstaltung Icinga Availability Monitoring TrainingAbseits des „Lernstresses“ und passend zum Bergfest fand dieses mal die Abendveranstaltung im Clube Portugues statt. Schöne Atmosphäre, lustige und interesannte Gespräche, eben eine rundum gelungene Abendveranstaltung.
Ich möchte mich hier nochmals bei allen Teilnehmern für eine sehr schöne Woche in der Landeshauptstadt Düsseldorf bedanken. Das sonnige und warme Wetter war sicher auch nicht ganz unbeteiligt an der guten Stimmung. Die lange Vorbereitungszeit und der damit verbundene Aufwand haben sich gelohnt, Düsseldorf wir kommen wieder, nächstes mal am 21.-25. Mai 2012.
Das nächste Icinga/Nagios Training in Nürnberg findet übrigens vom 07. – 11. Mai statt.

OpenLDAP 2.4.x und die ACL

In vergangenen Blogposts habe ich erwähnt welche Möglichkeiten OpenLDAP 2.4.x bei der Replikation bietet und wie man neuerdings weitere Schema zu OpenLDAP hinzufügen kann.
Mit dem dynamischen Backend cn=config hat sich auch das bearbeiten der ACL (Access Control List) verändert.
Unter OpenLDAP < 2.4.x war die slapd.conf die richtige Anlaufstelle um Benutzern, Gruppen etc. den Zugriff auf bestimmte Attribute, Objekte, Teilbäume... zu ermöglichen. cn=config als dynamisches Backend fordert hier eine neue Vorgehensweise um die ACL zu administrieren.
Generell gibt es zwei Möglichkeiten neue Zugriffsrechte zu definieren oder bestehende zu ändern.

  • Änderungen direkt in das entsprechende Backend-LDIF eintragen (olcDatabase={1}hdb oder olcDatabase={1}bdb).
  • Änderungen über ein separates LDIF File mit ldapadd oder ldapmodify zu importieren.

Wie bei allen Dingen die im Backend geändert werden gilt auch hier, alle Änderungen werden während der Laufzeit übernommen und erfordern keinen Reload des OpenLDAP Daemons.
Nun aber ans Eingemachte…
Bevor wir eine Access Control List aufbauen können, müssen wir wissen wie die Definition auszusehen hat und welche Möglichkeiten der Definition es gibt.
Die Definition einer ACL hat sich zu älteren OpenLDAP Versionen nicht groß geändert und immer den Folgenden grundlegenden Aufbau:

olcAccess: {n} to "what" by "who" "access"

Was in vollendeter Form z.B. so aussehen kann:

olcAccess: {2}to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read by anonymous none

Das Beispiel ermöglicht den Mitgliedern der Gruppe “admins” Schreibrechte auf den Inhalt der Organisationseinheit “company”. Andere Benutzer haben Leserechte und Anonyme haben keinerlei Rechte.
Die {2} definiert die Reihenfolge der Verarbeitung. Die Access Control List wird von oben nach unten abgearbeitet. Regeln mit {1} greifen vor Regeln mit {2}, {3} etc… und werden auch so angewendet.
Eine Standardregel, die meist sehr weit oben in der ACL angesiedelt ist, lautet:

{1}to * by self write by dn="cn=admin,dc=netways,dc=org" write by * read

Diese Regel verhindert meist das folgende Regeln überhaupt Wirkungsvoll sind. Die Regel sagt aus das Überall der Benutzer “admin” Schreibrechte hat und jeder andere Benutzer Leserechte hat (und Benutzer auf die eigenen Objekte Schreibrechte haben). Ist diese Regel weit oben in der ACL angesiedelt haben die darauf folgenden Regeln meist keine Wirkung, daher empfiehlt es sich hier die Reihenfolge anzupassen.
Eine sehr detaillierte Anleitung über die Möglichkeiten der Definitionen gibt hier die OpenLDAP 2.4 Dokumentation: http://www.openldap.org/doc/admin24/access-control.html
Die Dokumentation entält, meiner Meinung nach, eine sehr gute und verständliche Beschreibung der “what” Definition:
0: o=suffix
1: cn=Manager,o=suffix
2: ou=people,o=suffix
3: uid=kdz,ou=people,o=suffix
4: cn=addresses,uid=kdz,ou=people,o=suffix
5: uid=hyc,ou=people,o=suffix
dn.base=”ou=people,o=suffix” trifft 2
dn.one=”ou=people,o=suffix” trifft 3 und 5
dn.subtree=”ou=people,o=suffix” trifft 2, 3, 4 und 5
dn.children=”ou=people,o=suffix” trifft 3, 4 und 5
Welche unterschiedlichen Möglichkeiten der “what” “who” und “access” Definition man hat beschreibt das Schaubild unter “8.2. Access Control via Static Configuration”.
Bisschen was aus der Praxis…
Damit dieser Blogpost nicht allzu theoretisch wird ein paar Code snippets die das Thema ACL ggf. etwas leichter machen.
Definitionen zur ACL hinzfügen:

changetype: add
add: olcAccess
olcAccess: to dn.subtree="ou=company,dc=netways,dc=org" by group.exact="cn=admins,ou=users,dc=netways,dc=org" write by * read

Neue Definitionen werden in der Liste ganz am Ende aufgeführt und bekommen immer die höchste Listenzahl {}
Definition in der ACL ändern:

changetype: modify
delete: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * search
-
add: olcAccess
olcAccess: to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Definitionen abändern erfordert ein “delete: olcAccess” und ein “add: olcAccess”. Die “-” sind im LDIF wichtig.
Definition an bestimmter Stelle in ACL ändern:

changetype modify
delete: olcAccess
olcAccess: {1}
-
add: olcAccess
olcAccess: {1}to dn.children="ou=contacts,dc=netways,dc=org" by * write
-

Hier wird der Inhalt von {1} mit dem neuen überschrieben.
Noch was Gutes zum Schluß…
Das Backend cn=config kann mit der Zeit sehr groß und sehr komplex werden.
Insbesondere dann wenn die ACL sehr groß geworden ist.
Zur Administration des Backends ist es daher Empfehlenswert auf einen gut strukturieren und übersichtlichen LDAP Browser / Editor zurück zu greifen.
Ich verwende sehr gerne Apache Directory Studio oder unter Windows LDAPAdmin.
Eine Verbindung zur cn=config erfolgt über den administrativen Backendbenutzer (meist cn=Manager,cn=config oder cn=admin,cn=config) und über die BaseDN cn=config.

Openldap Schema Erweiterung cn=config

In dem Artikel wurde beschrieben welche Neuerungen in OpenLDAP 2.4 enthalten sind.
In diesem Artikel möchte ich kurz darauf eingehen wie man das Schema mit dem cn=config Konfigurationsbackend erweitern kann.
Um neue Schema einzubinden müssen zunächst alle vorhanden inkl. dem neuen Schema in ein LDAP Format exportiert werden.
1. Eine schema_convert.conf erstellen mit dem Inhalt aller vorhandenen Schema:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/netways.schema

Wichtig: Das neue Schema (in diesem Fall netways.schema) muss unter /etc/openldap/schema liegen.
2. Schema an einen temporären Ort exportieren:

# mkdir /tmp/ldapexport
# slaptest -f schema_convert.conf -F /tmp/ldapexport

3. Editieren der Datei /tmp/ldapexport/cn=config/cn=schema/cn={8}netways.ldif und folgende Attribute abändern:

dn: cn=netways,cn=schema,cn=config
...
cn: netways

Folgende Zeilen am Ende der Datei entfernen:

structuralObjectClass: olcSchemaConfig
entryUUID: 10dae0ea-0760-102d-80d3-f9366b7f7757
creatorsName: cn=config
createTimestamp: 20080826021140Z
entryCSN: 20080826021140.791425Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20080826021140Z

4. Abschließend muss das erweiterte Schema mit ldapadd wieder importiert weden.

# ldapadd -x -D cn=admin,cn=config -f /tmp/ldapexport/cn=config/cn=schema/cn={8}netways.ldif

In unserem LDAP Backend (cn=config) sollte nun die DN: cn={8}netways,cn=schema,cn=config auftauchen.
Anmerkung:
Der Name {8}netways kann variieren.
Mit folgendem Befehl kann der korrekte Name herausgefunden werden:

slapcat -f schema_convert.conf -F /tmp/ldapexport -n 0 | grep netways

Icinga Monitoring Schulung

Open Source Produkte haben für viele Unternehmen an erster Stelle den großen Anreiz Geld bzw. Ressourcen zu sparen. Das klingt Anfangs sehr schlüssig und jeder Controller oder Buchhalter wird diesen Ansatz befürworten. Gerade der Markt an System- oder Netzwerkmonitoring Produkten bietet neben den Open Source Produkten wie Icinga, Nagios, OpenNMS etc. eine Vielzahl mehr an propertären Produkten z.B.: HP OpenView, Microsoft System Center Operations Manager (SCOM), CA Unicenter/Spectrum, DELL Data Center System Management uvm. Nach dem Vergleich der einzelnen Produkte mit den Open Source Alternativen zeigt sich schnell in welchem finanziellen Rahmen sich die Kosten für ein weitestgehend betriebssystemunabhängiges und mandantenfähiges Monitoringsystem mit propertären Lösungen bewegen.
Daraus nun folglich zu schließen, die OpenSource Lösungen seien umsonst oder gar kostenfrei stimmt leider auch immer nur im buchhalterischen Sinne mit Blick auf die Einkaufszahlen. Das Implementieren einer Open Source Lösung, ohne Consulting kostet “Manpower”, also interne, vorhandene Ressourcen. In der heutigen, schnell wachsenden und mit täglich neuen Herausforderungen versehenen IT wird es immer schwieriger diese internen Ressourcen über einen langen Zeitraum für das Einarbeiten in diese Themen freizugeben.
Also was machen? Externes Consulting kaufen wäre eine Option, das weiterbilden der eigenen Mitarbeiter eine andere.
Nach dem Erfolg unserer Nagios Schulungen bieten wir nun auch Icinga Schulungen an.
Von der Installation, über die Konfiguration bis hin zur Anwendung verschiedenster AddOn Produkte vermittelt unsere Icinga Schulung auch, was es im Bereich des neuen Webfrontends Icinga-Web zu beachten gibt. – Wie integriere ich die AddOn Produkte in Icinga-Web, welche Möglichkeiten der Benutzerverwaltung und des Rechtemanagements habe ich, was muss ich bei der Installation beachten, welche Best Practice Tips gibt es für meine eigene Installation abweichend vom Standard.
Aus vielen großen Icinga und Nagios Installation möchten wir unser gewonnenes Wissen und unsere vielen Erfahrungen teilen und schon angefangen bei der Grundinstallation aufzeigen, wie welche Option am sinnvollsten genutzt wird. Der Workshop hilft nicht nur das eigene Wissen zur erweitern sondern bietet auch Platz zum Erfahrungsaustausch untereinander.
Weitere Informationen zu den nächsten Training-Terminen sind hier zu finden: http://www.netways.de/de/units/training/icinga
Ich freue mich auf Sie….