Re: Configuration File Organization

[Russell Adams]

Arch - The revision control system.

Russell

On Fri, Jul 30, 2004 at 12:19:43PM -0400, Christian Pearce wrote:
> 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
> 
-----------------------------
Russell Adams
RLAdams@AdamsInfoServ.com
http://www.adamsinfoserv.com/