Hier war gerade (letzte zwei Wochen) ? ein änlicher "Fall" mit RHEL /CENTOS; es handelte sich um eine SELINUX Sache.
Ist es dir möglich das mal probehalber etwas niedriger als "enforce" einzustellen ?
Hier war gerade (letzte zwei Wochen) ? ein änlicher "Fall" mit RHEL /CENTOS; es handelte sich um eine SELINUX Sache.
Ist es dir möglich das mal probehalber etwas niedriger als "enforce" einzustellen ?
Back to the screenshot; We see that localhost seems to resolve to two different IP's, perhaps that confuses something.
Can you try to connect using psql -h 127.0.0.1 -U icinga -p 5432 and if that works, change the host and port fields in icingaweb2 accordingly.
Also an idea:
i feel that it should - as long as the postgresql service and the webserver are both at the same machine.
does netstat -an | grep ':5432' list 127.0.0.1 as well as ::1 ? not that localhost resolves to an adress the daemon does not serve...
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.
Client:
Master:
Now, that we know what the problem is, we fix that at the master:
After a few minutes the remote checks are running.
Great that it worked out !
thanks for the clarification !
Michael already told you that:
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.
That is why the zones.conf file can not be the same at both machines.
Sorry, i did not checked it out myself, but here are some pointers (the second answers your question best, i guess):
https://www.icinga.com/docs/ic…mand-signing-and-ca-proxy
https://www.icinga.com/2017/11/13/how-to-icinga-2-ca-proxy/
So, you are telling us that:
Is this correct ?
any unintentional rollback of a former snapshot of the VM ?
Initially did exactly that to get a state as clean as possible.
Did it multiple times, it never worked out.
A few days later the same process worked.
But thanks anyway.
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.
Re-did it at the problematic machine, went OK without any issues.
I can not tell what it was, thanks again.
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:
Hope that helps.
thanks to both of you - will check with a vm first.
Thanks, here is my output. Perhaps a pakaging thing ?
That is intended to be a client once i managed to bring it up, thus *ido* and *web* are missing.
hello,
did the below multiple times, cleaned up between the attempts:
Could it be that features need to be installed individually for 2.8 ?