Posts by sru

    Host XX ist in diesem fall der s00-aud-admsrv oder kurz admsrv.

    Dann nehmen wir uns nun gezielt diesen vor.


    Die zones.conf auf dem Master hab ich immer noch nicht, bitte prüfe dass diese mindestens enthält:


    Die zones.conf des problemhosts soll so aussehen:


    frage ich mich immer häufiger ob ich einfach zublöd dafür bin

    Keineswegs. Icinga hat eine steile Lernkurve - aber eine super Doku mit funktionierenden Beispielen zu so ziemlich allem.

    Man muss da drann bleiben. Belohnt wird das mit einem sehr universell konfigurierbarem System.


    bekomme ich einen Korrekten Host alive check zurück, schiebe ich sie aber wieder in die Satelliten zone wo sie hin gehört, ändert sich der status wieder nicht

    Das ist nun das nächste:

    Auch wenn das ein Endpoint ist, beklagst du Probleme mit einem Host-Object names s00-aud-admsrv.global.fum.

    Wir müssen nun prüfen, dass dieses auf beiden Maschinen

    • existiert
    • gleich konfiguriert ist


    In Post 3, Screenshot 1:

    https://i.imgur.com/pkprZ28.png

    sehen wir diese Konfig auf dem Master für den s00-aud-admsrv.global.fum in der zone satellite.

    Diese Zone gibt es aber nicht, sondern das Unterverzeichnis satellite muss wie die Zone in der zones.conf des Masters heissen:

    s00-aud-admsrv.global.fum


    Dann wird der Master dieses Objekt dem Satellite senden und dieser wird es akzeptieren weil er eben diese Zone s00-aud-admsrv.global.fum

    in seiner zones.conf findet.


    wenn du nun auf dem satellite ausführst:

    icinga2 object list --type host --name "s00-aud-admsrv.global.fum" 

    dann muss die Ausgabe dort mit der Ausgabe im obigen Screenshot

    übereinstimmen (die Pfade werden leicht abweichen).


    Achtung: Gross/Kleinschreibung ist für den Hostnamen / Endpunktnamen / Zonennamen wichtig, bitte prüfe das erneut auf beiden

    Maschinen.


    Wir haben damit getestet, dass ein Objekt erfolgreich vom Master zum "s00-aud-admsrv.global.fum" repliziert werden kann.

    Wir haben noch nicht sichergestellt, dass dieses auch funktionsfähig ist.

    Ich picke mal die Stellen mit meinen Quotes heraus:

    Ich bin mir nicht ganz sicher ob ich dich da falsch verstehe aber ich meinte damit das ich mir die Pfade rausgesucht habe in denen (wie ich die Doku verstanden habe) config files entsprechender Art drin sein sollten, hab diese von hand angelegt

    Ja. Dann sind wir uns einig:

    Host XX hat statische .conf files unter /etc/icinga2/*, alle anderen sind via Director konfiguriert.

    Ehrlich gesagt hab ich gerade nicht die Zeit, mir 20 Posts noch einmal reinzuziehen.

    Also, Welchen Hostnamen hat nun host XX ?


    Ich hab dir die beiden files die du sehen wolltest ausgeschnitten, einmal vom admsrv:

    Nö. wollte ich nicht.

    Ich wollte:

    1. Die zones.conf vom Problemhost - wie immer der nun inzwischen heist.
    2. Aus der constants.conf vom Problemhost: Die Werte ZoneName und NodeName
    3. Die zones.conf vom Master (und nicht von irgend einer mal wieder neuen Maschine, wir reden sonst jedesmal über was anderes)
    4. Aus der constants.conf vom Master: Die Werte ZoneName und NodeName

    Das ganze bitte nicht als Screenshot sondern als Text, mittels obigem Button "</>" formatiert.

    Ich guck mir das nicht nur mit dem Auge an sondern paste das im Extremfall in ne extra für dich aufgesetzte virtuelle Umgebung, da macht es mir Arbeit und ist fehlerträchtig screenshots abzutippen.


    Und was ist wenn beide auf den Anruf warten...?


    Das dies nicht passiert steuerst du mit dem host attribut im Endpoint Object. Entweder auf dem Master oder auf dem Satellite.

    Ich war 3 Wochen abwesend, deshalb die verspätete Antwort

    Sieh mal, der erste Post ist aus dem März, Donnerstag haben wir Juni.

    In dieser Zeit vergesse ich die Zusammenhänge.

    Und bei 20 komplexen Posts mit Spoilern die ich alle einzeln aufklappen muss, will ich mir das einfach nicht neu erarbeiten.

    Hinzu kommt dass ich hier auf "moving Targets" schiesse: jedes Mal hat sich irgend etwas an den Maschinen / der Konfig verändert.

    Und ich hab nun 3-mal angeregt, die zones.conf vom Master und vom Problemhost zu vergleichen und hab die Files immer noch nicht.


    Ich hoffe ich habe dich jetzt nicht vergnatzt - aber obiges scheinen mir die Dinge zu sein an denen es bezogen auf eine schnelle Hilfe mangelt.

    Of course it is.


    You need some criteria in the service declaration that you can query in the apply rule of the notification.

    For example, you can make the services a member of a service group or set a variable in the service to a given value.


    Your notification would look like the example in the docu:

    https://docs.icinga.com/icinga…using-apply-notifications


    here the criteria for creating notifications for some services would be for example:

    Code
    1. assign where service.vars.myspecialservice.mail

    Each server monitors (ping, http) dozens of devices in its local subnetwork. This is what we have to live with - we have no control of server locations or network topology.


    I thought we could have a satellite per network and then 10 clients beneath each, more or less, but we cannot afford it becoming a single point of failure in the icinga zone hierarchy.


    My suggestion:

    • 2 endpoints in the master zone, building a HA scenario.

    • X satellite zones with 2 endpoints each, again forming a HA scenario, having the master zone as parent.

    • Y client zones with 2 endpoints as above.


    Each Client zone has one satellite zone as the parent, but one and the same satellite zone is a parent of many client zones (group by location or network...).


    Satellites as well as clients can do check work against hosts which do *not* speak the icinga cluster protocol (ping, http, mysqld, DNS, etc).


    This scales fine, or do i misunderstand you ?

    for type 'Notification' does not match anywhere

    Heist:

    Es gibt kein einziges host object, auf welches zutrifft:

    Code
    1. assign where (host.vars.notification.mail) && ("testrechner" in host.groups)

    Lass mal && ("testrechner" in host.groups) weg und guck, ob das dann greift.


    Ich glaube, dass dieses mail-icingaadmin-quiet ja irgdnwie mit in den host muss

    Nö. Muss das nicht.


    Dein apply Notification "mail-icingaadmin-quiet" to Host {

    Kreiert dir Notification Objects, und zwar jedes für sich gebunden an einen bestimmten Host.

    Und für welche Hosts das passiert, sagt die obige assign where Deklaration.


    Ist nun klar wie Hosts, Notifications und Downtimes zusammen spielen ?

    As long as these IPs are assigned to host objects, i can tell from own experience that this will work (doing that with multiple host objects having the IP "127.0.0.1" myself).


    If these IPs are assigned to endpoint objects, i did not proved it myself but see no problems as long as routing is working correct.

    Endpoints must have unique names, however.

    There are two things here:


    1. Notifications

    There is an implicit dependency from a service to its host that prevents that notifications are sent out for services if their host is down.


    2. Service checks

    The default with above dependency is that they continue to run.

    You can create an explicit dependency that disables these checks.


    There are two things to take into account:


    It might be helpfull to have the host check interval 2-3 times shorter than the service check intervals to reduce situations where the host fails

    but is not checked yet. If the (now failing) services are checked before the host, you still get service down notifications because above dependency does not trigger until the host is checked to be down.


    Disabling service checks does result in "freezing" the last known service state in the Web Frontend. It will *not* turn these into "unknown".

    If that would be your goal, an event commad configured to the host could run a script that changes all service states of that host to unknown via an api call.

    However, this approach turns out to be problematic when remote satellites are writing a backlog because they have lost the connection to their parent / master:

    Once the master is reachable again, this backlog can not be replayed anymore if you forcibly insert status changes via the API.


    So make your decision...

    Usually, you have:

    • The notification feature enabled only at the master
    • The zones.d directory populated only at the same master
    • The hosts and services objects in that zones.d/zonename directories carry a line like vars.notification["mail"]   = { groups = [ "icingaadmins" ] }


    I personally let the masters conf.d/notifications.conf in place which evaluates this vars.notification["mail"] for every host known to the master

    (remember that the master knows objects in all zones).

    That way, the master is able to send notifications and the clients to not get replicated notifications and notification commands because they do not need them.


    On the other side, if you like to have a client to send notifications in addition to these of the master, just move the files to the masters global-templates zone and enable the feature notification at the respective client.

    Check the config of module monitoring, Command Transports.


    There are two possible:

    Type local (uses a pipe through a socket)


    Type API (uses a user and password)

    For this one, check that credentials defined in /etc/icinga2/conf.d/apiusers.conf

    match these in /etc/icingaweb2/modules/monitoring/commandtransports.ini.


    From the command line, check that you are able to query the api using the credentials in apiusers.conf:


    Code
    1. curl -k -s -u root:icinga 'https://localhost:5665/v1/objects/hosts'

    ein lokales Git-Repository und das einchecken

    So mach ich das auch. Macht möglicherweise die "30 Stände" obsolet und bringt ne History der Dateien, die sich auch wirklich geändert haben. Und zwingt via "commit msg"dazu, ein "warum" der Änderung anzugeben.

    Das da aber einfach so Dateien verschwinden ist derart unglaublich, dass da dann auch einem Git-Repository nicht zu trauen ist.


    Ein stabiles Backup

    • sichert auf mehrere Arten und mit mehreren Tools (z. B. Image- *und* File-Level oder Offline *und* Online)
    • sichert (diese verschiedenen Arten) in unterschiedlichen Intervallen (halb-jährlich Full, monatlich/wöchentlich Full, täglich INC/DIFF)
    • sichert auf unterschiedliche Medien
    • hält diese Medien an unterschiedlichen Standorten
    • wird regelmässig zu Wiederherstellungsübungen verwendet um Umfang und Funktion zu prüfen

    mach es manuell am Server für alle Clients und überschreibe jeweils am Client die Zertifikate (crt und key sowie ca.crt), die Konfiguration und node wizard brauchst du nicht angreifen

    ... Solange die "CN:" der Zertifikate exakt dem Endpunkt-Objekt in der Zones.conf entsprechen.