Hi, we use "command-args" with NRPE and "down_blame_nrpe=1". We need it critically. Why was "command-args" USE flag removed from this package? Now, it is not possible to install NRPE with command-args support, so our argumented commands doesn't work with log error message "Error: Request contained command arguments!" :( Thank you for your answer.
For addition, this issue is related only to NRPE 3+. Latest 2.15r3 still contains "command-args" USE flag.
https://github.com/gentoo/gentoo/commit/1aa4d1f895af173e41d53f5d811a62788a68d7f2 For what reason do you need it? What is the use case?
We have about 80 servers monitored by central Nagios server and maintained by Ansible. Some dynamic checks are configured in central Nagios (for example, each harddrive has nagios-service ie. "check_nrpe_disk!/dev/sda3|10%|20%"). Of course, it can be refactored to ie. "check_nrpe!check_dev_sda3" (and "check_dev_sda" configured in nrpe.cfg on target server) - but, it's unflexible. But sometimes are cases, where I need to monitor same service (for example "check /dev/sda") multiple times. One service with "benevolent threshold" (ie. 10%/20%) just for notification and other for "extreme threshold" (ie. 1%/2%), which runs some our triggers (event-handlers). When command-args are not supported, NRPE flexibility is really very limited for us. Our servers are monitored over IPsec tunnels, also limited by IP addresses and our plugins have strictly-validated arguments. Whole Nagios central server is private only. In our case, there is no security risk. I think, that command-args could be DISABLED by default, but when someone need it, it could by possible to enable it. Thank you for understanding.
Hi, sorry this caused you problems. I made a judgement call when making the nrpe-3.x ebuild. The ./configure script for nrpe says, --enable-command-args allows clients to specify command arguments. *** THIS IS A SECURITY RISK! *** Read the SECURITY file before using this option! Since we don't have an analogous way to warn you about the USE flag, I thought it best to remove that option by default. For a workaround, you can add --enable-command-args to the EXTRA_ECONF variable for the nrpe package. The following two articles should get you up to speed on overriding environment variables per-package: https://wiki.gentoo.org/wiki/Knowledge_Base:Overriding_environment_variables_per_package https://wiki.gentoo.org/wiki//etc/portage/package.env Afterwards, all you should need to do is set EXTRA_ECONF="--enable-command-args" for net-analyzer/nrpe. The contents of that variable are passed directly to the ./configure script.
I just asked about this on the -dev mailing list: https://archives.gentoo.org/gentoo-dev/message/015cfae58631b7652cf7315d396ea2d0 I don't know whether e.g. the security team will suggest that we leave it completely disabled, or if everyone will agree that a masked USE flag is fine.
Michael, thank you for workaround with ENV! I'm stupid that I did not realize it :) This helps: > echo 'EXTRA_ECONF="--enable-command-args"' > /etc/portage/env/nrpe-extra-conf > echo "net-analyzer/nrpe nrpe-extra-conf" > /etc/portage/package.env/nrpe > emerge net-analyzer/nrpe > .. after that, NRPE is installed with "command-args" support :-) I close this issue, thank you guys.
(In reply to Ján Regeš from comment #3) > We have about 80 servers monitored by central Nagios server and maintained > by Ansible. > > Some dynamic checks are configured in central Nagios (for example, each > harddrive has nagios-service ie. "check_nrpe_disk!/dev/sda3|10%|20%"). Of > course, it can be refactored to ie. "check_nrpe!check_dev_sda3" (and > "check_dev_sda" configured in nrpe.cfg on target server) - but, it's > unflexible. > > But sometimes are cases, where I need to monitor same service (for example > "check /dev/sda") multiple times. One service with "benevolent threshold" > (ie. 10%/20%) just for notification and other for "extreme threshold" (ie. > 1%/2%), which runs some our triggers (event-handlers). > > When command-args are not supported, NRPE flexibility is really very limited > for us. Our servers are monitored over IPsec tunnels, also limited by IP > addresses and our plugins have strictly-validated arguments. Whole Nagios > central server is private only. In our case, there is no security risk. > > I think, that command-args could be DISABLED by default, but when someone > need it, it could by possible to enable it. > > Thank you for understanding. So right now the logic how to monitor the disks is in Nagios (I mean the thresholds). If you move it to Ansible (set a default disk warning/critical level and override per server role), you can probably disable the command arguments. If you need to change the thresholds, you set them in the server role and deploy the nrpe configuration.
Hi Ján, no one objected to me putting the flag back masked. So, USE=command-args is back in nrpe-3.2.0-r2, but you'll have to unmask the flag. You can do that by adding the line, net-analyzer/nrpe -command-args to the file, /etc/portage/profile/package.use.mask The EXTRA_ECONF workaround is no longer necessary afterwards.
Thank you, Michael! :-) It is really necessary to "unmasking" USE flag this way? It looks, that my standard USE flag definitions for packages works well: 1) "net-analyzer/nrpe command-args" in "/etc/portage/package.use/nrpe" 2) OUTPUT of "emerge -av net-analyzer/nrpe": > [ebuild U ~] net-analyzer/nrpe-3.2.0-r2::gentoo [3.2.0-r1::gentoo] USE="command-args%* ssl (-selinux)" So NRPE will be installed with "command-args" support. Probably, "command-args" is not MASKED, but just DISABLED by default and can be enabled like any other tags. Maybe "unmasking USE flag" and "enabling USE flag" are the same thing? I knew masked packages, but not masked USE flags.
(In reply to Ján Regeš from comment #9) > Thank you, Michael! :-) > > It is really necessary to "unmasking" USE flag this way? > This way is a slight improvement over EXTRA_ECONF, because it plays nicer with portage features like --changed-use and --newuse. I realize it's roughly the same amount of work to unmask it, though. I would reconsider masking the flag if there are others that need it. It's a trade-off between a little extra work for those who need it, and a possible vulnerability for those who don't but enable it anyway. Debian also has command-args disabled, and they recommend check_by_ssh to replace much of NRPE's functionality: https://www.monitoring-plugins.org/doc/man/check_by_ssh.html If all of your monitored hosts are capable of running SSH, that should be a lot safer: SSH is already running, it requires authentication, can limit the commands that are executed, etc.
*** Bug 635988 has been marked as a duplicate of this bug. ***
