help-cfengine
[Top][All Lists]
Advanced

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

Re: Configuration File Organization


From: Christian Pearce
Subject: Re: Configuration File Organization
Date: Fri, 30 Jul 2004 12:19:43 -0400

Arch?  As in Arch Linux?

File layout can be tricky when it comes to organization and importing. 
I will give you my file layout.  It has worked well for me and I never
had to change it.

Keep in mind I have a process that builds the cfengine from templates
based on configurations stored in a database or LDAP.  You might not
find this suits your needs.

cfagent.conf - Main configurations, anything site wide that pertains
specifically to how you want cfengine to behave.

cfservd.conf - Main server configuration, anything site wide that
pertains specifically to how you want the server to behave.

update.conf - Bare minimum for getting the server bootstrapped.  You
want to get this right the first time.  You don't want to change this
file ever, once it is rolled out.  Or you run the risk of getting a
parse error.  At this point your system stops updating.

cf.groups - I use this file to keep organized all the classes. I usually
have a class for each component I wish to automate.  Some components
have scheduled events.  I tie those events to classes.  This way it make
it easy to use cfrun to kick off an event.  (ie. I want to run a nessus
scan now instead of tonight)

cf.snav - You can call this what ever you want.  But this is the main
file I use to define variables and import files based on cf.groups.  I
should mention that in cfagent.conf I important cf.groups then cf.snav.

cf.<component> - I then have a file for each thing I am trying to
automate.  For each I have a cf.bigbrother file.  This works to automate
anything involving big brother.

cf.<platform> - It might be useful to have a platform for the variation
of different binaries.  I typically use $(rm) or $(cp) for any binary in
a shellcommand action.  I have since moved to a cf.binary file that use
`which rm` to define $(rm).  Make adding new platforms easier.  Some
might consider this dangerous since it relies on PATH.  But what is your
tolerance for risk?

Hope this helps.  I might take some time to outline this further.  I
will try to detail some of the internals.  I will try to put it into an
article and get it published onlamp.com.  Or I will just dump it on
pearcec.com.

On Fri, 2004-07-30 at 10:02, Chip Seraphine wrote:
> I have a theoretical grand plan involving importing files that control 
> specific fucntional areas, but in practice I find myself organizing things 
> principally to appease order-of-operations issues.   Debugging tends to make 
> my setup drift from 'proper' toward 'pragmatic'.
> 
> On Thursday 29 July 2004 20:47, Russell Adams wrote:
> > On the topic of splitting up large configs into smaller pieces, can
> > anyone share any method of organization that has worked well for them?
> > 
> > Lastly, has anyone other than me dabbled in using Arch with cfengine
> > configs, including file sharing from the central server?
> > 
> > -----------------------------
> > Russell Adams
> > RLAdams@AdamsInfoServ.com
> > http://www.adamsinfoserv.com/
> > 
> > 
> > _______________________________________________
> > Help-cfengine mailing list
> > Help-cfengine@gnu.org
> > http://lists.gnu.org/mailman/listinfo/help-cfengine
> > 
-- 
Christian Pearce
http://www.commnav.com
http://www.perfectorder.com






reply via email to

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