* site.cf
I use this to set global classes that control what actions needs to be
taken in a particular environment/server. I also set global vars in here,
such as the slist which is passed to bundlesequence - that way all the
stuff that varies depending on what classes are defined is consolidated in
a single spot. If I need to add a service to a particular server (or group
of servers) it's done in here.
* promises.cf
Pretty standard, just controls the default behavior of the agent, server
and executor.
* update.cf
Bootstraps cfengine, also has a bundle called 'checks' that defined classes
for sanity checks that are used in 'abortclasses' in promieses.cf and
failsafe.cf
* failsafe.cf
Against pretty standard, just runs the bootstrap bundle from update.cf
(only requires itself and update.cf to run so I can always bootstrap even
if other files have errors)
* library.cf
As per normal
* runagent.cf
has a special control body for the executor, to run cf-agent with certain
classes defined. This way I can use cf-runagent to trigger a specific
action, like killing off a runaway process.
I consider all the above files to be kind of 'base' files required for
cfengine to run. I have a directory 'roles' for specific services that may
or may not be applied to different servers. They are generally quite simple
and dont do any class-based actions: if something needs to change based on
a class I will set a global variable in site.cf based on a class, and get
the role to refer to that variable. I have one .cf file per bundle
implementing a role.
My current .cf file structure looks like:
$ find . -name '*.cf'
./roles/rtsystem.cf
./roles/autodrm.cf
./roles/localise.cf
./roles/seedlink.cf
./roles/nagios.cf
./roles/services.cf
./roles/sysconf.cf
./roles/webscripts.cf
./testbundle.cf
./failsafe.cf
./promises.cf
./update.cf
./runagent.cf
./library.cf
./site.cf
./testsite.cf
./cleanup.cf
I don't bother getting all religious about naming conventions/standards, I
think there are more important things to consider like the overall design
and how well it works in an operational
On Feb 18, 2010 10:18am, Justin Lloyd <jll...@digitalglobe.com> wrote:
Hi all,
I'm curious about what good practices people have developed for
organizing their local configuration files, bundles, bodies, special
files, etc. as well as naming conventions for bundles, bodies,
variables, etc. to prevent conflicts with defaults. I checked
www.cfwiki.org but it doesn't seem like that's seen much attention
(other than from spammers) in a while.
Here are some thoughts I'm putting into my initial pilot implementation,
but I'm always looking for approaches that may better suit my
environment. I'm using the dg_ prefix since for things specific to my
company.
* Put all custom global classes and variables in a "dg" common bundle in
dg_config.cf
* Put all custom bundles for use in bundlesequence in dg_bundles.cf
* Put all bodies and non-bundlesequence bundles in dg_library.cf,
leaving library.cf untouched.
These first two could grow quite large so I'm wondering if I should
eventually find a logical way to split them into appropriate smaller,
more manageable files.
* Clear and descriptive names, eg
bundle agent cleanup_cfengine_outputs_directory
> Delete old files from /var/cfengine/outputs.
bundle agent update_local_sudoers_file
> Pull the latest sudoers file from a master server to a
platform-dependent location.
bundle agent create_solaris_globalzone_files
> Create /usr/globalzone in all Solaris global zones that only
contains $(sys.uqhost).
body copy_from secure_copy_with_backup(filename, hostname)
> Based on library.cf:secure_cp, retrieves a file, backing up the
promised file first.
bundle edit_line enforce_one_line_file
> I don't like this name but I can't think of a better one. It ensures
a single string
> parameter is the only line in a file and is used by the above
globalzone bundle.
Under Consideration:
* Prefix all custom bodies and bundles with dg_. Seems a little clunky
but would enforce a "namespace".
So please feel free to provide constructive criticism of my thoughts
above and add other good practices you may have come up with.
Thanks,
Justin
This electronic communication and any attachments may contain
confidential and proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient,
or an agent or employee
responsible for delivering this communication to the intended recipient,
or if you have received
this communication in error, please do not print, copy, retransmit,
disseminate or
otherwise use the information. Please indicate to the sender that you
have received this
communication in error, and delete the copy you received. DigitalGlobe
reserves the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
