Kommunikation zwischen Director und Icinga Datenbank

This forum was archived to /woltlab and is now in read-only mode.
  • Hi, wir haben ein kleines Problem.
    Auf dem System läuft Debian 9 mit einer frischen Icinga 2, Icinga Web2 und Icinga Director installiert. Direkt gab es Probleme mit der Datenbank, waren wohl Probleme mit den Rechten. Funktioniert jetzt aber!
    Der Kickoff-Wizard vom Director hat den bereits vorhandenen localhost Server nicht importiert. Es scheint so, als hätte er gar nichts importiert (keine Gruppen etc vorhanden).
    Als Endpoint-Name haben wir den Hostnamen genutzt, stimmt das?

    Gruppen nachträglich anlegen funktioniert, löschen aber nicht. Es wird kein Error angezeigt, als sei alles in Ordnung. Der Deploy funktioniert also "perfekt".

    Welche Konfigurationen / Daten wären denn für euch nützlich?

    Grüße

  • Kannst du uns genauer erzählen, was ihr für Probleme beim anlegen hattet und wie eure Konfiguration aussieht. Das Problem kommt mir merkwürdig vor.

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Hallo und Danke für deine Antwort. Bin mir gerade nicht sicher wie ich das genau erklären soll. Bin neu im Thema Icinga2.
    Aber für mich schaut es so aus als würde der director versuchen die Konfiguration im File vorzunehmen. Aber ich habe meine Icinga2 Installation auf SQL umgestellt. Kann es sein das man dort beim Endpoint etwas konfigurieren muss wenn die Daten in einer Datenbank und nicht im File liegen?


    Es ist ja auch so das in der Installation schon einige Gruppe und der localhost von Haus aus vorhanden sind.
    Diese hat er mir NICHT importiert (im kickstart wizzard) (sollte er doch eigentlich tuen oder?)


    Im icinga web an sich sehe ich den Host, aber halt nicht im director.



    Irgend ein Tipp für mich was ich da mal testen soll?

  • ah jetzt kommen wir der Sache näher.

    Der Master wird niemals im Director angezeigt, da er seine Konfiguration standardmäßig unter /etc/icigna2/conf.d hat.

    Der Director nutzt eine Datenbank um seine Konfigurationen vorzuhalten, im Endeffekt bringt er diese beim deployment aber auch als Files nach /var/lib/icinga2/... aus.


    Rein aus pragmatischen Gründen, würde ich die Konfiguration des Masters auch getrennt vom Director lassen, damit diese auch weiterhin funktioniert, wenn der Director mal Probleme haben sollte.


    Wenn du den localhost trotzdem Importieren möchtest, dann würde ich dir raten einen Import über die CoreAPI im Director zu machen. Dann musst du aber alles in conf.d was an services, host, notifications usw definiert ist entweder auskommentieren oder entfernen.

    ACHTUNG: Solltest du das tun, lösche niemals die api-users.conf da sonst der Zugriff auf die API nicht mehr funktioniert.


    Was mich noch interessieren würde, was hattest du für Probleme mit den Rechten bei den Datenbanken, war hier einfach nur kein User eingerichtet, der darauf zugreifen durfte?

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Der Director schreibt KEINE Dateien. Der Director kommuniziert lediglich mit der Icinga 2 REST API und den Config Packages (siehe Doku zur API).

  • Der Director schreibt KEINE Dateien. Der Director kommuniziert lediglich mit der Icinga 2 REST API und den Config Packages (siehe Doku zur API).

    Hallo dnsmichi,


    wieso schreibt er dann seine Dateien nach /var/lib/icinga2/... Wofür sind die denn da? Die müssen ja auch einen Sinn haben. Sind die zur Versionsverwaltung?


    Danke und Gruß

    Linus

  • War ein Fehler meiner von meiner Seite, der Director nutzt die Icinga2 API um die Konfiguration zu deployen.

    Linux is dead, long live Linux


    Remember to NEVER EVER use git repositories in a productive environment if you CAN NOT control them

  • Das Verzeichnis wird von Icinga 2 und dem API-Feature verwaltet. Der Director oder jedwede andere Applikation die die API verwendet, hat da keinen Einfluss darauf. Hilfreich zum analysieren ja, manuell dran rumbauen absolutes nein.

  • ah jetzt kommen wir der Sache näher.

    Der Master wird niemals im Director angezeigt, da er seine Konfiguration standardmäßig unter /etc/icigna2/conf.d hat.

    Der Director nutzt eine Datenbank um seine Konfigurationen vorzuhalten, im Endeffekt bringt er diese beim deployment aber auch als Files nach /var/lib/icinga2/... aus.

    Ich nutze das conf.d Verzeichnis auch auf dem master nicht. Der Master host liegt in der zones.d/'master' bzw wird ganz normal im Direktor erstellt/verwaltet.