Seite wählen

NETWAYS Blog

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


OSQuery Systeminfos in Sql

logo-big
Echo „Hallo Welt!“;
Ich habe ein bisschen in Github gestöbert und habe Folgendes ausgegraben.
OSQuery ist ein schickes Projekt der Firma „Facebook“, welches zum Zweck ihrer eigenen Systemüberwachnung entstanden ist.
Es bildet Systeminformationen in einer schnellen SQLite- bzw. Postgresdatenbank ab.
Nach der Installation als Package osquery-1.5.1.pkg kann man direkt loslegen.
In der Bash kann man mit dem Aufruf von „osqueryi“ die interaktive Query Shell starten.
Hier eröffnet einem die interne Hilfe mehr Information zu dem was hier möglich ist.

osquery> .help
Welcome to the osquery shell. Please explore your OS!
You are connected to a transient 'in-memory' virtual database.
.all [TABLE]       Select all from a table
.bail ON|OFF       Stop after hitting an error; default OFF
.echo ON|OFF       Turn command echo on or off
.exit              Exit this program
.header(s) ON|OFF  Turn display of headers on or off
.help              Show this message
.mode MODE         Set output mode where MODE is one of:
                     csv      Comma-separated values
                     column   Left-aligned columns.  (See .width)
                     line     One value per line
                     list     Values delimited by .separator string
                     pretty   Pretty printed SQL results
.nullvalue STR     Use STRING in place of NULL values
.print STR...      Print literal STRING
.quit              Exit this program
.schema [TABLE]    Show the CREATE statements
.separator STR     Change separator used by output mode and .import
.show              Show the current values for various settings
.tables [TABLE]    List names of tables
.trace FILE|off    Output each SQL statement as it is run
.width [NUM1]+     Set column widths for "column" mode
.timer ON|OFF      Turn the CPU timer measurement on or off
osquery>

Wir sind mal neugierig und schiessen auf der osquery Shell das folgende Kommando ab:

osquery> .tables
..
  => os_version
  => osquery_extensions
  => osquery_flags
  => osquery_info
  => osquery_packs
  => osquery_registry
  => osquery_schedule
  => package_bom
  => package_receipts
  => passwd_changes
  => pci_devices
  => preferences
  => process_envs
  => process_events
  => process_memory_map
  => process_open_files
  => process_open_sockets
  => processes
  => routes
  => safari_extensions
  => sandboxes
  => shell_history
  => smbios_tables
  => startup_items
  => suid_bin
  => system_controls
  => time
..

Was wir hier erhalten, sind die Systemfakten welche automatisch im Hintergrund in festgelegten Intervallen abgefragt werden.
Beispiel 1)
Fragen wir zum Test die ‚os_version‘ ab.
Dies tun wir folgendermaßen:

osquery> select * from os_version;
+----------+-------+-------+-------+-------+
| name     | major | minor | patch | build |
+----------+-------+-------+-------+-------+
| Mac OS X | 10    | 10    | 4     | 14E46 |
+----------+-------+-------+-------+-------+

Dies ist ein Beispiel für ein einfaches Abfragestatement. (Wenn wir wissen wollen welche OS-Version unsere Rechnerflotte hat.)
Beispiel 2)
Ein Komplexeres Beispiel in SQL:

osquery> select distinct process.name, listening.port, listening.address, process.pid FROM processes AS process JOIN listening_ports AS listening ON process.pid = listening.pid;
+----------------+-------+---------+-----+
| name           | port  | address | pid |
+----------------+-------+---------+-----+
| UserEventAgent | 0     | 0.0.0.0 | 251 |
| UserEventAgent | 0     |         | 251 |
| Adium          | 55648 | 0.0.0.0 | 261 |
| SystemUIServer | 59036 | 0.0.0.0 | 265 |
+----------------+-------+---------+-----+

Dies wird alles mit durch OSQuery in festgelegten Intervalle in das Logfile überführt.
Es liegt in unserem Beispielsystem unter

/var/log/osquery.log

und kann mit einer geeigneten Software wie Icinga & Logstash weiter ausgewertet werden.
Nun noch der knifflige Teil des Setups: Ich habe kurz angerissen, wie die SQL Syntax von OSQuery funktioniert und angedeutet, wie flexibel das Ganze ist.
Die unbeantwortete Frage ist allerdings, wie ich meine eigenen Checks in einem Interval definiere.
Dies erfolgt bei OSQuery über eine simple ‚.conf‘-Datei. In diesem Beispiel liegt diese unter /var/osquery/osquery.conf.
In der osquery.conf wird beispielsweise ein Check mit der folgenden Syntax erstellt:

.. excerpt
 "schedule": {
        "info": {
        "query": "select * from startup_items"
        "interval": 3600
        }
 }
../excerpt

Fazit:
Aufgrund der simplen Abfragestatements und den kleinen Footprint durch eine SQLite Datenbank kann man im Hintergrund auf Linux & OS X Clients/Servern einen Faktencheck durchführen und durch andere Tools „in der Ferne“ auswerten lassen.
Kurzum, man bekommt ein mächtiges Werkzeug für Devops und Systemadministratoren, welches an die meisten Umgebungen angepasst werden kann.
Bis zum nächsten Post!

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu glücklichen Menschen zu machen.

Wiederholung des Request Tracker Webinars

Gute Neuigkeiten für alle die das heutige Webinar verpasst haben: Aufgrund von technischen Problemen musste das WebinarRequest Tracker: Open Source Ticket System“ leider abgebrochen werden.
Wir möchten uns aber noch einmal für die Geduld aller Teilnehmer bedanken – hoffentlich konnten wir fragentechnisch zumindest einen ersten guten Eindruck liefern.
Da wir natürlich die Lösung und die Vorzüge aufzeigen wollen, haben wir uns jetzt entschlossen, das Webinar bereits morgen, am 30. April 2014 um 10:30 Uhr zu wiederholen! Um auch neuen Teilnehmern einen Einstieg zu liefern, werden wir auch die bereits genannten Themen noch einmal ansprechen.
Wer sich registrieren möchte, sollte das gleich tun bevor alle Plätze ausgebucht sind.
Bis morgen!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

OSMC 2013: Der Countdown läuft – nur noch 23 Tage

Nicht mal mehr ein Monat, und wir sehen uns schon auf der OSMC 2013.
Zum Eingrooven in die richtige Konferenzstimmung, gibt es heute Ralf Dörings Talk „Monitoring bei der DB Systel„.

OSMC? Was soll das denn sein und wer sind die netten Menschen in diesen Videos?Die Open Source Monitoring Conference (kurz: OSMC) ist die internationale Plattform für alle an Open Source Monitoring Lösungen Interessierten, speziell Nagios und Icinga. Jedes Jahr gibt es hier die Möglichkeit sein Wissen über freie Monitoringsysteme zu erweitern und sich mit anderen Anwendern auszutauschen. Die Konferenz richtet sich besonders an IT-Verantwortliche aus den Bereichen System- und Netzwerkadministration, Entwicklung und IT-Management. Und die netten Menschen, die Ihr in unseren Videos zur OSMC seht, gehören dazu. 2013 wird die OSMC zum 8. Mal in Nürnberg stattfinden.