Posts by bodsch

    We make the parsing a little bit faster

    Shell-Script
    1. curl -s --connect-timeout 10 -X GET --header \"Accept: application/json\" \
    2. "http://openhab.bafi.lan:8080/rest/persistence" | \
    3. jq --compact-output '.[] | select(.id)' | jq --raw-output .label | sed --expression 's/^/<li>/g' --expression 's/$/<\/li>/g'

    The Result are the same:


    (i like long parameters. thats easier to read later (for me))

    But, i can't see an error or problem.


    The HTML interpreter could interpret '\n' as '<br>' , you can test the usage of tr to remove the '\n' :

    Shell-Script
    1. echo $a | \
    2. jq --compact-output '.[] | select(.id)' | \
    3. jq --raw-output .label | \
    4. sed \
    5. --expression 's/^/<li>/g' \
    6. --expression 's/$/<\/li>/g' | \
    7. tr -d '\n'
    8. <li>influxdb</li><li>rrd4j</li>




    (i hope you can follow the voices of my head ;) )


    Greetings from Hamburg,

    Bodo

    Moin Moin!


    Ich habe mal eine Frage zu einem Master / Satellite Setup ...


    Ich nutze einen Icinga2-Master und an dem hängen dynamisch viele Satelliten in anderen Netzen.

    Wo kippe ich am besten die Host und Service Checks ab, so dass diese auch auf dem Master sichtbar sind?


    Wenn ich das am Satelliten mache, müssten der ja nicht nur die Ergebnisse, sondern auch die Checks zum Master transferieren.


    Liege ich da mit meiner Vermutung richtig?


    (Ich würde das aktuell auch gern selber nachstellen / austesten, aber ich muß noch das Grafana Zeug fertig bekommen ...)


    Gruß aus Hamburg

    Ich komme zwar erst Montag wieder ans Testsystem, aber Docker sei Dank, kann ich schon jetzt was rausrücken ;)


    AFAIK sind die Objekte verfügbar und in der IDO DB geschrieben worden (was man ja daran sehen kann, dass ein simples restart von icinga hilft)



    Die Icinga Versionsnummer ist m.M.n. falsch, aber Alpine bietet mir nur das:



    Ggf. reiche ich mal einen Bugreport ein.

    Bis auf die Historie sehe ich keinen wirklich sinnvollen Grund das zu tun.


    Da du ja bei icinga2 gezwungen sein wirst, deine Altlasten komplett zu überarbeiten, werden sich dadurch auch die daraus resultierenden checks ändern.
    Ergo auch die daraus resultierenden Logs.

    Was gibt denn ein curl -v https://icinga2/icingaweb2/authentication/login auf der Komandozeile aus?


    Ein 301 / 302 bedeutet - wie es auch da steht - das es einen Redirect auf eine andere URL geben wird.


    Bei mir sieht das dann nämlich so aus:


    Location: /icinga/authentication/login?_checkCookie=18 ist dann die eigentliche URL, auf die der Redirect erfolgt.



    Wenn ich die aber aufrufe, bekomme ich einen 403, da kein Cookie hinterlegt ist. (Logisch)


    Ich würde daher mal sagen, wenn du das Icingaweb2 Logininterface prüfen willst, akzeptiere den 301 als OKAY und alles ist gut.

    Moin Moin!


    Ich stelle aktuell immer mal wieder ein kleines (aber nerviges) Problem bei der API fest.
    Ich füge Host und Services per API hinzu, was auch wunderbar funktioniert.


    Die entsprechenden Files landen alle unterhalb von /var/lib/icinga2/api/_api/$ICINGA-HOST/conf.d/



    Trotzdem werden weder Host noch Services im Icingaweb2 angezeigt ;(


    Starte ich icinga2 durch, ist alles da ?(


    Ich weiß auch nicht, wo ich das gerade Einsortieren kann ... Icinga2 oder Icingaweb2 ...

    Moin Moin!


    Nach dem ich jetzt Hosts und Services per API verwalten kann ... gibt es eigentlich auch eine Möglichkeit, das Service apply über die API hinzubekommen?


    Ich tue mich gerade schwer damit :(


    Gruß aus Hamburg,
    B.

    'umgehäkelt' ... aber wie? ;)


    Das NRPE schon lange nicht mehr State-of-the-Art ist, ist ja bekannt.
    Interessanterweise müsste man jetzt mal den icinga2-client dagegen testen, ob der das besser kann ...


    Für komplexere Anforderungen (wie z.B. deine) baue ich eigentlich eher eigene Scripte, die unter der Haube machen was sie sollen und nur noch Fehler zurückliefern.
    Dann hab ich im Icinga eine klarere Anzeige.

    Wenn ich dein Testaufruf via Puppet ausrolle, dann werden die ersten Werte zu disk_wfree/ disk_cfree überschrieben.
    Damit scheidet Puppet im ersten Schritt aus.


    Bleibt 'per Hand' ...
    Mit dem Standard Check aus der ITL scheint das auch nicht so zu funktionieren.


    Bleibt also nur, einen eigenen - für dich speziellen Check - zusammen zu bauen.


    Code
    1. object CheckCommand "extended-disk" {
    2. import "plugin-check-command"
    3. .
    4. .
    5. .
    6. }


    Vielleicht bringt dich das weiter?

    Eine andere Idee ...


    Basierend auf der Annahme, dass Icinga2 mit ihrer CA eine Art Standard-CA auf openssl Basis verwendet, könnte ich doch bereits im Vorfeld eigene Zertifikate erstellen und dann nur noch ausrollen!?
    Dann würde ich das ganze Thema mit den Tickets eigentlich umgehen und das ganze weitreichend automatisieren ...


    Würde das gehen?