Posts by sru

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

    I'm not sure how it got messed up. All the purging/file deletion happened before I installed the icinga2 packages again on the master, so the box should have looked clean to the installer.

    Same here.

    Can not tell what leads to the creation of the selfsigned cert at master.

    Anyhow, great that it worked out.

    'vmMONp01': Invalid endpoint origin (client not allowed).

    could be that the following is missing in features-available/api.conf: accept_commands = true

    selfsigned certificate looks like the certificates are not correct. Here is an example from my half-working machines:

    The masters cluster check considers the client to be successful connected, but checks at the client are not executed.

    In icinga.log we see that "selfsigned cert" line.

    The reason is that the masters certificate is not issued by the ca (as is at the client) but selfsigned.


    1. root@debian:/var/lib/icinga2/certs# openssl x509 -in ca.crt -noout -text | grep -i 'issuer\|subject'
    2. Issuer: CN=Icinga CA
    3. Subject: CN=Icinga CA
    4. Subject Public Key Info:
    5. root@debian:/var/lib/icinga2/certs# openssl x509 -in debian.local.crt -noout -text | grep -i 'issuer\|subject'
    6. Issuer: CN=Icinga CA
    7. Subject: CN=debian.local


    1. root@debian88:/var/lib/icinga2/certs# openssl x509 -in ca.crt -noout -text | grep -i 'issuer\|subject'
    2. Issuer: CN=Icinga CA
    3. Subject: CN=Icinga CA
    4. Subject Public Key Info:
    5. root@debian88:/var/lib/icinga2/certs# openssl x509 -in debian88.local.crt -noout -text | grep -i 'issuer\|subject'
    6. Issuer: CN=debian88.local <- wrong ! must be: Icinga CA
    7. Subject: CN=debian88.local

    Now, that we know what the problem is, we fix that at the master:

    1. cd var/lib/icinga2/certs
    2. rm debian88*
    3. icinga2 pki new-cert --cn debian88.local --key debian88.local.key --csr de.csr
    4. icinga2 pki sign-csr --csr de.csr --cert debian88.local.crt
    5. rm de.csr
    6. service icinga2 restart
    7. openssl x509 -in debian88.local.crt -noout -text | grep -i 'issuer\|subject'
    8.     Issuer: CN=Icinga CA
    9. Subject: CN=debian88.local

    After a few minutes the remote checks are running.

    Zones.conf (same on Sat and Client )

    If these are the same on both and there are no host= attributes, no endpoint will create a connection to a partner.

    • At the client, put a line host="IP_OF_Satellite" in the endpoint definition of the satellite.
    • At the satellite, you must set the master to be the parent of the satellite.

    That is why the zones.conf file can not be the same at both machines.

    So, you are telling us that:

    • You modify i. e. zones.conf or constants.conf
    • You validate the config and restart icinga2
    • You re-check above files and they are at the state were you left them after editing
    • you wait 20 minutes
    • you recheck the files and find them to be at the state before editing them

    Is this correct ?

    any unintentional rollback of a former snapshot of the VM ?

    You place all configuration objects at the master below /etc/icinga2/zones.d/[ZONENAME] .

    The icinga cluster protocol will then distribute it to the target machines of the given Zone for you.

    First of all, interval is a property of the notification object, not the host object.

    You could create a template that sets the interval to 0:

    And import that into your notification objects.

    In the host configuration, set a variable to indicate that you do not like renotifications for it, i.e.:

    And use that variable to create the notification:

    1. apply Notification "mail-icingaadmin-wo-renotification" to Host {
    2. import "mail-host-notification-wo-renotification"
    3. user_groups = host.vars.notification.mail.groups
    4. users = host.vars.notification.mail.users
    5. assign where (host.vars.wo_renotification)
    6. }

    Hope that helps.

    Thanks, here is my output. Perhaps a pakaging thing ?

    1. root@workstation08:/var/log/apt# dpkg -l | grep icinga | cut -b 1-60
    2. ii icinga2 2.8.0-1.xenial
    3. ii icinga2-bin 2.8.0-1.xenial
    4. ii icinga2-common 2.8.0-1.xenial
    5. ii icinga2-doc 2.8.0-1.xenial
    6. ii libicinga2 2.8.0-1.xenial
    7. root@workstation08:/var/log/apt#

    That is intended to be a client once i managed to bring it up, thus *ido* and *web* are missing.


    did the below multiple times, cleaned up between the attempts:

    Could it be that features need to be installed individually for 2.8 ?