Re: [Nagios-devel] nagios api

[Tony S. <to...@bu...>]

> 
> Tony Sceats wrote:
> > So, I suppose I have 1 question and one
> > suggestion.. the first question is does Nagios have an API, and is it
> > documented anywhere? If so, I suppose it would be in C or C++ ? 
> 
> Sort of. You can use cgiutils.c and the xodata stuff in the cgi and 
> xodata subdirectories of Nagios.
> The code is however in a semi-miserable state (it does pretty much what 
> it's supposed to, but configuration variables are in-line, 90% of the 
> variables are declared global, optimisations are left to the compiler 
> and memory management is a bit sketchy).
> 
> It's not documented anywhere except for rather extensive commentary 
> within the code itself. You might want to try the 'indent' program on it 
> if you want to try following the logic around without suffering 
> brain-damage.

damn, there I was thinking it might be easy :) I'll give it a go, see
what happens :) Jason suggested using the status.log, but this doesn't
seem appropriate. What I was looking for is a way to get something like
the output of this:

/cgi-bin/status.cgi?host=all&servicestatustypes=248&serviceprops=42&hostprops=42

but in plain text or in some kind of data structure.. 

> > The reason I ask is that I a while
> > ago now I wrote a cgi script that will list all the hosts currently
> > monitored with nagios.. it does this by parsing the relevant config files,
> > and will display this list as series of options.. for each host selected it
> > will put a comment in nagios by writing to the named pipe file
> 
> Sounds kinda useful, I guess. But with a script you won't be able to 
> access a C API without intermittent programs anyway.

it was intended more of a way to track which machines have been patched
against a known vulnerability more than anything, and the comments put
there just because it's nice to see the fact it's been patched recorded
somewhere. 

We monitor hosts on many different ISPs, and sometimes a whole bunch
will go down due to a routing issue (or whatever). Having host
dependencies on core routers sounds good, but in practise it's very hard
to keep up with dynamic routing issues... A way to acknowledge a whole
set of hosts at once would save a LOT of effort at times.. 

I wrote it as a script because I'm pretty rusty on C/C++ and usually get
away with just perl.. parsing configs with perl is no issue, but would
have taken me a while to do in C... not that I'm adverse to C, but day
to day I don't have much need for it.

> > And I suppose a related question would be how would one acknowledge
> > things and schedule downtime for this list? Is there a way to do this
> > via the named pipe file used for comments mentioned above? 
> > 
> Read the documentation. It's explained properly there.
> You can find it at www.nagios.org

I did have a look first, I swear ;) Anyway, Jason pointed me to the
External Commands doc, so thanks for that Jason.. unfortunately it
doesn't mention Acknowledging problems or scheduling downtime as
external commands :(

> > The suggestion I have is really for some of the plugins, I'm not sure if
> > this is the right place to put this... But anyway, it would be nice if they
> > supported an option to specify a source address. 
> 
> If you're talking about spoofing, you've ended up at the wrong list 
> (spoofing requires access to raw sockets, which means non-root users 
> can't use them). If it's something else, you might want to clarify that 
> a bit.

not spoofing - that would be reasonably useless in terms of monitoring.
But using an alias interface instead of the default interface (eg eth0:1
which has a different IP than eth0, however is in the same subnet).
Basically binding to a specified interface.. Afaik, this does not
require root privs. 

> 
> > I have already patched
> > check_http to do this (well, in fact I modified netutils.c), although
> > I did this dodgely, as I hard coded the IP (I was extremely short of
> > time to do this by the time it was considered to be the only option
> > forward). 
> 
> Bad Thing, no matter how short on time you are.

o, I know :( 

> 
> > During the course of going over the code it was seen clearly
> > that a lot of the plugins would require to be patched as the change had
> > to be made to the my_connect function in netutils..
> 
> Or you could have copied the my_connect() function to a copy of the 
> check_http plugin souce and modified the copied function.

now that would be a very sensible idea :)