Re: Generation of distributed nagios configuration w/cfengine

[Luke A. Kanies]

On Mon, 2 Aug 2004, Christian Pearce wrote:

> I just read the INSTALL.  There is a lot to digest.  I want to take some
> time this afternoon and play with it.  My initial reaction is that this
> is very complex and a little overwhelming to a new reader.  But I think
> that could be improved by having a better overview.  Let's face it
> explaining this stuff is tough. (Or maybe it is to early in the
> morning)  That was offered as a suggestion and not a harsh criticism.
> Here are some other thoughts.

Yeah, I wrote it all up in one session, just to get some docs out there.

> 1. Ruby? Ugh (Just kidding, I need an excuse to learn it)

Yeah well.  It got done faster this way.  It's not actually that much 
code, so it could be redone in perl.  Or pieces of it could be redone. 
But heck, you're already using cfengine to do package installations, so 
what's another package?  :)

> 2. module:nagios in subversion is not a good filename, I can't click on
> it without getting "module is not a registered protocol.

Yeah, but I don't get to pick the filenames.  I'll change my makefile to 
copy the file over with another name.

> 3. Why do you push the a remote.cfg out to the nagios clients.  Is this
> for people who don't use Cfengine?

It's the opposite:  The clients each push their generated remote.cfg up to 
the central server.  As to why I do it this way...

Only my hosts themselves know how cfengine has configured them, so only 
they are qualified to generate a valid monitoring configuration.  Thus, 
they have to generate it, and then I have to get the configuration to the 
central server, which will collate all of them into a single file.

> 4. I am not certain of the integration of Cfengine (I need to reread
> INSTALL)

Well, the main way in which it integrates with cfengine is that cfengine 
already has a list of classes associated with each machine (e.g., 
mail_server, dns_server, cfengine_server); if any associated classes are 
found in the hostgroups.cfg file, then the host is added to that 
hostgroup.  Thus, I just specify in nagios which groups I'm interested in, 
and cfengine automatically adds the appropirate hosts to each group.

The other piece is slightly murkier and depends a lot on how you are using 
cfengine.  If you're already using cfengine to, for instance, decide which 
packages are installed, then just add a line to add appropriate services 
to the nagios services variable.  For instance, I use cfengine to install 
packages directly (i.e., not using rpms or whatever), and this allows me 
to create a <package>.cf file for each package.  So, I've got an httpd.cf 
file that defines everything I want to do with httpd, such as pulling 
configurations from subversion and stuff like that.  In that file, I just 
add the following line:

nagSvcs = ( "${nagSvcs}:httpd" )

and as long as there's a 'check_httpd' command, it all just works.

The great thing about this is that it allows me to reuse the fact that 
cfengine already knows I'm installing httpd; if you're not using cfengine 
to add packages, this doesn't really help, but if you are, then this 
allows you to keep that information normalized, instead of having to 
configure it in multiple places.

> 6. Can we setup a mailing list? I don't think it would be appropriate to
> hash out problems about naginator?

We certainly can, but I'll be relatively surprised (based on experience) 
if many people join.  I'll see if I can get a mail server set up today; 
otherwise, it won't be until next week.

> 7. This opens up an opportunity to start discussing the idea of a
> Cfengine Module Repository. What we need is a set of guidelines for
> writing modules.  This would help with plugging in any module and
> getting it to work in any Cfengine environment.  Provided the Cfengine
> implementor implemented the guidelines correctly.  I am not certain if
> this is possible.  But think of the merit?  We can start sharing the
> wealth of Cfengine knowledge beyond just talking about it.  This would
> provide great leverage.  This is the first project I have seen that
> would tap into the possibility

Yes, this would be great, and has been discussed tons of times.  No one 
has yet come up with a sufficiently maintainable solution.  I would be 
glad to help, especially since I've now built quite a few useful modules. 
Maybe we could just start by creating a web page linking to other people's 
modules, maybe with tarballs locally or something?  I could throw that up 
pretty quickly.

> 8. I want to help.

Great!  I'd love help.  Feature requests are especially good, because I've 
(somewhat obviously) written this to do what I think is appropriate, but 
that usually does not result in a sufficiently useful solution.  I know 
that the currently solution needs a bit more abstraction, but I'm not sure 
where exactly it needs that abstraction.  I've tried to keep the separate 
components as separate as possible, but we'll see how well I've succeeded.

Luke

--
Due to circumstances beyond your control, you are master of your fate
and captain of your soul.
---------------------------------------------------------------------
Luke Kanies | http://abstractive.org | http://reductiveconsulting.com