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 #12606] Config validation should complain about disabled API #4611

Closed
icinga-migration opened this issue Aug 31, 2016 · 3 comments
Labels
area/configuration DSL, parser, compiler, error handling bug Something isn't working

Comments

@icinga-migration
Copy link

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

Created by mfrosch on 2016-08-31 15:23:51 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-09-02 07:00:29 +00:00 (in Redmine)

Icinga Version: 2.5.3-80-g01b23ee
Backport?: Not yet backported
Include in Changelog: 1

Noticed the following in a test environment:

  • Icinga 2 configured with Zone + Endpoint
  • API disabled, since its currently only one Node
  • Checks assigned to Zone master (zones.d)

Result:

  • Config is validated without a warning
  • Running, but all checks in zone master PENDING, never to be checked

Expected:

  • Icinga should complain that complex zoning (more than 1 Zone or EP) needs API
  • Still check the checkables(???)
@icinga-migration
Copy link
Author

Updated by mfrosch on 2016-09-01 12:01:23 +00:00

This definitely is a problem of the Zone, when I move the data in conf.d the checkables are actually checked.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-09-02 07:00:29 +00:00

The problem is that without the ApiListener object Icinga doesn't know which zone it belongs to (it does this by loading the .crt file in ApiListener::OnConfigLoaded) - which means it won't un-pause those objects in ApiListener::UpdateObjectAuthority.

@icinga-migration icinga-migration added bug Something isn't working area/configuration DSL, parser, compiler, error handling labels Jan 17, 2017
@dnsmichi
Copy link
Contributor

dnsmichi commented Apr 5, 2018

I don't see a way to properly fix this, other than verifying on your own that all requirements are fulfilled.

@dnsmichi dnsmichi closed this as completed Apr 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/configuration DSL, parser, compiler, error handling bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants