Seite wählen

NETWAYS Blog

Monthly Snap August – NETWAYS News | Tipps & Tricks | Upcoming… | Corporate Blogging


 
„Das @netways Blog kann man auch generell einfach mal empfehlen: https://www.netways.de/  – immer wieder spannende Sachen bei den Posts dabei“, twittert Felix Kronlage Anfang August. Das freut mich und meine Kolleginnen und Kollegen natürlich sehr! Denn, wie ihr als fleißige Blog-Leser/innen sicher wisst, das NETWAYS Blog ist, ganz im Geiste von Open Source, ein offenes Gemeinschaftsprojekt, geschrieben von uns, dem NETWAYS Team.
Wir haben unseren Redaktionsplan so organisiert, dass das Schreiben wie ein Staffelstab Tag für Tag durch unser Headquarter und von Team zu Team gereicht wird: Montags Shop & Sales, dienstags Events & Marketing, mittwochs Managed Services, donnerstags Development, freitags Consulting.  Für samstags planen wir eventuelle Specials und am Monatsende gibt es, so wie heute, einen Rückblick, den Monthly Snap. Der Snap bietet die Gelegenheit, noch einmal zu rekapitulieren. Während ich bei meinem täglichen Blick in das Blog meinen Fokus ja eher auf den einzelnen Beitrag des Tages richte, fällt mir jetzt am Monatsende mal wieder die Bandbreite an Themen und die Vielzahl der Stimmen auf, die unseren Blog und damit NETWAYS ausmachen!
Im besten Falle findet ihr, genau wie Felix, das ein oder andere für euch spannende Thema und klickt euch durch die Links. Viel Spaß dabei!
CEO Bernd hat diesen Monat seine Vergleichsserie wieder aufgenommen und veröffentlicht Icinga, Nagios, Naemon, OMD, Check_MK, Op5, Centreon oder Shinken – Teil III. Außerdem verweist er auf das Bitkom Forum Open Source 2018.

Webinare – Aus der Asche

In NETWAYS Webinare – Aus der Asche erfahrt ihr von Christian mehr über ein kleines Hitze- und Performance-Problem und die Termine aller Webinare in der zweiten Jahreshälfte, während Silke vom Shop & Sales-Team euch darüber informiert: Die neuen STARFACE Pro V6 und STARFACE Compact V3 Anlagen sind da!
Und natürlich gibt es auch wieder eine bunte Kiste voller Tipps und Tricks von unseren Entwicklern, Administratoren und Consultants, die vielleicht auch euch das Leben erleichtern: Jennifer – Feu – verrät „How css-tricks improved my work life“. Thomas weiß, es gibt JSON in bequem. Noah stolpert durch Zufall darüber und ist ab sofort happy mit  Postman – API development and testing made simple. Philipp setzt seine i-doit-Reihe fort mit i-doit API create, update, delete.

La La Lan & Molecule

Max zeigt euch in seiner La La Lan-IT Love Story wie man Linux Netzwerkschnittstellen mit check_nwc_health überwachen kann. Florians Thema: MySQL-Datenbanken verwalten mit Sequel Pro. Tim teilt sein Wissen über Adfree Internet with pi-hole.
Blerim stieß, als er an der Ansible Role für Icinga 2 arbeitete, auf ein hilfreiches Tool. Lest selbst: Testing Ansible Roles with Molecule. Ihr wollt mehr über Icinga 2 wissen, genauer, wie ihr mit Puppet eine dezentrale Icinga 2-Umgebung aufbaut und konfiguriert? Wir haben da einen neuen Workshop! Was euch erwartet, erfahrt ihr von mir in Ice, Ice – Icinga 2 / Puppet – Baby!

GitLab as a Service, Mutual SSL und OpenStack

Gitlab | self-hosted vs. Gitlab as a ServiceMarius wagt den Vergleich! Die vergangenen Monate hat er außerdem genutzt, um eine neue Cloud aufzubauen und weiß nun allerhand über Bursting und Throtteling in OpenStack zu berichten.
Jean beschäftigt sich in The Walrus Has Landed mit Structured Logging in Go und Georg dank einer Kunden-Anfrage mit der Realisierung einer clientbasierten Zertifikats-Authentifizierung (Mutual SSL) mit selbstsignierten Zertifikaten auf Linux + Apache. Sein Motto: Gesagt, getan.

DevOpsDays, OSBConf, OSMC und OSCAMP

Eventmäßig ist der August selbst ein eher ruhiger Monat. Klar: Viele sind in Urlaub, in zahlreiche Länder verstreut. Dafür stehen im Herbst die Zeichen umso mehr auf Get-Together. DevOpsDays | Sep 12. – 13. // OSBConf | Sep 26 // OSMC | Nov 5. – 8. // OSCamp | Nov 8. Mehr erfahrt ihr hier von Keya und mir: Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!, Why you shouldn’t miss OSBConf 2018 – #1 und #2, OSMC program online: Check out who’s in! Und OSCAMP #2 on Puppet: Get on stage!

 Und sonst so?

Wir haben Gunnar verabschiedet, ohne den wir Icinga heute so nicht hätten, und unseren ersten neuen Azubi willkommen geheißen, Henrik Triem im Development, und eine Woche Unterstützung von Nadine gehabt, die als Berufsschullehrerin mal Firmenluft schnuppern wollte.
Unser Schulungsraum Kesselhaus hat jetzt Jalousien und kann verdunkelt werden. Wir werden am 17. Dezember ein IcingaCamp in Tel-Aviv veranstalten und Icinga ist jetzt offizieller Partner im HashiCorp Technology Partner Program.
Viele Themen, viele Stimmen, viel Neues, viel Spannendes!
So much happend, more to come! Stay tuned!

i-doit API create, update, delete

Wie in meinem letzten Blogpost angekündigt, werde ich anhand eines Beispiels zeigen, wie man mittels der i-doit-API Daten erstellen, aktualisieren und löschen kann.
Ein großer Vorteil den man durch das Benutzen der i-doit-API hat, ist der, dass man nicht “wie üblich” mit SQL-Statements interne Verarbeitungsschritte innerhalb der Datenbank umgeht. Dadurch kann es nicht passieren, dass man durch z.B. einem UPDATE-Statement einen Datensatz so verändert, dass dieser fehlerhaft wird. Somit ist die Datenintegrität mit der API gewährleistet.
Zunächst sucht man sich das Objekt aus der CMDB heraus welches man verändern will (im folgenden Beispiel das Modell eines bestehenden Servers):

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.read", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL"}}' \
--header "Content-Type: application/json"  \
| python -m json.tool

Man erhält durch diese Anfrage folgende Antwort:

{
    "id": "1",
    "jsonrpc": "2.0",
    "result": []
}

Wie man sieht ist das result null. D.h. dieser Server/Objekt besitzt keinen Eintrag zu einem Modell bzw. Hersteller. Somit kann man nun ein neues Modell hinzufügen.
Zu beachten ist, dass im Voraus schon Modelle bzw. Hersteller in der CMDB angelegt wurden!

Die zu benutzende Methode ist cmdb.category.create:

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.create", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL",\
"data":{ "manufacturer": "random_manufacturer","title":"random_modelname","serial":"1234"}}}' \
--header "Content-Type: application/json"  \
| python -m json.tool

Sollte alles funktioniert haben, bekommt man folgenden Response zurück:

{
  "jsonrpc": "2.0",
  "result": {
    "id": "855",
    "message": "Category entry successfully created.",
    "success": true
  },
  "id": "1"
}

Hat man z.B. die Seriennummer falsch eingetragen und möchte diese verändern, kann man dies mit der Methode update durchführen.
cmdb.category.update

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.update", \
"params":{ "apikey":"random_key","objID":"random_objectid","category":"C__CATG__MODEL",\
"data":{ "serial":"4321"}}' --header "Content-Type: application/json"  \
| python -m json.tool

Im Anschluss kann man überprüfen ob alle eingetragenen Daten stimmen, indem man wieder den Server ausliest (oberes Beispiel cmdb.category.read):

{
  "jsonrpc": "2.0",
  "result": [{
    "id": "855",
    "objID": "random_objectid",
    "manufacturer": {
      "id": "13",
      "title": "random_manufacturer",
      "const": null,
      "title_lang": "random_manufacturer"
    },
    "title": {
      "id": "3",
      "title": "random_modelname",
      "const": null,
      "title_lang": "random_modelname"
    },
    "productid": "",
    "service_tag": "",
    "serial": "4321",
    "firmware": "",
    "description": ""
  }],
  "id": "1"
}

Zum Schluss löschen wir den Server komplett mittels der Methode quickpurge (quickpurge muss in i-doit aktiviert sein!)
cmdb.category.quickpurge:

curl -s --data '{ "jsonrpc":"2.0","id":"1","method":"cmdb.category.quickpurge", \
"params":{ "apikey":"random_key","id":"random_objectid","\
--header "Content-Type: application/json"  \
| python -m json.tool

 

{
  "jsonrpc": "2.0",
  "result": {
    "message": "Object(s) successfully purged",
    "success": true
  },
  "id": "1"
}

Quickpurge ist eine Methode bei denen die drei Löschschritte (archivieren, löschen, purge) automatisch hintereinander ausgeführt werden. Ansonsten müsste man der Methode cmdb.object.delete die verschiedenen Status in folgender Reihenfolge mitschicken:

{
  ...
  "status": "C__RECORD_STATUS__ARCHIVED"
  ...
}
{
  ...
  "status": "C__RECORD_STATUS__DELETED"
  ...
}
{
  ...
  "status": "C__RECORD_STATUS__PURGE"
  ...
}

Im nächsten Teil der Serien zeige ich wie man mit einem Ruby-Script all diese Schritte automatisiert durchführen kann.

i-doit API

Als IT-Dienstleister bieten wir nicht nur Web Services oder Schulungen, sondern unter anderem auch Hosting an. Im Hosting-Bereich ist eine umfassende und geordnete IT-Dokumentation zwingend erforderlich um ein reibungsloses Arbeiten zu ermöglichen.  Als Lösung wird eine sog. CMDB (Configuration Management Database) eingesetzt, welche nicht nur als eine Inventarisierungs-Datenbank dient, sondern auch die gegenseitigen Abhängigkeiten der Objekte verwaltet. I-doit ist eine solche CMDB.
Seit der i-doit Version 1.8 ist die API kein Bestandteil der Pro-Version mehr und wird als separates Modul ausgeliefert welches frei verfügbar ist. Infolge dessen hab ich ein Azubiprojekt bekommen bei dem man die Funktionsweise einer API kennenlernen kann. Ich zeige im ersten Teil der i-doit API Serie wie man einen Request  über den curl – Befehl versendet.

Hat man die API über die Web GUI von i-doit konfiguriert kann man über folgende URL, welche an die Basis-URL angehängt wird, zugreifen:

/src/jsonrpc.php

Die Programmierschnittstelle kann auf Daten der CMDB über das JSON-Format zugreifen, d.h. es werden JSON-RPC Requests per HTTP-Post an i-doit geschickt und als JSON-RPC Response (mit HTTP-Header application/json) zurückgegeben. Somit kann man entweder über den curl – Befehl oder über einen RESTClient (z.B. als Firefox-Addon) die API ansprechen.
Ein beispielhafter Aufbau eines Request könnte folgendermaßen aussehen :

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "cmdb.objects.read",
  "params": {
    "apikey": "random_key",
    "filter": {
      "type": "4"
    }
  }
}
  • jsonrpc – version: Da i-doit ausschließlich die Version 2.0 des RPC-Request untersützt
  • id: Ein optionaler skalarer Wert (True, False, String, Numer) welcher aber nicht Null sein darf. Lässt man diesen Parameter aus, so wird lediglich eine Mitteilung verschickt, sodass der Server keine Rückmeldung generiert
  • method: Die zu aufrufende Methode
  • params: Parameter welche an die Methode übergeben werden
curl -s --data '{"jsonrpc":"2.0","id":"1","method":"cmdb.objects.read","params": \
{"apikey":"random_key","filter":{"type":"4"}}}' \
--header "Content-Type: application/json" \
 | python -m json.tool

Mit diesem Request lesen wir alle Objekte in der CMDB aus welche dem Typ 4 (Rack) entsprechen:

{
  "id": "1",
  "jsonrpc": "2.0",
  "result": [{
    "cmdb_status": "6",
    "cmdb_status_title": "in operation",
    "created": "2018-01-05 11:32:13",
    "id": "33",
    "image": "https://example-idoit-web-gui.de/images/objecttypes/something.png",
    "status": "2",
    "sysid": "SYSID_[RANDOMNUMBER_3849274329]",
    "title": "RacknameXYZ",
    "type": "4",
    "type_group_title": "Infrastructure",
    "type_title": "Rack",
    "updated": "2018-01-11 13:38:09"
  },
  {
    ...
    ...
  }]
}

Um z.B. alle Informationen einer Kategorie eines Objektes auslesen zu können, benutzt man die Methode cmdb.category.read:

curl -s --data '{"jsonrpc":"2.0","id":"1","method":"cmdb.category.read","params": \
{"apikey":"random_key","objID":"1234","category":"C__CATG__MODEL"}' \
--header "Content-Type: application/json" \
 | python -m json.tool

Response:

{
  "id": "1",
  "jsonrpc": "2.0",
  "result": [{
    "description": "",
    "firmware": "",
    "id": "307",
    "manufacturer": {
      "const": null,
      "id": "5",
      "title": "Random_Manufacturer_Name",
      "title_lang": "Random_Manufacturer_Name"
    },
  "objID": "Uniqe-Object-ID",
  "productid": "",
  "serial": "1235265477457",
  "service_tag": "",
  "title": {
    "const": null,
    "id": "71",
    "title": "XYZ1234",
    "title_lang": "XYZ1234"
  }
  }]
}

Eine ausführliche Liste aller in i-doit benutzten Kategorien kann man unter folgendem URL-Anhang aufrufen:


Darüber hinaus kann man über die i-doit API nicht nur Daten aus einer CMDB herauslesen, sondern auch erstellen, aktualisieren oder löschen. Diese Methoden werde ich im Teil 2 dieser Serie abhandeln.
 
Quellen: i-doit Knowledge Base


Live vom Nagios Workshop Kassel: i-doit & Nagios

Nach der Mittagspause startet nun ein weiterer interessanter Vortrag: Dennis Blümen von der Firma synetics GmbH spricht über die Open Source CMDB i-doit in Verbindung mit Nagios. Einen Kollegen von ihm hatten wir mit einem ähnlichem Thema bereits auf der OSDC als Referent zu Gast.
Zuerst stellt er i-doit vor und gibt einen Überblick über die Features: Dokumentation idoitder IT Struktur in beliebiger Detailtiefe, Versionierung, Abbildung logischer und physikalischer Abhängigkeiten, Abbildung von Dokumenten und Handbüchern, sowie die Anbindung mit anderen ITIL Tools und Prozessen. Nach der kurzen Einführung kommt gleich eine Live Demo: Out-of-the-box bietet i-doit bereits eine große Anzahl an Dokumentationsobjekte, wie Gebäude, Räume, Schränke, Server, aber auch Software, Dienste und viele weitere. Die Software kann aber auch einfach um neue Objekte erweitert werden. Durch Verknüpfungen können die Objekte untereinander in Beziehung gesetzt werden, beispielsweise indem ein bestimmter Dienst mit einem Server auf dem er läuft, verbunden werden kann.
Über ein ebenfalls frei verfügbares Nagios Modul für i-doit, können die Statusdaten aus einer NDO Datenbank in die CMDB Anwendung integriert werden. Der aktuelle Status eines überwachten Servers oder Dienstes, wird direkt in der i-doit Anwendung angezeigt und alle Statusänderungen werden ebenfalls in das i-doit Logbuch integriert. Neben diesen lesenden Zugriffen auf die Nagios Datenbank unterstützt i-doit aber auch schreibenden Zugriff, sprich Generierung von Nagios Konfigurationen. Dazu können in allen relevanten Objekten, wie Server, Dienste, User und sogar Abhängigkeiten, zusätzliche Daten für Nagios hinterlegen und daraus Nagios Konfigurationsdateien erstellen. Aktuelle Schwachstelle ist aber leider noch, dass das Tool momentan nur mit einem einzelnen Nagios Server umgehen kann und nicht wie beispielsweise NConf mehrere Nagios Server unterstützt. Geplant ist das Feature aber für die nächste Zeit.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.