1

I've got about 10 machines configured with nrpe and Dell's OMSA to report to nagios. For each of those machines, output on the command line from the nagios server a la

./check_nrpe -H $HOSTNAME -c check_om_tag

matches the output I see in the web interface.

I've got one machine, though, that returns successful output from the command line on the nagios server, but on the web interface reports

NRPE: Unable to read output.

Every discussion I can find of the "unable to read output" error assumes that the command always fails, whether command line or web and suggests permissions or SELinux fixes. But the command line success should mean I don't have permissions or SELinux issues. Does anyone have experience with this kind of mismatch?

EDIT:

Success on command line on Nagios server

Error for client in Web interface

thepocketwade
  • 1,525
  • 5
  • 16
  • 27
  • Command line success under `check_nrpe`, yes? Are there any other nrpe services on this particular client? – MadHatter Mar 30 '16 at 13:09
  • `check_nrpe` succeeds on both command line and web interface for this client. Now I have 4 services on this client, 2 open_manage and 2 non-open_manage. The first 2 succeed in the web, and the latter 2 do not. All 4 succeed on the command line. – thepocketwade Mar 30 '16 at 13:15
  • I'm sorry to ask for clarification, but since you're *telling* us what you're dong, not *showing* us, I have to. When you say "*all four succeed on the command line*", you mean that all four NRPE checks on this client can be run by `check_nrpe` from the server's shell? – MadHatter Mar 30 '16 at 13:22
  • what user are you using running command? maybe command succeeds with root user, but fails with nrpe/nagios? – Martynas Saint Mar 30 '16 at 13:25
  • @MadHatter I mean that from the nagios server shell I can successfully run all 4 nrpe checks. From the web interface on the Nagios server 2 succeed, and 2 show an error. – thepocketwade Mar 30 '16 at 13:29
  • Fair enough, that's what I thought you meant, and I agree with you, that rules out user mismatch, selinux on the client, NRPE SSL negotiation issues, and just about all the usual suspects. Personally, I think we're going to need to see the NAGIOS config for all four checks, on both server and client, to have the faintest chance of commenting further. – MadHatter Mar 30 '16 at 13:33
  • Yeah, that's probably true, I've got to figure out exactly what I'm able to share, if we're talking sharing configs. I was hoping that a plain mismatch would be enough of a trigger for discussion. I'm mostly struck by the fact that clearly remote checks from the nagios server work, but the information is getting lost as far as the web side of things is concerned. – thepocketwade Mar 30 '16 at 13:37
  • @systemsninja I've manually run the command successfully as root, nagios, and nrpe. Nagios runs the commands as the nagios user. – thepocketwade Mar 30 '16 at 14:01

1 Answers1

0

Well, this turns out to be much ado about nothing. After combing the logs, I found Nagios sending requests to an IP that doesn't belong to any of the configured servers. Double checked the configuration for this particular client, and it was wrong. Fixing that, of course, fixed the weird error mismatching.

thepocketwade
  • 1,525
  • 5
  • 16
  • 27