IDO DB cleanup

This forum was archived to /woltlab and is now in read-only mode.
  • Hi everyone!


    MoD : please move my thread if needed... it wasn't clear for me if this was the right place for it.


    I am having some stale objects (hosts, services, etc.) in my IDO DB and I want to make sure that this perl script can be ran against 2.4.7:


    My problem's background is that I can see a host with

    Shell-Script
    1. icinga2 node list


    and with


    Shell-Script
    1. icinga2 object list --type host



    however, I can't see it in the web interface. While trying to debug the problem, I saw some old entries in the tables of the IDO DB, so I figured that cleaning that up would be a good idea.


    BTW, the host was created through the API.


    Thanks for the help.

  • FWIW, I made a backup of the IDO DB, dropped it and imported the schema again. Seems like this did not help.
    I'll keep investigating and see if the certificates side of things is OK.


    LE: certificates are OK. Turning on the debuglog feature on both master and client does not yield any suspicious line. In fact, it appears as if everything is working correctly...
    I suspect that the problem is on the Web Interface and/or IDO DB.
    Any help for debugging that would be greatly appreciated.

  • Stupid question:
    are you able to see it running:


    Code
    1. curl -k -s -u root:icinga -H 'Accept: application/json' -X GET 'https://localhost:5665/v1/objects/hosts?host=MissingHostName' | python -m json.tool

    service icinga2 reload has been done ?

  • Stupid question:
    are you able to see it running:


    Code
    1. curl -k -s -u root:icinga -H 'Accept: application/json' -X GET 'https://localhost:5665/v1/objects/hosts?host=MissingHostName' | python -m json.tool

    service icinga2 reload has been done ?

    Thanks for your reply. In the end, I was doing something wrong with my configuration management tool :cursing:
    Anyway, I decided to go with the built-in configuration synchronisation mechanism and let the cluster handle that for me. In my particular use case, it seems like it makes the most sense to talk only to the API of the master node instead of touching the APIs of the satellite/slave/client/whatever nodes.
    Oh, and I found a broken link on the docs here: Cluster config sync (3rd bullet point on 13.2 http://docs.icinga.org/icinga2…a2/chapter/icinga2-client)


    The IDO DB cleanup script question still stands, though.
    Dunno how much the DB schema has changed but I ran it against a 2.4.7 database and the only issue I saw was that it complained about a missing table: icinga_slahistory.


    Cheers,


    Dan.