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 #8333] Icinga2 master doesn't change check-status when "accept_commands = true" is not set at client node #2586

Closed
icinga-migration opened this issue Feb 1, 2015 · 8 comments
Labels
bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

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

Created by nuts on 2015-02-01 17:43:47 00:00

Assignee: gbeutner
Status: Resolved (closed on 2015-02-05 14:18:44 00:00)
Target Version: 2.3.0
Last Update: 2015-02-13 07:10:46 00:00 (in Redmine)

Icinga Version: 2.2.3
Backport?: Already backported

Icinga2 master and client node are configured for remote-check-execution like here [1].

Two szenarios:
(1) When "accept_commands = true" is missing in api.conf on the client, the master reschedule the remote check again and again. The state is pending. (thats not the bug but a question of concept)

(2) When a check successed with OK ("accept_commands = true" is set) and then "accept_commands = true" removed from the client node api.conf the master didn't change the check-status and check-output. The master can't get informations from the client node because the client node does not accept commands. But the master shows the old status with OK.

I think it would be better for the first szenario that the icinga2 master reports that commands are not allowed on the asked client node. For the secound szenario the check-state and output is wrong.

It is reproduceable with a working config on master and client and a configured remote check via remote-check-execution. When it works fine remove "accept_commands = true" from the client node api.conf.

[1] http://docs.icinga.org/icinga2/latest/doc/module/icinga2/chapter/monitoring-remote-systems#icinga2-remote-monitoring-client-command-execution

Changesets

2015-02-05 14:17:56 00:00 by (unknown) 2d5112c

Send check result even when accept_commands is not set

fixes #8333

2015-02-05 14:38:13 00:00 by (unknown) ddce723

Send check result even when accept_commands is not set

fixes #8333

Relations:

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-02 07:22:02 00:00

  • Relates set to 8257

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-03 14:42:21 00:00

  • Target Version set to 2.3.0

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-05 09:21:21 00:00

  • Subject changed from Icinga2 master dosn't change check-status when "accept_commands = true" is not set at client node to Icinga2 master doesn't change check-status when "accept_commands = true" is not set at client node

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-05 14:18:28 00:00

  • Status changed from New to Assigned
  • Assigned to set to gbeutner

@icinga-migration
Copy link
Author

Updated by Anonymous on 2015-02-05 14:18:44 00:00

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

Applied in changeset 2d5112c.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-05 14:18:55 00:00

Please test whether this is fixed.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-02-05 14:38:00 00:00

  • Target Version changed from 2.3.0 to 243
  • Backport? changed from TBD to Yes

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-02-09 15:35:38 00:00

  • Target Version changed from 243 to 2.3.0

@icinga-migration icinga-migration added bug Something isn't working libicinga labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.3.0 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant