Posts made by lewando

@franknagel
Genau darum geht es ja, der Eintrag /dev/mapper/fs02 existiert als Titel eines devices bereits, so dass hier die Zuordnung als String über den Titel erfolgen sollte. (In anderen Fällen klappt das auch, aber nicht in jedem Fall).

Anders ausgedrückt, ich möchte mit dem Request zwar das drive anlegen, die notwendigen Abhängigkeiten wie device etc. existieren aber schon und müssen nur richtig verknüpft werden.

Wenn ich den gleichen Request absetzte, mit der ID des Device funktioniert es ja auch. Das ist jedoch umständlicher als den Titel zu verwenden, den ich bereits weiß.

Vielleicht noch ein anderes Beispiel, was das Problem für eine andere Kategorie zeigt.

Hier der Eintrag aus dem Logbuch (also das Ergebnis des API Requests):

So schaut es im Objekt selbst aus:

@franknagel
Stimmt, ich hatte dazu mal eine ähnliche Frage gestellt (wobei, da fällt mir gerade ein, dass ich noch keine Info bekommen hatte, ob mein Bugreport auch geschlossen wurde), in diesem Fall ist es zwar ähnliches Beispiel, steht hier aber nur stellvertretend für mehrere Kategorien, wo dieses Problem existiert und vor allem auch bei Werten, die nicht als Int interpretiert werden.

@martinv
Das könnte natürlich sein, aber ich hab den Fehler schon an mehreren Stellen gefunden, ein anderes Beispiel wäre bei "drive" (bzw. Laufwerk) wo das on_device nicht gesetzt wird, obwohl die Übergabe korrekt ist und auch hier die Einträge existieren. Ein weiteres Beispiel wäre die Zuordnung bei virtual devices.

Ich würde mir jedoch gerne die Suche nach den passenden ID's ersparen, sofern es auch ohne geht.

Hallo zusammen,

ich versuche gerade zu verstehen, warum bei einem cmdb.category.save, Daten die zwar im API Aufruf zu finden sind, nicht in die CMDB übernommen werden.

curl -s --noproxy "*" --location --request POST 'https://FQDN/i-doit/src/jsonrpc.php' --header 'Content-Type: application/json' --header "X-RPC-Auth-Session: TOKEN" --header "Cookie: PHPSESSID= SESSIONID" --data-raw '{
        "version": "2.0",
        "method": "cmdb.category.save",
        "params": {
            "object": "13217",
            "entry": "",
            "data": {
                "application": "5136",
                "application_type": "",
                "assigned_license": "",
                "assigned_license_key": "",
                "assigned_it_service": "",
                "assigned_variant": "",
                "assigned_version": "7.9",
                "assigned_databases": "",
                "description": "Auto created by API"
            },
            "category": "C__CATG__OPERATING_SYSTEM",
            "apikey": "KEY",
            "language": "en"
        },
        "id": 1
      }'
# Ergebnis
"result":{"success":true,"message":"Category entry successfully saved","entry":582}}

Dieser Aufruf sollte eigentlich die OS Infos aktualisieren und hier neben dem OS selbst (application id) auch die Version 7.9 setzten. Der Doku nach kann für assigend_version sowohl ein String, passend zu einem Eintrag im Dialogfeld oder die ID des Eintrags im Dialogfeld angegeben werden.

Die Versionsnummer existiert eindeutig in der Liste der Versionsnummern, wie hier zu sehen ist wird diese jedoch nicht übernommen. Hat jemand eine Idee, woran das liegen könnte?

@franknagel :
Gute Idee, ich hab das direkt mal ausprobiert und es scheint ähnlich zu sein, wie von ihnen beschrieben.

Ändere ich den POST, wie in ihrem Beispiel zu sehen ist, bekommt I-Doit mit, das ein neuer Wert geschrieben werden soll

Dieser wird beim Objekt jedoch nicht übernommen.

Sieht für mich auf den ersten Blick wirklich nach einem Bug aus, oder?

Edit: einen Bug Report habe ich hierzu ebenfalls mal eröffnet.

Hallo zusammen,

ich suche derzeit eine Möglichkeit Subkategorien zu aktualisieren, wie etwa "C__CATG__VERSION". Hintergrund ist, dass ich gerne dynamisch das OS System aktualisieren möchte (samt Versionsnummer), diese aber nicht übernommen wird. Beziehungweise, die Versionsnummer wird nur dann übernommen, wenn diese zuvor im DialogPlus Feld hinterlegt wurde.

Auszug aus der API Beschreibung:

Beim Versuch einen Eintrag des Betriebssystems zu aktualisieren

- name: update os information in CMDB
  shell: |
    curl -s --noproxy "*" --location --request POST 'https://idoit/i-doit/src/jsonrpc.php' \
    --header 'Content-Type: application/json' \
    --header "X-RPC-Auth-Session: {{ idoit_session_key }}" \
    --header "Cookie: PHPSESSID= {{ idoit_session_key }}" \
    --data-raw '{
        "version": "2.0",
        "method": "cmdb.category.save",
        "params": {
            "object": "{{  idoit_object_id }}",
            "entry": "",
            "data": {
                "application": "{{ os_idoit_id }}",
                "application_type": "",
                "assigned_license": "",
                "assigned_license_key": "",
                "assigned_it_service": "",
                "assigned_variant": "{{ ansible_distribution_release }}",
                "assigned_version": "{{ ansible_distribution_version }}",
                "assigned_databases": "",
                "description": "Auto created by API"
            },
            "category": "C__CATG__OPERATING_SYSTEM",
            "apikey": "{{ idoit_api_key }}",
            "language": "en"
        },
        "id": 1
      }'
  args:
    warn: false
  delegate_to: 127.0.0.1
  when:
    - "os_idoit_id is defined"

Musste ich jedoch feststellen, dass der Wert zwar korrekt dem Request hinzugefügt wird (hier als String) jedoch nicht gespeichert wird.

changed: [idoit] => {"changed": true, "cmd": "curl -s --noproxy \"*\" --location --request POST 'https://idoit/i-doit/src/jsonrpc.php' --header 'Content-Type: application/json' --header \"X-RPC-Auth-Session: u501nrtoo270p04ceuakpmetgc\" --header \"Cookie: PHPSESSID= u501nrtoo270p04ceuakpmetgc\" --data-raw '{\n    \"version\": \"2.0\",\n    \"method\": \"cmdb.category.save\",\n    \"params\": {\n        \"object\": \"11571\",\n        \"entry\": \"\",\n        \"data\": {\n            \"application\": \"1702\",\n            \"application_type\": \"\",\n            \"assigned_license\": \"\",\n            \"assigned_license_key\": \"\",\n            \"assigned_it_service\": \"\",\n            \"assigned_variant\": \"Core\",\n            \"assigned_version\": \"7.8\",\n            \"assigned_databases\": \"\",\n            \"description\": \"Auto created by API\"\n        },\n        \"category\": \"C__CATG__OPERATING_SYSTEM\",\n        \"apikey\": \"XzpV1ejX9ungCUW6K2dT\",\n        \"language\": \"en\"\n    },\n    \"id\": 1\n  }'\n", "delta": "0:00:00.290924", "end": "2020-10-07 13:10:15.218418", "rc": 0, "start": "2020-10-07 13:10:14.927494", "stderr": "", "stderr_lines": [], "stdout": "{\"id\":1,\"jsonrpc\":\"2.0\",\"result\":{\"success\":true,\"message\":\"Category entry successfully saved\",\"entry\":444}}", "stdout_lines": ["{\"id\":1,\"jsonrpc\":\"2.0\",\"result\":{\"success\":true,\"message\":\"Category entry successfully saved\",\"entry\":444}}"]}

In der Beschreibung der Kategorie wird darauf verwiesen, dass sich assigned_version auf einen bereits existierenden Wert beziehen muss. Ich habe in der Doku jedoch noch keinen Hinweis darauf gefunden, wie ich diesen Wert über die API hinterlegen kann.

Vielleicht könnt ihr mir hier weiterhelfen?

Gruß
Lewando

@Philipp-Hörselmann
Ich habe das obige Beispiel mit der I-Doit Version 1.14-2 gemacht, aber du es gerade erwähntest... ja die API hatte ich noch nicht aktualisiert ^^ okay, also jetzt I-Doit 1.15 und API 1.11.2 check

Danke für die Hilfe

Hallo zusammen,

bei der Abfrage über die I-Doit API mit der Methode cmdb.category.read ist mir aufgefallen, dass es scheinbar keine Information darüber gibt, im welchem Status sich ein Eintrag befindet. Wenn ich mit folgendem Aufruf die eine Kategorie abfrage

{
    "version": "2.0",
    "method": "cmdb.category.read",
    "params": {
        "objID": 9241,
        "category": "C__CATG__DRIVE",
        "apikey": "API-KEY",
        "language": "en"
    },
    "id": 1
}

finde ich in der Antwort keinen Unterschied zwischen den beiden Einträgen, obgleich beide einen unterdiedlichen Status haben. Im nachfolgenden Beispiel mit 2 Objekten, liegt der Eintrag mit der ID 108 im Bereich Archiviert oder gelöscht (noch nicht bereinigt), der Eintrag mit der ID 109 im Bereich Normal.

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": [
        {
            "id": "108",
            "objID": "ObjektID",
            "mount_point": "/",
            "title": "sda",
            "system_drive": {
                "value": "1",
                "title": "Yes"
            },
            "filesystem": {
                "id": "10",
                "title": "EXT4",
                "const": null,
                "title_lang": "EXT4"
            },
            "capacity": {
                "title": 500
            },
            "unit": {
                "id": "3",
                "title": "GB",
                "const": "C__MEMORY_UNIT__GB",
                "title_lang": "GB"
            },
            "serial": "",
            "assigned_raid": null,
            "drive_type": "1",
            "device": null,
            "raid": null,
            "ldev": null,
            "category_const": "",
            "free_space": null,
            "free_space_unit": null,
            "used_space": null,
            "used_space_unit": null,
            "firmware": "",
            "description": "<p>Created WITH API</p>\r\n"
        },
        {
            "id": "109",
            "objID": "ObjectID",
            "mount_point": "/",
            "title": "sda",
            "system_drive": {
                "value": "1",
                "title": "Yes"
            },
            "filesystem": {
                "id": "10",
                "title": "EXT4",
                "const": null,
                "title_lang": "EXT4"
            },
            "capacity": {
                "title": 500
            },
            "unit": {
                "id": "3",
                "title": "GB",
                "const": "C__MEMORY_UNIT__GB",
                "title_lang": "GB"
            },
            "serial": "",
            "assigned_raid": null,
            "drive_type": "1",
            "device": null,
            "raid": null,
            "ldev": null,
            "category_const": "",
            "free_space": null,
            "free_space_unit": null,
            "used_space": null,
            "used_space_unit": null,
            "firmware": "",
            "description": "<p>Created WITH API</p>\r\n"
        }
    ]
}

Gibt es eine weitere Möglichkeit diese Einträge über die API zu unterscheiden?

@Philipp-Hörselmann
Ah super vielen Dank für die schnelle Hilfe

Ich hab mich schon gefragt, wofür die Entry (ID) da ist, aber die DOKU erzeugte bei mir eher Fragezeichen xD (Da ich zunächst mit der Beschreibung "Eintragsidentifikator" die Verbindung zur Nutzung im Request nicht gezogen habe)

Es ist zwar etwas unglücklich das man keine weiteren Identifikatoren nutzen kann, aber gut so muss ich zunächst das Objekt abfragen, bevor ich es aktualisieren kann, auch gut. (Weil im Anwendungsfall den ich gerade versuche umzusetzen, sind mir die Daten bereits bekannt, ich muss diese nur noch auf den passenden API Call mappen um diese zu aktualisieren.)

@emrehayta
Ich würde dir empfehlen dies nicht über die API sondern über einen dynamic Report zu machen. Die dynamischen Reports generieren dir unter anderem einem XML Report mit den Feldern, welche bei der Erstellung des Reports angegeben wurden. Basierend auf diesem XML Report musst du dann nur die Daten, die du wirklich benötigst in JSON Notation speichern und kannst diese anschließend direkt als Inventory in AWX nutzen.

Ein Vorteil bei der Nutzung von dynamischen Reports ist, dass du diese via http/s beziehen kannst, es ist also kein API Aufruf über I-Doit notwendig, sondern es reicht aus die ID des Reports zu kennen. Wie @RandomUser jedoch bereits richtig angedeutet hat, ist ein Zwischenschritt notwendig um die Reports für Ansible aufzubereiten. (Hier spielt es jedoch keine Rolle ob du das via python, php, shell etc. machst)

Die Einbindung der Reports in AWX kann dann über ein custom inventory Skript, direkt in AWX realisiert werden.

Beispiel wie das aussehen könnte:

{
    "_meta": {
        "hostvars": {
            "HOSTNAME": {
                "ansible_host": "IP",
                "idoit": {
                    "id": "ObjectID",
                    "ignore": false,
                    "network": {
                        "hostname": "HOSTNAME",
                        "ipaddr": "IP"
                    },
                    "title": "HOSTNAME"
                }
            },

            [...]

Hallo zusammen, ich habe eine Frage zur Aktualisierung der Kategorien über die API von I-Doit. Konkret versuche ich gerade Informationen über Festplatten / Dateisysteme via API von einem Objekt zu aktualisieren.

Aufurf:

{
    "version": "2.0",
    "method": "cmdb.category.save",
    "params": {
        "object": 9241,
        "data": {
            "title": "sda",
            "mount_point" : "/",
            "system_drive": "Yes",
            "filesystem": "EXT4",
            "capacity": 500,
            "unit": "GB",
            "serial": "",
            "assigned_raid": null,
            "drive_type": "1",
            "device": null,
            "raid": null,
            "ldev": null,
            "category_const": "",
            "free_space": null,
            "free_space_unit": null,
            "used_space": null,
            "used_space_unit": null,
            "firmware": null,
            "description": "Created WITH API"
        },
        "category": "C__CATG__DRIVE",
        "apikey": "API-KEY",
        "language": "en"
    },
    "id": 1
}

Der Rückgabewert des Requests ist, wie erwartet folgender:

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": {
        "success": true,
        "message": "Category entry successfully saved",
        "entry": 107
    }
}

Wenn ich diesen Request jetzt jedoch zweimal ausführe, so wird der vorherige Eintrag nicht aktualisiert, sondern es werden 2 Einträge erstellt.

Folglich stellt sich mir die Frage, wie kann ich über die cmb.category.save Methode Einträge eines Objektes aktualisieren?