Nagios Plugins build under SPARC Solaris8 with SUNWspro CC fails

[Andreas Ericsson]

Ralph.Grothe at itdz-berlin.de wrote:
> Hi Rob, Marc, Frank et alii,
> 
> I had to leave office yesterday earlier why I couldn't continue.
> 
> Thus only now my feedback.
> 
> Many thanks for your kind support.
> 
> Because I was tired of my fruitless efforts yesterday I think I
> got a bit sloppy,
> as can be seen from creating a Nagios plugin directory with mode
> bits 0644 (where I meant 0755).
> Another such flaw was giving configure --disable-openssl where it
> should have been --without-openssl.
> So I guess it was simply ignored.
> But wouldn't you agree that it is rather inconsistent that
> configure from the nrpe tarball on the other hand looks for the
> --{enable|disable}-ssl switch.
> Very confusing.


NRPE and the plugins are completely separate sets of software. Expecting 
consistency between the two is like expecting HPUX to be similar to Windows.

> 
> Although I know that it is very easy to check the status of
> Informix DBs, and the VCS's out-of-the box Informix monitors are
> ashamingly simple, I wonder if someone already has come up with a
> check_informix or check_vcs/check_vxvm to save me the time coming
> up with an own custom Perl script?
> 

I think I've seen something about a check_informix. Google around a bit 
and see what pops up.

> As you may have noticed I set up nrpe daemon to run as informix
> rather than a less powerful nagios user.
> I would rather prefer the latter for security concerns.
> I only chose informix to be able to check the status of Informix
> instances (viz. system() or exec*() of onstat,
> or through Perl DBI::Informix).
> How could that be better addressed?
> Is there some suexec mechanism or would one set up sudo (or RBAC
> in the case of Solaris)?
> Suggestions welcome.
> 

chown informix:nrpeuser onstat
chmod 4750 onstat

This won't work with DBI::Informix, although it should work nicely if 
you backtick onstat from perl.

> 
> Frank,
> 
> thanks for the hints how to overcome the compiling catch with
> check_icmp.
> I will try your suggestion, and report.
> 

Latest CVS snapshot contains a bugfixed makefile for building 
check_icmp. If you want the latest and greatest you can visit 
http://oss.op5.se/nagios and download check_icmp-####-##-##.tar.gz 
(where ####-##-## represents a date).

> Apropos, I so far haven't really understood what is expected as
> PING_COMMAND string to render a working check_ping binary?
> You have to admit that the documentation either in the Nagios
> docs, or in configure's help screen is more than sparse.
> I think the developers should have provided a terse example to
> make things clear to dummies like me.
> 

PING_COMMAND is supposed to render itself. If you use check_icmp you 
won't need check_ping though, so this shouldn't be an issue.

> For instance on my Nagios Manager on AIX I defined this (because
> I had fping already installed, from my Mon setup,
> and I thought fping would perform better).
> 
> [nagios at daisy:~]
> $ grep ^\#define\ PING_COMMAND
> /opt/sw/nagios-plugins-1.4/config.h
> #define PING_COMMAND "/usr/local/sbin/fping -q -C 3 -t 2000"
> 

This is completely and utterly wrong. The check_fping plugin understands 
the output from fping (surprise!). It is not faster than regular 
check_ping, because fping by default also waits 1 second between packet 
transmissions. check_icmp does not, so that's a better option.

> [nagios at daisy:~]
> $ ls -l /usr/local/sbin/fping
> -rwsr-xr-x   1 root     staff     140575 Apr 26 2004
> /usr/local/sbin/fping
> 
> 
> But this config rendered a broken check_ping binary.
> 
> On the other hand on the Solaris mananged node I simply chose the
> path to Solaris' vanilla ping
> (which, as you may know, without any options simply reports
> "<node_name> is alive" to the astonishment of non-Solaris unix
> admins).
> 
> 
> # grep PING_COMMAND /usr/local/src/nagios-plugins-1.4/config.h
> #define PING_COMMAND "/usr/sbin/ping"
> 
> 
> But this doesn't work either 
> 
> [root at zecke:/usr/local/nagios/etc]
> # ../libexec/check_ping -H themis -w 1000,50% -c 2000,80%
> /usr/sbin/ping
> CRITICAL - Could not interpret output from ping command
> 
> 
> However, as said I don't really require the check_ping to be
> executable from the managed nodes
> but would be pleased to learn how its config was meant to be.
> 

It's meant to be autodetected. If it isn't, you probably won't be able 
to fix it, since the format is fairly arcane to those who doesn't 
intuitively understand sscanf() strings.

> Regards
> Ralph
> 
> 
> 
> 
>>-----Original Message-----
>>From: nagios-users-admin at lists.sourceforge.net
>>[mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
>>Ralph.Grothe at itdz-berlin.de
>>Sent: Tuesday, July 19, 2005 2:54 PM
>>To: robmossrm at aol.com
>>Cc: nagiosplug-help-admin at lists.sourceforge.net;
>>nagios-users at lists.sourceforge.net
>>Subject: RE: [Nagios-users] Nagios Plugins build under SPARC
> 
> Solaris8
> 
>>with SUNWspro CC fails
>>
>>
>>Hi Rob,
>>
>>I noticed that accidentally the separately mounted filesystem
>>/usr/local/src
>>got full during the build.
>>Luckilly it was on an SDS volume set up as softpartition so
> 
> that
> 
>>I could growfs it.
>>
>>I reran make distclean and reconfigured, this time disabling
> 
> the
> 
>>openssl stuff altogether.
>>So there should be no need for the blooming compiler to search
>>for such header files.
>>
>>
>># CC=/opt/SUNWspro/bin/cc ./configure
> 
> --with-nagios-user=informix
> 
>>--with-nagios-group=informix --disable-openssl
>>--with-ping-command=/usr/sbin/ping
>>
>>
>>This time my "make all" got a bit further, up to check_icmp
>>(ok, if I get check_ping this time working, opposed to my
> 
> broken
> 
>>check_ping build on HPUX,
>>I can ignore that, besides this is not a Nagios server, so
> 
> there
> 
>>should be little need for this node
>>to ping anything).
>>
>>
>>Here's the tail where cc aborted
>>
>>
>>/opt/SUNWspro/bin/cc  -g  -L. -o check_procs  check_procs.o
>>utils.o ../lib/libnagiosplug.a ../lib/li
>>bcoreutils.a popen.o ../intl/libintl.a  -lgen -lsocket
>>zecke --> Job output
>>/opt/SUNWspro/bin/cc  -g  -L. -o check_icmp  check_icmp.o
>>../intl/libintl.a  -lgen -lsocket
>>ild: (undefined symbol) gethostbyname -- referenced in the text
>>segment of check_icmp.o
>>ild: (undefined symbol) inet_addr -- referenced in the text
>>segment of check_icmp.o
>>ild: (undefined symbol) inet_ntoa -- referenced in the text
>>segment of check_icmp.o
>>*** Error code 5
>>dmake: Fatal error: Command failed for target `check_icmp'
>>Current working directory
>>/usr/local/src/nagios-plugins-1.4/plugins
>>Waiting for 1 job to finish
>>zecke --> Job output
>>/opt/SUNWspro/bin/cc  -g  -L. -o check_procs  check_procs.o
>>utils.o ../lib/libnagiosplug.a ../lib/li
>>bcoreutils.a popen.o ../intl/libintl.a  -lgen -lsocket
>>*** Error code 1
>>dmake: Fatal error: Command failed for target `all-recursive'
>>Current working directory /usr/local/src/nagios-plugins-1.4
>>*** Error code 1
>>dmake: Fatal error: Command failed for target `all'
>>[root at zecke:/usr/local/src/nagios-plugins-1.4]
>># df -k .
>>Filesystem            kbytes    used   avail capacity  Mounted
> 
> on
> 
>>/dev/md/dsk/d103      342255  254652   59514    82%
>>/usr/local/src
>>
>>
>>Ok, I got enough check_* binaries compiled (the important ones
>>for me being check_disk, check_procs, check_load)
>>
>># ls -F plugins|grep \*\$
>>check_dhcp*
>>check_disk*
>>check_dummy*
>>check_http*
>>check_load*
>>check_mrtg*
>>check_mrtgtraf*
>>check_nwstat*
>>check_overcr*
>>check_ping*
>>check_procs*
>>check_real*
>>check_smtp*
>>check_ssh*
>>check_tcp*
>>check_time*
>>check_udp*
>>check_ups*
>>check_users*
>>negate*
>>urlize*
>>
>>
>>Therefore I think I can get along with simply copying them
>>manually into place
>>
>># mkdir -m 0644 -p /usr/local/nagios/libexec
>>
>># (cd plugins && cp $(ls -F|grep \*\$|tr -d \*)
>>/usr/local/nagios/libexec/)
>>
>>
>>Let's hope they are not broken.
>>
>>Now I need to build the nrpe daemon.
>>
>>Since I'm almost dead sure that this will start yet another
>>debugging frenzy
>>I'll be back soon to ask for further help...
> 
>  
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
> ::: Messages without supporting info will risk being sent to /dev/null
> 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null