Posts by sru

    I think the solution that Kevin.Honka provided should suit your needs.

    But yes, you can put a satellite below your master and delegate all application related checks to that.

    That way, your OPs-Team will manage the master with the hosts and common services and the restricted administrators may manage the applications.

    crunsher already told you that.

    1. find out how to send sms from the command line

    2. write / modify the scripts below /etc/icinga2/scripts to send sms instead of emails.

    3. create notification commands and notifications either using the director or by editing commands.conf and notifications.conf, that use the scripts created in step 2.

    Regarding step 1:

    you need a provider that sends the sms out.

    You create an account with them and pre-pay for a number of sms's.

    normally, you deliver the receipient and the text to send by calling a url using the curl utility - but that will be told you by the provider of youir choice.

    Hope that makes it more clear.

    I confirm that mail notifications are send in "All exteced cases".

    Ok, if you can see all the calls to the mattermost notification script, i guess the problem must be in the script or behind and not in icinga2.

    1. apply Notification "mattermost_service" to Service {
    2. assign where host.vars.notification.mail # better swap these lines
    3. import "mail-service-notification" # here.

    I would always import the template before doing all other things.

    The unrelyable notifications might be wihtin icinga not triggering them or within the mail script / mail server not handling them properly.

    For the first, can you analyze the icinga logfiles if the mail script finally gets called in *all* expected cases ?

    For the second, can you add a line to the mail script that logs a line whenever it was called ?

    The IP routing has nothing to do with the CN of the certificate.

    Icinga Cluster Protocol requires that the endpoint name in zones.conf matches the CN of the certificate.

    But for routing the traffic, the host= attribute needs to have a routeable value - either a FQDN or an IP.

    Above Error message "not a valid certificate" seems to indicate a problem with a missing certificate or a certificate that can not be validated (the ca.crt can not be used to validate the certificate provided).

    Auch wenn dein Ziel die Konfiguration mit dem Director ist (dies ist auch zu empfehlen),

    denke ich du solltest den ersten Client mit statischen Config- Files aufsetzen um erst einmal den Top-Down Mode und die Config-Sync zu verstehen.

    Den Master aufräumen:

    • In der icinga2.conf auskommentieren:include_recursive "repository.d"- damit hast du keine bottom-up config mehr.
    • Die Datenbank des Directors löschen / zappen.
    • /var/lib/icinga2/api/packages/director löschen.

    Ersten Client an den Master hängen:

    Auf dem Master ausführen:

    1. icinga2 pki ticket --cn sat4.local
    2. 4f75d2ecd253575fe9180938ebff7cbca262f96e

    Auf dem Client ausführen:…ientsatellite-linux-setup

    also auf dem Client icinga2 node wizard ausführen, Master-Setup: N, etc.

    Dann erstellst du in der Zones.conf auf dem Master für den ersten Client eine eigene Zone und einen Endpoint:

    Und machst dann entsprechendes in der Zones.conf auf dem Client:

    Und fügst auf dem Master unter zones.d/master/services.conf den cluster check hinzu, damit geprüft wird ob dein neuer Client auch verfügbar ist:…monitoring/#health-checks

    Dienste auf dem Master und dem Client neu starten und prüfen, dass der Cluster check funktioniert.

    Nun kannst du unter zones.d/sat4.local/services.conf den ersten Dienst hinzufügen, sagen wir: Load.

    Deine Erwartung ist, dass nach dem service icinga2 reload dieser service auch auf dem Client angekommen ist.

    Damit hast du dann eine Synchronisation der Config.

    Prüfe dies auf dem Client mit icinga2 object list --type service --name load.

    Baue nun die Config für den Client etwas aus, indem du weitere Dienste für den Client erstellst - Du tust dies wieder auf dem Master in der zones.d/sat4.local/services.conf .

    i can *not* reproduce that: