[dev.icinga.com #10216] Clarify on cluster/client naming convention and add troubleshooting section

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/10216

Created by ziaunys on 2015-09-24 21:40:00 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2015-09-25 09:34:21 +00:00)
Target Version: 2.3.11
Last Update: 2015-09-25 09:37:21 +00:00 (in Redmine)

Backport?: Already backported
Include in Changelog: 1

---

I have a situation where I have a client and master separated by a firewall. I have to NAT connections established by the client to reach the master node. I can verify the connection from both the master -> client and client-> master. However, checks executed by the client are stuck in a pending state. The master's "cluster-zone" check for the client is succesful. When I enable debug logging on the client, I can see the check results are being relayed to the master correctly, but the state is never updated.

The problem seems to be that it won't relay checks back to the parent node correctly because the A record pointing at the static NAT address is different than the one pointing at the internal address. It seems like external nodes shouldn't be dependent on DNS.

I don't actually see an error message indicating any issue, but one theory I've had is maybe it was failing because the external hostname didn't match the hostname set on the Puppet cert as an alt name. In this situation I guess it wouldn't really be a bug.

Changesets

2015-09-25 09:34:01 +00:00 by mfriedrich 6555e42

Docs: Cluster naming convention for clients, troubleshooting for overdue check results

fixes #10216
fixes #10207

2015-09-25 09:36:46 +00:00 by mfriedrich 4c87f62

Docs: Cluster naming convention for clients, troubleshooting for overdue check results

fixes #10216
fixes #10207

---

Relations:

• relates #10216

[icinga-migration]

Updated by mfriedrich on 2015-09-24 21:51:46 +00:00

• Status changed from New to Feedback
• Assigned to set to ziaunys

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring-high-availability#cluster-naming-convention

Is applied all the way through?

[icinga-migration]

Updated by ziaunys on 2015-09-24 22:11:31 +00:00

dnsmichi wrote:

http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/distributed-monitoring-high-availability#cluster-naming-convention

Is applied all the way through?

Ahh.. that's the issue. The endpoint names didn't match because the external hostname doesn't match the CN which was more of a configuration issue on my part. Thanks for pointing that out.

[icinga-migration]

Updated by mfriedrich on 2015-09-25 07:43:38 +00:00

• Subject changed from Icinga2 client depends on the master's internal DNS name to Clarify on cluster/client naming convention in the remote clients chapter
• Category changed from Cluster to Documentation
• Status changed from Feedback to Assigned
• Assigned to changed from ziaunys to mfriedrich

I'll change that into a documentation issue, and add that information to the remote clients chapter.

[icinga-migration]

Updated by mfriedrich on 2015-09-25 09:30:28 +00:00

• Relates set to 10207

[icinga-migration]

Updated by mfriedrich on 2015-09-25 09:30:59 +00:00

• Subject changed from Clarify on cluster/client naming convention in the remote clients chapter to Clarify on cluster/client naming convention and add troubleshooting section

Also managed to add a dedicated troubleshooting chapter.

[icinga-migration]

Updated by mfriedrich on 2015-09-25 09:31:11 +00:00

• Target Version set to 2.4.0

[icinga-migration]

Updated by mfriedrich on 2015-09-25 09:33:18 +00:00

• Tracker changed from Bug to Feature

[icinga-migration]

Updated by mfriedrich on 2015-09-25 09:34:23 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 6555e42.

[icinga-migration]

Updated by mfriedrich on 2015-09-25 09:37:22 +00:00

• Target Version changed from 2.4.0 to 2.3.11
• Backport? changed from TBD to Yes