Mike, I definitely want to have a form of documentation around our Cfengine and overall Unix infrastructure. I plan on using our MOSS server for just that sort of thing. Wikis, lists, blogs, forums, etc. will be invaluable in improving our documentation and communications as I overhaul and enhance much of our Unix infrastructure.
I've not thought it through completely, but I really like the /etc/classes directory idea. I had an idea of using an /etc/digitalglobe.conf shell-style file that could be parsed or sourced by Cfengine, shell scripts, etc. and could contain comments explaining each entry (e.g. RUNTIME=gold, FUNCTION=pp). But OTOH, /etc/classes files could contain descriptions of why they're there. OTTH, I could have a variable in the conf file that simply contained additional arbitrary classes, similar to your minimal_host class. And a single file per host is easier to revision control. This will take some thinking. Either way, however, such files would generally be outside of Cfengine's remit, so there's the question of how to manage those files and prevent them from being inadvertently changed or deleted. Thanks, Justin -----Original Message----- From: Mike Hoskins [mailto:micho...@cisco.com] Sent: Tuesday, February 02, 2010 11:59 AM To: Tim Cutts; Justin Lloyd Cc: help-cfengine@cfengine.org Subject: Re: Team-based Cfengine Management On 2/2/10 12:08 AM, "Tim Cutts" <t...@sanger.ac.uk> wrote: > Finally, if there really are some machines which need to be configured > by hand (something I resist strongly) we have a minimal_cfe class > where the vast majority of our cfengine policy is skipped, and only > the bare essentials are checked. We do the same. Anyone (with root of course) can touch /etc/classes/minimal_host (/etc/classes is a convention we adopted locally for interfacing with cfe, after seeing it done elsewhere), which in turn defines the "minimal_host" class, and skips all but the essentials. As to docs, we found wikis work great when maintaining communal documentation. An initial education in the form of a broad overview presentation, with a pointer to the wiki (and urges to fix what's broken while reading) seems to work. The biggest problem was stale docs as you mentioned... As docs grew and new ones were created, we quickly needed more powerful search. We currently use a Google appliance for that, and it does pretty well. That said, having a good way to "retire" docs from the start (maybe move them to a history web) would be good for anyone going the way of wiki. Some times communal systems like wiki make this worse -- you need good communication, or people will forever block on bad docs waiting for someone else to update them. :) 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
