Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
icinga-migration opened this issue Sep 24, 2015 · 9 comments

Comments

@icinga-migration
Copy link
Member

@icinga-migration icinga-migration commented Sep 24, 2015

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:

@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 24, 2015

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

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 24, 2015

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

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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

  • Relates set to 10207
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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

  • Target Version set to 2.4.0
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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

  • Tracker changed from Bug to Feature
@icinga-migration

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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

This comment has been minimized.

Copy link
Member Author

@icinga-migration icinga-migration commented Sep 25, 2015

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.