Security has never been a concern cause the users allowed to modify those parameters have access to the monitoring console. It's a closed environment.
About open sourcing our software it's not viable. It does thousands of things besides that and closely related to our organization so I doubt it's of any value for the community. It's just a bunch of webforms linked to an oracle database. Nothing interesting. > El 30/05/2014, a las 14:54, Michael Friedrich <[email protected]> > escribió: > >> 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 _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
