Re: Newbie help with how to implement update and cfagent.conffiles (fwd)

[Tim Nelson]

[Sorry for the delay, I originally posted with the wrong address and it 
bounced]

On Wed, 18 May 2005, PAUL WILLIAMSON wrote:

> cfservd.conf - Used only for the policy master.  But, I've seen
> references in the archives to people running the sfservd
> process on servers that are not policy masters.  I have no
> need to run more than one policy master at this point, so
> do I need to run cfservd on a cfclient-only machine?

 	You only need cfservd.conf on machines that you intend to run cfservd 
on.  As someone said, you use cfservd if you want to use cfrun. The simplest 
setup of cfengine is that it checks back to the master every X amount of time 
(half hour?) looking for new config.  But there's an alternative overall setup, 
as documented by Dr. Daystrom in section 2.8 of the tutorial.  I don't do his 
stuff myself, but some people like things that way.

> Another question I have is when is it appropriate to run cfagent
> in daemon mode vs. crontab?  I saw a post from Christian Pearce
> that he runs cfagent via crontab, distributed through the
> update.conf to add the entry via the Append line.  That seems
> like a very good idea.  I just can't find the darn post in the
> archives to test it out.

 	"daemon mode" is actually cfexecd running cfagent every once in a 
while.  Mark's idea was that cron could ensure that cfexecd is running, and 
cfengine could ensure that cron is running, and everything will not go down :).

Here's your original list:

> 1.  cfenvd running for at least a week on every machine where I want
> to use cfengine.  Keep this running if you want to use cfenvgraph
> later down the road.
> 2.  cfkey to generate pub-priv key on same machines.
> 3.  copy all pub keys from individual machines to the $cfengine/ppkeys
> in the format of user-ip.address.of.system.pub
> 4.  cfservd running on the policy master.  Can be running on
> non-masters for other purposes (like cfrun).
> 5.  Generate an update.conf and put it in your masterfile location.
> 6.  Generate a cfservd.conf ...
> 7.  Generate a cfagent.conf ...
> 8.  Test out (if possible) on the policy master.
> 9.  Copy update.conf to all systems.
> 10.  Roll it out.

        Taking Ed's suggestions, you end up with:

> 4.  cfservd running on the policy master.  Can be running on
> non-masters for other purposes (like cfrun).
> 5.  Generate an update.conf and put it in your masterfile location.
> 6.  Generate a cfservd.conf ...
> 7.  Generate a cfagent.conf ...
> 8.  Test out (if possible) on the policy master.
> 9.  Copy update.conf to all systems.
> 10.  Roll it out.

 	If you're using RPM, and install cfengine-masterconf, you can reduce it 
to these (renumbered and rewritten, to be basic, and have a few more steps):

1.      Install cfengine package everywhere
2.      Install cfengine-masterconf on policy master
3.      Run cfservd on policy master [4]
4.      Ensure cfexecd is running on all systems
5.      Edit configs on policy master (in /usr/etc/cfengine) [5,6,7]
6.      Copy update.conf to all systems

 	The above steps would work for any other OS, if someone wants to 
package cfengine-masterconf for it :).

        If you're looking for quickstart info:
http://cfwiki.org/cfwiki/index.php/QuickStart

        I do want to particularly address one of your points, though:

> 8.  Test out (if possible) on the policy master.

 	BAD!  Test it out on a test machine.  If there's something damaging in 
the configs, you do *not* want to be rolling it our on your policy master.

 	Having said that, my policy master uses the same configs as everything 
else at the moment :).  When we get our setup here working properly with 
staging servers and all, maybe we'll be able to put our cfengine conf in 
different classes too.  But until then...

-------------------------
Luke Youngblood wrote:

> I too would like to know what the hell cfenvd does exactly.  I know on some 
> systems that don't have proper /dev/random support (Solaris, I'm looking at 
> you :-) it generates entropy, but what else does it do besides that?
>
> I don't like having daemons running on my box unless I know EXACTLY what
> they do.  As near as I can tell, I get the same benefit from running only
> cfagent through cron as I do from running the entire cfengine stack.
>
> Would someone be willing to give me a summary?

        The way I see it, there's 3 basic daemons:
-       cfservd: you know this one :)
-       cfexecd: see above for further information; has some advantages
        over cron, and some disadvantages
-       cfenvd: Has these properties:
        -       Not enough documentation (or it's hard to find)
        -       "anomaly detection service (strongly recommended)" (thanks
                Tutorial)
        -       Collects data off your system
        -       Defines classes based on anomalys (see section 4.6 of
                Reference, "alerts")
        -       "It  is  part  of  the  on-going  research  in  anomaly
                detection using cfengine" (thanks "man cfenvd")
        -       "an optional daemon used to collect historical and
                statistical data from a host" (thanks cfwiki Glossary)


 	Hmm.  That's all I could pick up from the standard documentation. But 
when I hit Google, I found what we want to know:

http://www.delorie.com/gnu/docs/cfengine/cfengine-Anomalies_2.html

 	So, it basically collects data on your system, and when something 
statistically unusual happens, cfagent will define extra classes.

 	I'd always wondered a bit about this, and now I know.  I'll link to it 
from the wiki to make it easier to find.

        :)

--
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim.nelson@webalive.biz
http://www.webalive.biz/

"Your Business, Your Web, Your Control"