Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

 
41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.
Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.
Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.
Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Things done wrong: Benutzermanagement

Homer Simpson
Ich hatte bereits angekündigt oder viel mehr angedroht mich mit dem Thema Benutzermanagement auseinander zu setzen. Anfangen möchte ich damit zu erläutern was ich darunter verstehe bzw. was meine Ziele hierbei sind. Ein Benutzer soll meiner Definition eines guten Benutzermanagement nach eindeutig identifiziert werden und sich mit möglichst viel Komfort und Sicherheit dort anmelden können, wo er berechtigt ist und eben nur dort.
Klingt ja eigentlich ganz einfach, aber als Einstieg denkt nun bitte jeder mal zurück an seinen ersten Arbeitstag und überlegt wie viele Kennungen/Passwort-Briefe er damals bekommen hat. Die wenigsten werden die Frage wohl damit beantworten können genau eine Kennung mit zugehörigem Passwort erhalten zu haben. Nun denkt weiter an die ersten Arbeitswochen und überlegt wie oft noch fehlende Berechtigungen oder lokale Benutzerkonten und Passwörter nachträglich erstellt werden mussten. Und nun einfach mal wie oft am aktuellen Arbeitstag eine Passworteingabe erforderlich war oder den letzten Tag an dem eine Passwortänderung fällig war. Wenn ich damit schon das persönliche Horrorszenario von jemand beschrieben habe, dann versetzt sich derjenige bitte in die Rolle des Consultants, denn mir geht es üblicherweise jede Woche so.
(mehr …)

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

LConf Backend releases 1.4.4 & 1.5.0-RC1

lconf_logoWe’ve recently released LConf 1.4.3 and the first beta of 1.5.0 including performance improvements. This time, we’ve come around a couple of bugs with the Icinga 2 export and therefore release 1.4.4.

Additionally we’re working on getting things straightened up for the final 1.5.0 release. To get things going aside from performance improvements, there’s a new deployment script capable of Icinga 2 zones.d as well as additional schema changes (icon_image). Keep your fingers crossed, 1.5.0 is scheduled end of Q1. This time it’s 1.5.0-rc1 time.icinga_logo_200x69

Grab them while they’re hot and let us know how much better 1.5.x scales!
 

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Wie kann ich einen Teil meiner Arbeit loswerden? – Oder: LConf und ACL

Da ich persönlich eher zu den faulen Menschen gehöre und sich bestimmt jeder Admin auch dazu zählen kann, will ich in diesem Blogpost darauf eingehen wie man zumindest die Aufgabe Monitoring ein wenig auf fleißige Kollegen oder auch Azubis und Praktikanten verschieben kann. Natürlich möchte man sich im Nachhinein nicht mehr Arbeit gemacht haben, indem man Fehlersuche betreiben muss, daher ist mein Ansatz: graphische Administration und eingeschränkte Berechtigungen.
Unser Werkzeug für graphische Administration LConf dürfte mittlerweile wohl bekannt sein. Wem dieses gar nichts sagt kann sich ja mal das Webinar anschauen. Kurz zusammengefasst verwendet LConf ein LDAP-Backend, bietet Vererbung und Templates sowie ein hübsches Frontend.
Gebe ich nun dem Azubi eine kurze Einweisung und volle administrative Rechte, sehe ich mich schon statt beim Feierabend-Bier beim Restore und anschließendem “Hätte ich’s bloß gleich selbst gemacht” und “Wenn etwas richtig gemacht werden soll, muss man es selber machen”. Und damit sich niemand diskriminiert fühlt, gilt das gleiche natürlich für alle anderen Kollegen wie Windows- oder Netzwerk-Admins. 😉
Diese Grundhaltung höre ich doch des öfteren bei Kunden und Schulungsteilnehmern, daher müssen also eingeschränkte Rechte her und dies ermöglicht LDAP zum Glück leicht mittels ACL. Voraussetzung hierfür ist ein Benutzer oder eine Gruppe innerhalb des LDAP. Da der LConf-Connection-Manager mir erlaubt eine Verbindung zu erstellen und dann einer Gruppe Zugriff auf diese zu erlauben, reicht mir ein Benutzer.
Diesen lege ich mir folgendermaßen an:

  1. Passwort-Hash generieren:
    # slappasswd
    New password: awesome
    Re-enter new password: awesome
    {SSHA}ZOmXcrADeKGkthMlJ3PZwKbyM8bnbP5t
  2. Datei user.ldif für den Import bauen:
    dn: cn=myuser,ou=users,dc=icinga,dc=lab
    objectClass: organizationalPerson
    cn: myuser
    sn: User
    description: My User
    userPassword: {SSHA}ZOmXcrADeKGkthMlJ3PZwKbyM8bnbP5t
  3. Benutzer mit administrativem Account einspielen:
    ldapadd -x -h localhost -D cn=admin,dc=icinga,dc=lab -W -f user.ldif

Nun muss ich mir überlegen wie meine Grundstruktur aussieht und worauf ich meinen Benutzer berechtigen will. Mein Ansatz ist hierbei dem Kollegen auf einen Teilbaum gemäß seiner Zuständigkeit schreibend zu berechtigen und Templates sowie grundlegende Objekte lesend zur Verfügung zu stellen. Hierfür müssen die Standard-Zugriffsregeln teilweise gelöscht werden bevor die neuen gesetzt werden, da diese in der gespeicherten Reihenfolge abgearbeitet werden.
Die Vorgehensweise ist hierbei:

  1. Datei access.xml für Import bauen:
    changetype: modify
    dn: olcDatabase={1}hdb,cn=config
    delete: olcAccess
    olcAccess: to dn.base="" by * read
    -
    delete: olcAccess
    olcAccess: to * by self write by dn="cn=admin,dc=icinga,dc=lab" write by * read
    -
    add: olcAccess
    olcAccess: to dn.base="dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.base="ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.base="ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=global,ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=Templates,ou=LConf,dc=icinga,dc=lab" by users read
    -
    add: olcAccess
    olcAccess: to dn.subtree="ou=myconfig,ou=IcingaConfig,ou=LConf,dc=icinga,dc=lab" by dn="cn=myuser,ou=users,dc=icinga,dc=lab" write
    -
    add: olcAccess
    olcAccess: to * by self write by dn="cn=admin,dc=icinga,dc=lab" write
  2. Importieren unter Nutzung der ldapi-Schnittstelle:
    ldapmodify -Y EXTERNAL -H ldapi:/// -f access.ldif

Nun noch in dem Wissen, dass die Kollegen nicht so leicht was kaputt machen können, die Verbindung im LConf-Frontend angelegt, die Kollegen berechtigt und eine Einweisung im Wiki hinterlegt. Danach heißt es dann heim zum Feierabend-Bier während die fleißigen Kollegen mit den neuen Rechten Hosts und Services ins Monitoring aufnehmen! 😉
In diesem Sinne viel Erfolg beim Verteilen der Arbeit und natürlich Prost!

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Aufzeichnung des LConf-Webinars ist online!

lconf_logo
Die Aufzeichnung unseres gestern geführten Webinars steht ab sofort zum Ansehen auf YouTube bereit. Vielen Dank nochmal an alle Teilnehmer für die Aufmerksamkeit. Im Webinar wurden folgende Punkte durchgesprochen:

  • Kurzvorstellung NETWAYS
  • Einführung LDAP
  • Vorteile/Funktionen LConf mit LDAP

natürlich wurde dann noch ausführlich eine Live-Demo gezeigt.

 
Nicht vergessen: Nächste Woche führen wir ein Webinar zum Thema Puppet. Ein Blick in unser Webinar-Archiv lohnt sich, dort gibt es auch die Präsentationsfolien zum Download!

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

NETWAYS Webinar für das Nagios/Icinga Konfigurationstool LConf

lconf_logo
Neben dem Bearbeiten von Nagios/Icinga Konfigurationsdateien über die Command-Line, gibt es noch Web-basierte Lösungen, welche die Konfiguration deutlich vereinfachen.
 
Eines dieser Tools ist der LConf. Ein aus dem Audi Projekt entstandenes Tool, welches die Nagios-Konfiguration über eine LDAP Struktur abbildet und an Nagios/Icinga zurück exportieren kann.
In diesem Webinar, werden wir näher auf die Möglichkeiten, die Vererbungslogik sowie den daraus resultierenden Vorteil eingehen.
Die Registrierung erfolgt wie immer über unser Webinar Center. Das Webinar startet am Mittwoch 09. Oktober um 14 Uhr.
Wir freuen uns auf eine rege Teilnahme!
Übrigens: nächste Woche Donnerstag (17.10.2013) halten wir ein Webinar über Puppet.

Georg Mimietz
Georg Mimietz
Lead Support Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Weekly Snap: MCollective, CCache & Apache Tips

weekly snap15 – 19 July offered tips for Puppet users, developers and sys admins alike, as well as news from the event circuit.
Starting with events, Eva counted 99 days to the OSMC 2013 with Rihards Olups’ presentation on Zabbix 2.0 while Lennart reported from DevOps Days Down Under in Australia.
Thomas then recommended Puppet users to try the MCollective orchestration framework as Gunnar upped the speed on his builds with ccache.
Lastly, Dirk offered a handy tip for large environments by showing how to integrate multiple LDAP servers in Apache authentication.

Apache und viele, viele User

Kollege Lennart hat zwar schon dankenswerterweise einiges zu Apache, Openldap und Active Directory geschrieben trotzdem ist dieses Thema noch nicht völlig erschöpft. Ich möchte diesmal die Anleitung liefern wie man mehrere verschiedene LDAP-Server bei der Apache-Authentifizierung nutzt. Auch nutzbar ist diese Lösung um mehrere Einstiegspunkte in den gleichen Verzeichnisbaum zu bekommen.
Die einen fragen sich nun wo soll da bitte die Schwierigkeit sein, die anderen wozu sollte man so etwas brauchen. Die Schwierigkeit hierbei stellt der LDAP-Provider dar, der nur eine LdapAuthURL akzeptiert. Der Grund dafür mehrere zu brauchen können mehrere Verzeichnisdienste für verschiedene Anwendergruppen sein oder auch ein Struktur im Active Directory, bei der sonst neue Gruppen gebildet und gepflegt werden müssten oder ein Verschieben der Benutzer innerhalb des Baums aus organisatorischen oder gar technischen Gründen nicht möglich ist.
Die Lösung hierfür heißt mod_authn_alias (oder ab 2.4 mod_authn_core). Mit diesem Modul lässt sich ein Alias für einen Authentfizierungs-Provider erstellen, so dass es möglich wird diesen mehrfach zu verwenden. Die Konfiguration könnte dann folgendermaßen aussiehen:

<AuthnProviderAlias ldap admins>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=admins,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias>
<AuthnProviderAlias ldap entwickler>
   AuthLDAPBindDN "CN=serviceaccount,DC=netways,DC=de"
   AuthLDAPBindPassword strenggeheim
   AuthLDAPURL "ldap://server1.netways.de server2.netways.de/OU=entwickler,DC=netways,DC=de?samaccountname"
</AuthnProviderAlias> 

Diese Konfiguration muss einmalig und vor der Verwendung eingebunden werden. Daher bietet sich ein Dateiname wie 00provider.conf an mit dem die Konfiguration im Apache-Konfigurationsverzeichnis abgelegt wird.
Für die Verwendung bietet es sich dann eine Datei auth.inc anzulegen, die dann in den einzelnen Konfigurationsdateien für die Webanwendungen mit include eingebunden werden kann. Diese sieht dann beispielsweise so aus:

AuthName "Icinga Access"
AuthType Basic
AuthBasicProvider admins entwickler
Require valid-user

Wer zusätzlich noch einen Fallback für einen anderen Provider benötigt kann diesen einfach hinzufügen und je nach Apache-Version einen Blick auf AuthzLDAPAuthoritative (2.2) oder RequireAny (2.4) werfen.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Weekly Snap: InGraph, Google Analytics for Prestashop, LDAP & Distributed Shell

weekly snap26 – 30 November ended the month with mini guides on Distributed Shell and LDAP, Google Analytics and Prestashop, alongside some familiar hardware, InGraph and news from Down Under.
Eric gave a sneak preview to features planned for coming releases of InGraph, concluding The Ultimate Guide to InGraph.
Stefan fiddled with batch mode clusters via ssh using Distributed Shell dsh, while Lennart showed how to use LDAP filters for authorisation settings in recursive groups.
Georg then showed how to make the most of Google Analytics in Prestashop and introduced one of his best sellers, the HWg-STE network thermometer.
On sabbatical, Birger got settled into Sydney and reflected on a successful Movember 2012 as Bernd shared his thoughts on Africa’s internet landscape.

SSO bei Apache mit gruppenbezogener Authentifizierung gegen ein Active Directory

Heute soll sich dieser Blogeintrag also um Single Sign On im Apache- und Active Directory-Umfeld drehen. Ziel ist es, sich an einem Webserver per Kerberos-Ticket zu authentifizieren und nachgelagert zu prüfen, ob der Benutzer sich ebenfalls in der Gruppe befindet, dessen Mitglieder Zugriff auf die Wibsite erhalten dürfen.
Zuerst muss ein Benutzer im Active Directory angelegt werden. Danach erzeugen wir auf unserem Domain Controller einen Schlüssel und fügen diesem Benutzer eine PrincipalName hinzu. Also Verschlüsselung wählen wir RC4-HMAC, da dies von Windows XP unterstützt wird. Die ab Windows Server 2008 hinzugekommenden Verschlüsselingen auf AES basierend werden erst von Windows Vista und Windows 7 unterstützt.
ktpass -out apache2.keytab \
   -mapuser www@NETWAYS.DE \
   -princ HTTP/www.netways.de@NETWAYS.DE \
   -pass login123 \
   -ptype KRB5_NT_PRINCIPAL \
   -crypto RC4-HMAC-NT \
In unserem Beispiel haben wir den Benutzer www angelegt. Unsere NS-Domäne lauetet netways.de und unser Kerberos-Realm NETWAYS.DE. Mit dem Kommando ktpass weisen wir nun diesem Benutzer über die Option -mapusr und -princ den PrincipalName HTTP/www.netways.de@NETWAYS.DE zu. Der Schlüssel erhält das Passwort login123 mit +rndpass kann man diesen auch zufällig erzeugen lassen. Erzeugt man den Schlüssel jedoch zufällig, ist es dann aber leider nicht möglich den Schlüssel auf dem Linux-Serverauf Korrektheit zu überprüfen.
Nachdem wir nun den Schlüssel erzeugt haben, kopieren wir die Datei apache2.keytab auf sicherem Wege auf unseren Webserver.
Die Kerberos-Client-Konfiguration /etc/krb5.keytab auf unserem Linux-Server sieht wie folgt aus:
[libdefaults]
     default_realm = NETWAYS.DE
[realms]
     NETWAYS.DE = {
          kdc = dc.netways.de
          default_domain = netways.de
          ktpasswd_server = dc.netways.de
     }
[domain_realm]
     .netways.de = NETWAYS.DE
Unsere apache2.keytab können wir nun mit kinit auf Korrektheit prüfen.
kinit -t /etc/apache2/apache2.keytab HTTP/www.netways.de
Der PrincipalName kann im Vorfeld auch schon mit klist ermittelt werden.
klist -t -k /etc/apache2/apache2.keytab
Für den Apache Webserver werden noch drei zusätzliche Module benötigt. Die Module mod_ldap und mod_authnz_ldap, im Gegensatz zu mod_auth_kerb sind diese beiden Module Bestandteil vom Apache-Paket. Das Module mod_auth_kerb muss nötigenfalls selbst übersetzt werden.
a2enmod auth_kerb
a2enmod ldap
a2enmod authnz_ldap
Für unser Beispiel  benötigen wir noch einen Active Directory Benutzer ads, um auf den LDAP-Server des DC zugreifen zu können. Außerdem die Gruppe ApacheAcces, deren Mitglieder auf unsere Website zu greifen dürfen.
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm NETWAYS.DE
KrbServiceName HTTP
Krb5Keytab /etc/apache2/apache.keytab
KrbMethodK5Passwd on
KrbMethodNegotiate on
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://dc.netways.de/dc=netways,dc=de?userPrincipalName"
AuthLDAPBindDN "cn=ads,cn=Users,dc=netways,dc=de"
AuthLDAPBindPassword ********
Require ldap-group cn=ApacheAccess,cn=Users,dc=netways,dc=de
Zu Abschuss nicht vergessen den Browser für den SSO-Zugriff zu konfigurieren. Beim Firefox geschieht dies durch den Aufruf der URL about:config.
network.negotiate-auth.trusted-uris     .netways.de

Weitere Artikel zum Thema:
LDAP-Filter zur Autorisierung bei rekursiven Gruppen
Nochmal Apache und Active Directory

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.