Generating nagios configs from LDAP, nmap, and traceroute

[Luke A. Kanies]

On Thu, 18 Dec 2003, Luke Rosenthal wrote:

> Yeah, plus if it's all just generated in a big lump, you tend never to
> really understand it the same as if you'd written it yourself by hand.  In
> the short term it's easier but in the longer term you end up scratching
> your head more, and wasting more time trying to understand what's been
> generated!  Like reading somebody elses sloppy code!

I'm all for not understanding how things work if I don't need to
understand.  I have no real idea how device drivers work, and I think
that's a good thing.  I'd some day prefer not to have any idea how Nagios
works; just say "hey, get the hosts from this ldap server" and have it
automagically monitor all of the appropriate stuff.  Let the stupid
computer do the stupid work.

> > I've written a lot of scripts to do things like gen apan config entries
> > and push extinfo and such.  But hosts.cfg and hostgroups.cfg and
> > services.cfg (etc) are all by hand.
>
> I find the best way is to whip up a quick and dirty perl script (or
> bash/sed/awk, whatever) to mangle the data out of whatever form it's in
> and turn it into something I can paste into the config.  It sounds old
> fashioned, but you would be surprised how often we export from whatever
> data source (usually windows-based, like Maximizer, ugh) to a flat text
> comma-delimited file, then just mangle that out into a series of config
> entries using perl.  We only do this infrequently tho (once every few
> months) and it only takes me half an hr or so each time.  Sure beats data
> entry!!

The problem comes when you need to add or remove or change a host.  You
have to do that in every separate application that knows about your host.
If you have a single, normalized, authoritative host list (in LDAP, SQL,
or a flat file; it doesn't matter) then you only need to change that one
list and everyone else automatically updates themselves.

Certainly when I'm done I expect that when I add a host to LDAP or remove
one from LDAP, Nagios will automatically (through no manual effort at all)
rebuild its configuration to take into account this change, including any
services it should monitor and IPs it depends on.  That, combined with
using cfengine to configure nsca on the local host, provides completely
automated monitoring and reaction.

> > I watch 247 hosts and 1111 services (and counting).
>
> Bout the same for us.  Next step is trying to implement something with
> net::ssh::perl that logs in and restarts services that fail, somehow
> linked to event handlers.  Anyone had experience with this?  Could
> check_by_ssh be given some creative commandline arguments?

I highly recommend you look at using something like cfengine for
restarting services locally.  It gives you a straightforward syntax for
restarting failed services, although it does not integrate with Nagios
plugin checks.  I've you're just restarting bombed services, though,
that's probably your best bet, and it certainly has fewer security
implications.  As a bonus, you can use it to centralize your nagios
configurations (if you're using nsca or something).

I'm using cfengine to install and configure pretty much all of my open
source software, along with checking that my basic processes are running
(syslog, sshd, etc.) and checking a bunch of other stuff.

Luke (Kanies)

-- 
"Only wimps use tape backup: _real_ men just upload their important
stuff on ftp, and let the rest of the world mirror it."
                --Linus Torvalds on linux-kernel


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&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