[Nagiosplug-help] checking logs

Ralph.Grothe at itdz-berlin.de Ralph.Grothe at itdz-berlin.de
Tue Jul 24 09:34:42 CEST 2007


Hi Bob,

> -----Original Message-----
> From: Robert Cole [mailto:robert.cole at support4linux.com]
> Sent: Tuesday, July 24, 2007 12:29 AM
> To: Grothe, Ralph
> Cc: nagiosplug-help at lists.sourceforge.net
> Subject: Re: [Nagiosplug-help] checking logs
> 
> 
> Do you mean checklogs2.pl? I couldn't find check_log2.pl on the

> nagiosexchange.org site. check_log2 that I did find is a bash
script 
> which I found the check_log2.pl script at 
> http://www.koders.com/perl/fid61E0D250D999B73B285F27D4FB037369
> C01ED25E.aspx 


No, the check_log2.pl script is really part of the latest stable
nagios-plugins tarball which you can download from
http://www.nagios.org/download/
(though I am convinced that it has been part of it for quite a
while, not only since the latest releases)

Let me prove to you.
If you go to the above link and click for the nagios-plugins
tarball you are actually directed by a PHP script to a
sourceforge mirror
which is close to your client's IP or browser's language/locale
settings (not sure how they track your whereabouts, but I'd go
for the IP).
So my request is directed to this German mirror mesh.dl while
yours may be somewhere in the UK?

Since I don't want to download the stuff again I simply pipe it
directly to my local tar command and grep for check_log.

$ wget -q -nd -O -
http://mesh.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plug
ins-1.4.9.tar.gz|gzip -dc|tar tf -|grep check_log
nagios-plugins-1.4.9/plugins-scripts/check_log.sh
nagios-plugins-1.4.9/contrib/check_log2.pl


See, its there in the contrib subdir.
If you wish I could mail the script to you but I think it would
be better you get the original tarball yourself.


> and copy and pasted it in and I can run it locally and it 
> works but when 
> I try to let nrpe so its think I get:
> 
> NRPE: Unable to read output
> 
> Everything I can find on this says to check permissions and I
have 
> encountered this problem before and solved it when I saw the
nrpe.cfg 
> file changed back to root ownership but this time its not the 
> case. All 
> files in /usr/nagios/plugins and /etc/nagios are owned by 
> nrpe including 
> the directories themselves

It isn't even necessary that these files are owned by nrpe,
they simply need to be executable by this user.
In fact, I would rather let no file at all be owned by nrpe to
make it less susceptible to any (however remote) exploits.
If you install the nagios, plugin and nrpe packages on Linux by
the appropiate package manager
almost all these files belong to root and per se posses correct
perms.

E.g. here from an nrpe installation on one of our RHES servers.
I query the --scripts which will display what pre and post
install and uninstall scripts are executed on installation of the
RPM.
I am only interested in the first 5 lines since they already show
which user account would be set up if not supressed by the
--noscripts flag during an rpm -ihv (sometimes you don't want
these scripts to be run, if for instance you configure nrpe to be
run
under a different uid)


# rpm -q --scripts nagios-nrpe|head -5
preinstall scriptlet (using /bin/sh):
if ! /usr/bin/id nagios &>/dev/null; then
        /usr/sbin/useradd -r -d /var/log/nagios -s /bin/sh -c
"nagios" nagios || \
                logger -t nagios-nrpe/rpm "Unexpected error
adding user \"nagios\". Aborti
ng installation."
fi


As you can see it would useradd a user called nagios if it not
already existed.
I must have allowed the scripts to be executed because this user
exists

# id nagios
uid=101(nagios) gid=102(nagios) groups=102(nagios)

Now if I query lists of the files of all the relevant nrpe
packages on this host
and parse for any file that actually belongs to that user nagios
the output is nill

# rpm -ql nagios-nrpe nagios-plugins nagios-plugins-nrpe|xargs ls
-ld|awk '$3=="nagios"'

But if I count those belonging to root I get this

# rpm -ql nagios-nrpe nagios-plugins nagios-plugins-nrpe|xargs ls
-ld|awk '{t+=1;if($3=="root"){r+=1}};END{printf"%d of %d files
belong to root\n",r,t}'
190 of 190 files belong to root

Crude sanity check if my arithmetics were right

# rpm -ql nagios-nrpe nagios-plugins nagios-plugins-nrpe|wc -l
    190


This all was only meant to show that the RPM package maintainers
for RHES or CentOS deemed it totally in order that the package
contents all belonged to root.


But to see what's going wrong you need to make nrpe and inetd or
xientd (however you start your nrpe) send its stderr to syslogd
or a separate logfile,
if you chose so.
You should edit nrpe.cfg and put debug=1.
Preparing (x)inetd is a bit more involved and heavily depends on
your OS.
Most inetd understand some -d (as debugging) flag.
You must consult your inetd's manpage.
For instance, the HP-UX inetd has a nifty -l (and undocumented
-b) toggle switch which can be called with inetd by root at any
time to either sitch on or off
extended logging.
However, most inetds require to be sent a SIGHUP after their
reconfiguration.
Grep the inetd's PID from the process table an run "kill -1
<inetd_pid>" (you may also find the PID somewhere in
/var/run/inetd.pid or so).
Then hopefully, you will be seeing more in your syslogd's main
logfile (facility daemon) and the output from the plugins that
are failing
which already may be telling what went wrong.





More information about the Help mailing list