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 #9623] missing config warning on empty port in endpoints #3149
Comments
Updated by mfriedrich on 2015-07-15 07:51:25 +00:00
|
Updated by mfriedrich on 2015-07-15 07:53:01 +00:00
Your configuration was probably created with a version before 2.3.6 (see the fix in #9205). Can you verify that the node wizard is working flawlessly (not setting the port attribute if empty) in 2.3.6+? |
Updated by VisionFhg on 2015-07-15 08:14:08 +00:00 Yes i can confirm this. We created the zones.conf with the wizard in a pre 2.3.6version. We distributed the faulty zones.conf with puppet, which was kind of separate from the wizard process.
results in:
|
Updated by mfriedrich on 2015-07-15 20:47:56 +00:00
|
Updated by gbeutner on 2015-07-16 08:46:18 +00:00
We should add a custom validator for the port attribute. Empty values should not be allowed. |
Updated by jflach on 2015-08-25 14:44:45 +00:00
Applied in changeset 0513be2. |
Updated by jflach on 2015-08-25 14:45:30 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/9623
Created by VisionFhg on 2015-07-15 07:28:38 +00:00
Assignee: jflach
Status: Resolved (closed on 2015-08-25 14:44:45 +00:00)
Target Version: 2.3.9
Last Update: 2015-08-25 14:45:30 +00:00 (in Redmine)
We discovered that a faulty configuration in the zones.conf lead to an inconsistency in the connection.
Our zones.conf were configured like this (on node and master):
Despite the missing Ports configuration everything was working flawlessly until a restart of the node, where the connection was lost and never able to recover unit a restart of the Masternode, after which everything was working again.
Adding the correct port information lead to no more connection losses. We reproduced this with 2.3.6.
Although it was a configuration error on our end, it might be worth to fallback to a sane default (5665) or throw a config error (better). As it was quite irritating to have a functional setup in the beginning, just to fail after a service restart on the node.
Feel free to contact us for further questions.
Changesets
2015-08-24 15:19:12 +00:00 by jflach 9f88a24
2015-08-25 14:43:52 +00:00 by jflach 0513be2
2015-08-25 14:44:32 +00:00 by jflach 9b05304
2015-08-25 15:06:08 +00:00 by jflach 2a9ac26
2015-08-25 15:10:20 +00:00 by jflach f71a2ca
2015-08-26 05:10:49 +00:00 by (unknown) d01330a
Relations:
The text was updated successfully, but these errors were encountered: