Re: Generation of distributed nagios configuration w/cfengine

[Christian Pearce]

On Mon, 2004-08-02 at 11:54, Luke A. Kanies wrote:
> 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?  :)

No am very interested in ruby.  I bet you will find a lot of people
would complain.  So I thought I would be the first.

> > 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.

Makes perfect sense.  Now everything else make more sense.  I actually
have a similar setup for push files back.

> > 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.

Sounds very cool.  I will look into it more.

> > 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.

I think if we can formalize what is discussed in point 7, we might be
able to gain more traction.  Don't go through any effort at this point. 
I say we focus on 7.

> > 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.

Yea, I suggested it more than once.  I didn't see much chatter about
it.  I guess I should read the archives.  Log into #cfengine on freenode
we should talk.  I want to wrap my head around your code a ittle more. 
I haven't done anything with modules yet.

> > 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.
> 

I have a guy that works for us who uses nagios.  I am going to have him
take a look at it.

> Luke
-- 
Christian Pearce
http://www.commnav.com
http://www.perfectorder.com