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.
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. On Fri, May 30, 2014 at 2:35 PM, Michael Friedrich < michael.friedr...@gmail.com> 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 > > 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 > > Once I am done with LConf and a customers project, I'll go back to > 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 >> <michael.friedr...@gmail.com <mailto:michael.friedr...@gmail.com>> 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> >> >> 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> >> >> best regards, >> Michael >> >> >> -- >> DI (FH) Michael Friedrich >> >> michael.friedr...@gmail.com <mailto:michael.friedr...@gmail.com> || >> >> icinga open source monitoring >> https://twitter.com/dnsmichi || lead core developer >> dnsmi...@jabber.ccc.de <mailto:dnsmi...@jabber.ccc.de> || >> https://www.icinga.org/team >> irc.freenode.net/icinga <http://irc.freenode.net/icinga> || >> dnsmichi >> _________________________________________________ >> icinga-users mailing list >> icinga-users@lists.icinga.org <mailto:icinga-users@lists.icinga.org> >> https://lists.icinga.org/__mailman/listinfo/icinga-users >> <https://lists.icinga.org/mailman/listinfo/icinga-users> >> >> >> >> >> >> _______________________________________________ >> icinga-users mailing list >> icinga-users@lists.icinga.org >> https://lists.icinga.org/mailman/listinfo/icinga-users >> >> > > -- > DI (FH) Michael Friedrich > > michael.friedr...@gmail.com || icinga open source monitoring > https://twitter.com/dnsmichi || lead core developer > dnsmi...@jabber.ccc.de || https://www.icinga.org/team > irc.freenode.net/icinga || dnsmichi > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users >
_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
