Mike, Ok, I see, the /etc/classes directory is more of a semaphore mechanism for emergency external control of how Cfengine will behave on a particular system without having to actually modify the policy. IMHO, that's actually an elegant solution to the 3 AM emergency problem, eliminating a lot of potential policy changes when one is not fully awake. :)
We use RT's Asset Tracker module as our asset database (ATDB), so we could add certain permanent classes to a custom field there and have Cfengine on each host retrieve that through our existing AJAX API, caching it locally for times when that database is unavailable. Having such information in the CMDB (AT, LDAP, etc.) would certainly make the types of queries you mention easier, since Cfengine cannot currently do that (to the best of my knowledge). Data quality control is high on our radar. I want to have Cfengine automate the population of the ATDB as much as possible to minimize the possibility of human error in data entry. Our IS developers are working on this from a number of angles as well, creating tools and interfaces to minimize the need for such human input. Thanks, Justin -----Original Message----- From: Mike Hoskins [mailto:micho...@cisco.com] Sent: Tuesday, February 02, 2010 2:00 PM To: Justin Lloyd; Tim Cutts Cc: help-cfengine@cfengine.org Subject: Re: Team-based Cfengine Management On 2/2/10 12:27 PM, "Justin Lloyd" <jll...@digitalglobe.com> wrote: > 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. One thing I didn't make clear in my last post... /etc/classes is still considered a bit of a hack. If there is something that must be supported long-term, it would ideally be added to policy (and our documentation and training enforces this). So /etc/classes is not meant to permanently override host configuration. It's just an option for power users (the paged admin at 3AM) when they really need control, or an easy stop gap while integrating new hosts (merged with Company X and got N new roles to think about?). We've found having these sort of flexible options make adoption of cfe easier for all. In terms of monitoring staleness, it should be fairly easy to write a nagios plugin that checks for /etc/classes files > threshold age. Beside this, we also have a system similar to what you describe... Our inventory database can return shell style output to queries received over the web. I highly suggest this approach... Once it was available, everyone started using it. The ability to run a single lightweight query and receive "all hosts of role X" or "all DEV hosts of role Y" in a fairly automated (e.g. The database is updated as part of provisioning new machines, not as manual edits to flat files) saves a lot of time. This sort of database is where more permanent role definitions belong (minimal hosts should eventually transition to a documented role), and we have modules which derive class information from the database (with caching of course, so the database can go down and on one cares...data just gets stale). It's good to see different minds progress in similar directions... I just wanted to encourage you to keep exploring this angle, and focus on making your host configuration data distributed (essential data should be available to each host with caching), centrally managed (through a web UI, SQL query, etc.), and query-able (harder if you don't use a database). We've also found that building web UIs on top of such data helps enforce constraints (e.g. A MAC address shouldn't be formatted like an IP, a FQHN should contain at least 2 dots, etc.). Otherwise, data quality may suffer as teams/number of hosts grow (more typing, more typos). 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
