On 3/31/10 1:15 PM, "Justin Lloyd" <jll...@digitalglobe.com> wrote: > I was approaching the problem from the opposite perspective, trying to > keep everything within the Cfengine policy and not depend upon an > external cron job. Ideally, I'd like to be able to eliminate the need > for any non-standard cron jobs and have Cfengine handle everything. In > the albeit unlikely event that the cron job disappears on one of your > systems and the system is restarted, then it won't know to restart > Cfengine.
Of course, if you are not careful, you can almost extend this type of argument indefinitely... Implement X to take care of problem Y, but if X is removed or just munged a little Y won't happen as intended... So implement X', and continue finding edge cases. > As I was thinking through this reply and trying to anticipate further > rebuttals to my approach, I started to realize that maybe going with the > simpler cron approach might be worth the small risk I mentioned above. > One example that came to mind is our near-future reimplementation of > standardized syslog-ng throughout our environment. My original idea was > to abstract and parameterize my SMF service management bundle so I could > use it for cfengine, syslog-ng, etc. But I realized I could just have > Cfengine manage the syslog-ng process (I've not used process promises > yet) rather than creating another Solaris service. It does seem like a > much cleaner approach in many ways. And one non-standard cron job isn't > too bad if it keeps the policy and environment simpler. Exactly... I think it's important to do the cost benefit analysis. Cron is "good enough" for many cases. An important thing (I think) from this discussion is to monitor for symptoms which indicate this edge case is present (e.g. missing cron, cfengine not running). If you already have something like nagios reporting this condition, you'll ultimately know if someone removes the cron (or cfengine doesn't run for whatever reason). We go a step further and have each host run what equates to a nightly "ping" into our inventory database... We can run reports showing "stale" servers that haven't ran cfengine as expected. This also helps us ensure the recorded OS version, package manifest, etc. are up to date in our database. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
