help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bootstrapping


From: John Sechrest
Subject: Re: Bootstrapping
Date: Thu, 19 Feb 2004 09:31:39 -0800


In order to complete the loop on my MLN configuration process,
one of the issues is how to derive the monitoring configuration file
so that when I specify that X host is doing Y service, that the
monitoring system expects to see Y on X. And does the green/yellow/red
alert thing.

But more importantly, on all of those same machines, we want to 
have a cfengine column which indicates that the cfengine service is
working correctly. And so what information would I look for 
in order to set this tool?

Would I have Cfengine look at the state of it's classes and 
to write a token out based on the state of those classes. And 
then have the monitoring tool expect the token?


"Luke A. Kanies" <luke@madstop.com> writes:

 % On Thu, 19 Feb 2004 Mark.Burgess@iu.hio.no wrote:
 % 
 % > Can you give an example. I thought the idea of convergence is that
 % > there is no need for such things. Maybe if you just think in the
 % > "right"  way you can already do this..
 % 
 % How do I know if all of my machines are updating themselves?  How do I
 % know if all of my machines have successfully copied all of their files,
 % started all of their processes, made all of their changes?  There are many
 % potential problems (issues with the cfengine keys, configurations for the
 % processes, nonexistent files) and although it's straightforward to have
 % cfengine email me, it's less straightforward to turn those emails into
 % meaningful information.
 % 
 % Convergent processes can only do so much; you also need mechanisms for
 % dealing with errors, and cfengine is largely lacking those.  Not that it's
 % not fault-tolerant to an extent, just that it doesn't seem to deal much
 % with faults within the system or the configuration.
 % 
 % Most companies already have some kind of monitoring system, and those
 % monitoring systems usually have a red/yellow/green classification system
 % for all hosts.  I would consider the cfengine service on a host to be red
 % if the host is not updating itself at all, and yellow if there are other
 % problems.  I'd actually like greater granularity -- maybe a count of the
 % number of errors encountered -- but I'd accept the red/yellow/green system
 % to start.
 % 
 % How would one go about getting this information into an NMS?  At this
 % point, I have to have something monitoring the syslog files and/more
 % email, and this monitor has to differentiate between different types of
 % failures (key exchange failure, cfexecd failure, minor error, sshd
 % failure, etc), and then upload that to the NMS.
 % 
 % If cfengine had better ideas of failure, then this would be much easier.
 % Failure of some kind is absolutely inevitable, which makes it imperative
 % that we deal well with it.  See my earlier post about how I monitor syslog
 % output to get system status into LDAP.
 % 
 % Luke
 % 
 % -- 
 % I think that all good, right thinking people in this country are sick
 % and tired of being told that all good, right thinking people in this
 % country are fed up with being told that all good, right thinking people
 % in this country are fed up with being sick and tired.  I'm certainly
 % not, and I'm sick and tired of being told that I am.
 %                 -- Monty Python
 % 
 % 
 % _______________________________________________
 % Help-cfengine mailing list
 % Help-cfengine@gnu.org
 % http://mail.gnu.org/mailman/listinfo/help-cfengine

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest@peak.org
                                      .   
                                              . http://www.peak.org/~sechrest




reply via email to

[Prev in Thread] Current Thread [Next in Thread]