Our filesystem layout (albeit on cf2, so no "bundles" or anything...)
./cf.strategies - pseudo-random class definitions ./cf.classes - global classes ./cf.control - global macros and settings ./<SITE>/cf.siteclasses - site-specific classes ./<SITE>/cf.sitecontrol - site-specific macros and settings ./cfagent.conf - ties all the above together ./cf.<something> - policy file for <something>, like "syslog" or "printing" or "snmpd". ./cf.runconfig - ties all the above together in cfagent.conf, the include order is: cf.strategies cf.siteclasses cf.classes cf.control cf.sitecontrol cf.runconfig Since cf.runconfig is itself an include, it guarantees that all of the cf.<something> policy files have all of the macros and classes ready to go. cf.siteclasses goes before cf.classes so that some global settings can be toggled by a site-specific flag being set. For example, there may be a PrepModule in cf.classes we don't want to run at a certain site. cf.sitecontrol comes *after* cf.control so that some global macros can be overridden by a site. For example, the root password may be different at one site but the same at all the others. Paul Krizak 7171 Southwest Pkwy MS B200.3A Senior Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Silicon Design Division Fax: (512) 602-0468 On 02/17/10 17:18, Justin Lloyd 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, e.g. > > 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
