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 #9584] Incorrect return value for the macro() function #3134

Closed
icinga-migration opened this issue Jul 8, 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/9584

Created by roji on 2015-07-08 10:58:38 +00:00

Assignee: gbeutner
Status: Resolved (closed on 2015-07-13 06:26:33 +00:00)
Target Version: 2.3.7
Last Update: 2015-07-16 08:30:03 +00:00 (in Redmine)

Icinga Version: 2.3.5
Backport?: Already backported
Include in Changelog: 1

(originally posted as a question to icinga-users, received response for Michael Friedrich)

My check looks like this:

object Service "mydb" {
  import "generic-service"
  host_name = "somehost.mycompany.com"
  check_command = "postgres"
  vars.postgres_host = "somehost.mycompany.com"
  vars.postgres_dbname = "catalog"
  vars.postgres_dbuser = "mon"
  vars.postgres_dbpass = "mon"
  vars.postgres_action = "connection"
}

This check generates the error "Peer authentication failed for user "mon"", which after some digging is the result of the lack of a -H (host) parameter to check_postgres.pl. Note that in /usr/share/icinga2/include/plugins-contrib.d/databases.conf the CheckCommand object includes "vars.postgres_unixsocket = false", and the -H argument has "set_if = {{ macro("$postgres_unixsocket$") == false }}". Since I haven't defined postgres_unixsocket to be true (or anything else) the expectation is for the -H to be passed, but this doesn't happen.

This seems to be because macro("$postgres_unixsocket$") always returns a String although $postgres_unixsocket$ is a Boolean.

Changesets

2015-07-13 06:25:19 +00:00 by (unknown) 8dedd47

Fix incorrect return value for the macro() function

fixes #9584

2015-07-13 06:26:17 +00:00 by (unknown) c2da486

Fix incorrect return value for the macro() function

fixes #9584
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-07-09 08:32:51 +00:00

https://lists.icinga.org/pipermail/icinga-users/2015-June/009733.html

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-07-09 08:33:15 +00:00

Probably a bug in the macro() function.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-07-13 06:09:26 +00:00

  • Description updated

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-07-13 06:16:48 +00:00

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

The underlying problem is that the macro code resolves your macro like this:

  1. Look up the value of the 'postgres_unixsocket' custom variable. This yields a boolean value.
  2. Coerce the result to a string and look for more macros in that string (we support nested macros).

There's already a special case for Array objects and I guess it would make sense to expand that to include all other scalar non-string values (i.e. numbers and booleans).

@icinga-migration
Copy link
Author

Updated by Anonymous on 2015-07-13 06:26:33 +00:00

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

Applied in changeset 8dedd47.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2015-07-13 06:26:57 +00:00

  • Category changed from ITL to libicinga
  • Target Version set to 2.3.7
  • Backport? changed from TBD to Yes

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-07-15 08:32:11 +00:00

  • Subject changed from Problem with postgres CheckCommand definition to Incorrect return value for the macro() function

@icinga-migration
Copy link
Author

Updated by roji on 2015-07-16 08:30:03 +00:00

Thanks, I can confirm the problem is gone in 2.3.7!

@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.7 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