On 30.05.2014 14:43, Jorge Ferrando wrote:
I mean we have a self developed software where we asign monitoring to some hosts and then we asign services to those hosts, then there's a field to enter custom parameters like -u whatever -h whatever2 and we have many of those fields, so it's not easy to change that. This information has been filled by many different users.
Well, from a security point of view it hurts. Probably your exporter must split the "-u foo" into vars.argname = "-u", vars.argvalue = "foo" and pass that accordingly.
Although I would reconsider that strategy, and only allow users to define optional values for a defined set of argument parameters. If then the command arguments are used they remain all optional by default. If you users don't add a value for "-u" then, Icinga 2 will omit the argument on execution and macro evaluation. That is different from Nagios, and imho one of those things which make Icinga 2 really better, having one command definition for everything.
And yes, probably not an easy change, but to be honest - I wouldn't let my users define the entire arguments and values on their own, but rather give them a list of parameters where they may add their required optional values. Probably a good idea to start over with your web interface and make it Icinga 2 ready then too. Any chance to open source it for the community?
It's a big nagios installation, we are monitoring around 3000 hosts and 3000 services so that's not easy to change or to adapt to icinga2 in an automated mode.
Nothing is easy, but if you really want to migrate, you'll sure make it happen. And it's even better for your strategy to adopt the changes made in Icinga 2 now, than to first migrate to Icinga 1.x and then look for possible upgrade paths.
On Fri, May 30, 2014 at 2:35 PM, Michael Friedrich <[email protected] <mailto:[email protected]>> wrote: On 30.05.2014 14:22, Jorge Ferrando wrote: It's just an example but we have hundreds of other services different from nrpe stored in a database cause we're using nagios so far. What kind of backend? I'm in the middle of fixing the LConf export, plus the Migration Script. But in fact your export $tool should know about that changed logic. If you're looking for the simple way of converting the old $ARG1$ macros, try this snippet http://git.netways.org/lconf/__lconf/blobs/next/src/generate.__pm.in#line1086 <http://git.netways.org/lconf/lconf/blobs/next/src/generate.pm.in#line1086> You can still define the vars.ARG1 = "foo" method on services, but it's ugly and unreadable. I'm just trying to find a way to migrate to icinga2 with no pain :) Depends. Every customization is a pain. But change is necessary. There's too much crap inherited from Nagios' history slowing down the knowledge and maintainability of these tools. There's no other workaround for it? Your exporter could use the ARGn vars, but also needs to take care about changed runtime macros. I've implemented that few hours ago for LConf here - http://git.netways.org/lconf/__lconf/commit/__a9654e8067c5dbb855b0d5de5caebf__f0e2338016 <http://git.netways.org/lconf/lconf/commit/a9654e8067c5dbb855b0d5de5caebff0e2338016> Once I am done with LConf and a customers project, I'll go back to https://dev.icinga.org/issues/__5929 <https://dev.icinga.org/issues/5929> If you could share some code of yours, it's probably more easy to help. On Fri, May 30, 2014 at 2:17 PM, Michael Friedrich <[email protected] <mailto:[email protected]> <mailto:michael.friedrich@__gmail.com <mailto:[email protected]>>> wrote: On 30.05.2014 14:03, Jorge Ferrando wrote: Hello I'm using icinga 2 and I have some command checks with arguments, for instance: object CheckCommand "check_nrpe"{ import "plugin-check-command" command = PluginDir + "/check_nrpe -H $host.address$ $args$" vars.args ="" } object Service "arecibo - Chequeo Disco 2 (NRPE)" { import "generic-service" host_name = "arecibo" check_command = "check_nrpe" vars.args = "-c check_disk2" } Problem is icinga2 is adding quotes around variable substitution and it makes command to fail: # /usr/lib/nagios/plugins/check_____nrpe -H '158.42.250.101' '-c check_disk2' NRPE: Command ' check_disk2' not defined # /usr/lib/nagios/plugins/check_____nrpe -H '158.42.250.101' -c check_disk2 DISK OK - free space: /var/log/nagios3 7469 MB (19% inode=99%);| /var/log/nagios3=30799MB;____40237;40227;0;40317 Is there any way to solve this or to remove those quotes from checks?? That's right. Arguments are automatically shell escaped. You should rather fix your Check Command to only pass argument values, but not entire strings just as lazy "args". That's common and wrong 1.x / Nagios thinking. Icinga 2 already ships the "nrpe" command. http://docs.icinga.org/____icinga2/snapshot/chapter-6.____html#nrpe <http://docs.icinga.org/__icinga2/snapshot/chapter-6.__html#nrpe> <http://docs.icinga.org/__icinga2/snapshot/chapter-6.__html#nrpe <http://docs.icinga.org/icinga2/snapshot/chapter-6.html#nrpe>> Use that to define your service check object Service "arecibo - Chequeo Disco 2 (NRPE)" { import "generic-service" host_name = "arecibo" check_command = "nrpe" vars.nrpe_command = "check_disk2" } If you want, add the "vars.nrpe_address = $address$" line, but that's already the default in the check command definition shipped with Icinga 2. I've created a ticket to update the documentation to make it more reasonable what to do. https://dev.icinga.org/issues/____6364 <https://dev.icinga.org/issues/__6364> <https://dev.icinga.org/__issues/6364 <https://dev.icinga.org/issues/6364>> best regards, Michael -- DI (FH) Michael Friedrich [email protected] <mailto:[email protected]> <mailto:michael.friedrich@__gmail.com <mailto:[email protected]>> || icinga open source monitoring https://twitter.com/dnsmichi || lead core developer [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>__> || https://www.icinga.org/team irc.freenode.net/icinga <http://irc.freenode.net/icinga> <http://irc.freenode.net/__icinga <http://irc.freenode.net/icinga>> || dnsmichi ___________________________________________________ icinga-users mailing list [email protected] <mailto:[email protected]> <mailto:icinga-users@lists.__icinga.org <mailto:[email protected]>> https://lists.icinga.org/____mailman/listinfo/icinga-users <https://lists.icinga.org/__mailman/listinfo/icinga-users> <https://lists.icinga.org/__mailman/listinfo/icinga-users <https://lists.icinga.org/mailman/listinfo/icinga-users>> _________________________________________________ icinga-users mailing list [email protected] <mailto:[email protected]> https://lists.icinga.org/__mailman/listinfo/icinga-users <https://lists.icinga.org/mailman/listinfo/icinga-users> -- DI (FH) Michael Friedrich [email protected] <mailto:[email protected]> || icinga open source monitoring https://twitter.com/dnsmichi || lead core developer [email protected] <mailto:[email protected]> || https://www.icinga.org/team irc.freenode.net/icinga <http://irc.freenode.net/icinga> || dnsmichi _________________________________________________ icinga-users mailing list [email protected] <mailto:[email protected]> https://lists.icinga.org/__mailman/listinfo/icinga-users <https://lists.icinga.org/mailman/listinfo/icinga-users> _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
-- DI (FH) Michael Friedrich [email protected] || icinga open source monitoring https://twitter.com/dnsmichi || lead core developer [email protected] || https://www.icinga.org/team irc.freenode.net/icinga || dnsmichi _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
