I agree. I don't think that people object to it--in fact there have been quite a few people who have posted very detailed examples to the list (or posted links to websites that have them). The issue (IMO) is one of security. By it's nature, posting production policies will expose information about a live enironment, and this could be of value to an attacker. Consider that if, for example, you use CF3 to manage /etc/password directly, and your have password hashes in your .cf files. Posting that file to the mailing list is probably a bad idea...
The community also used to have cfwiki.org as a place to post snippets, and it was quite active for some time. However, it fell victem to spambots and has been taken offline. In an attempt to replace it, I've created cfengineers.org (also a wiki), and I'm quite happy for people to post snippets and full-blow examples. But perhaps we need something more like pastebin.com? On Sat, Dec 17, 2011 at 12:19:59PM -0500, Mark Burgess wrote: > >Sharing policies is not a taboo subject. It is just something that few people >seem to be willing to do. We can only keep trying to offer the right forum. > >M > >On 12/17/2011 05:54 PM, Mike Svoboda wrote: >Hey Mark > >The most difficult time I had with Cfengine was going from nothing, to having >network transfers working. Once I understood the concepts of failsafe.cf / >promises.cf, things started to make sense and building upon that base >configuration was pretty straightforward. I know that you guys are shipping >sample configs now with the source code. What I would suggest, is to create a >new "users guide" that went through step-by-step and line-by-line to describe >what exactly was happening in those basic configs and why.. > >Then, since "sharing policies" is such a taboo subject for whatever reason (we >all really need to work on sharing some of the best / coolest things we're >using Cfengine for) — actually include in that base configurations some >policies to do stuff. Not just the unit tests. Lets show snmpd or ntpd being >configured and daemons bounced. Show command execution. Show file >changes. Show file changes raising a class, which is used to execute a >command and then fire a report.. Show an example of how processes / linux >services / packages / template substitution works. We've all submitted some >of our policies to this mailing list. Lets collect a few of those examples >and include them in this new users guide. The RHEL6 services policy and >/etc/sysctl.conf policies that I submitted I think would be a great >introduction as long as they're explained. Once you provide those policies, >then spend a few pages explaining what design decisions happened behind them. > >Once you are able to show policies and explain exactly whats happening in >them, I think the learning curve of Cfengine will decrease. You'll have less >frustrated folks, and I think newbies will start doing things "the right way" >by having Cfengine execute promises as designed. I think a lot of people are >using Cfengine as a distributed platform to launch shell scripts because they >just don’t want to learn / deal with what Cfengine is. If we show policies >and explain the design decisions behind them, the n00bs are going to have a >better experience. > >I wish the recent Cfengine 3 book did this. I begged them not to publish what >they were putting out, because just throwing Cfengine policies / config is >worthless unless there is some meaningful discussion behind what this stuff >actually means. > >Thanks >Mike > >From: Mark Burgess <m...@cfengine.com<mailto:m...@cfengine.com>> >Date: Sat, 17 Dec 2011 14:58:59 +0100 >To: <help-cfengine@cfengine.org<mailto:help-cfengine@cfengine.org>> >Cc: "develop...@cfengine.com<mailto:develop...@cfengine.com>" ><develop...@cfengine.com<mailto:develop...@cfengine.com>> >Subject: (addendum) How easy/simple is cfengine? > > >Addendum: > >Sorry again for forgetting the link > > http://www.infoq.com/presentations/Simple-Made-Easy > >It is worth commenting on two ways in which this talk applies to CFEngine, (in >my personal view). > >What I like about the talk is that it is not dogmatic, but poses questions. >The speaker >says that certain things are good and bad, but does not claim that certain bad >things are unavoidable, only >undesirable in a perfect world. CFEngine was needed because we don't live in a >perfect world. > >The talk is about how to limit it to what is "necessary and sufficient" and it >applies to CFEngine at two levels: > >1. the design and principles used by CFEngine for the problem of modelling >configuration > >e.g. CFEngine's language design seems to satisfy all the speaker's >requirements for simplicity. >With reference to the inline body-syntax we discussed recently in the forum, I >believe inline >syntax complects "what" with "how" by abusing syntax to mis-represent >information (that puts it >strongly to underline the point). > >The speaker suggests that one should *try* to avoid complexity, but CFEngine's >job is to cope with / model >configuration complexity that others have created, i.e. (state) in a simple >way. The disciplines it brings >encourages users to design simplicity, making things more declarative and >non-intertwined (autonomous) and eliminating >imperative threads that complect what with how. > >This complexity cannot necessarily be removed (there is a concept of necessary >and sufficient complexity), >so we should not *oversimplify* a model. > >We try to cope by imposing a simple discipline on the representation of state >by disentangling independent issues >into promise types with body types, using a meta-model called "Promises", >together with the concept of convergence >(persistence of state). > >2. the internal design of CFEngine's implementation. > > >In writing CFEngine 3, the use of the promise model led to considerable >disentanglement of code, compared to CFEngine 2, >though there might still be parts in the lower subsystems that could be >further disentangled. It was necessary >to have a model to understand how to disentangle issues. In my view Puppet >more deeply entangled the modelling >issues, sacrificing simple for easy. > >It would be an interesting exercise for the development team to discuss how >the principles the speaker expounds >apply to different parts of the code. > >Personally, I would have liked to hear what the speaker had to say about >global data/variables, since this is an area where >I noted the speaker's words (paraphrased): "Let data be data, don't hide it >behind an API" with agreement. I read this as >an argument that global data/variables have a valid place in programming, as >long as one copes with the inevitable >changes of state. > >M > >-------- Original Message -------- >Subject: How easy/simple is cfengine? >Date: Sat, 17 Dec 2011 10:09:12 +0100 >From: Mark Burgess <m...@cfengine.com><mailto:m...@cfengine.com> >To: help-cfengine ><Help-cfengine@cfengine.org><mailto:Help-cfengine@cfengine.org> > > > >Mikhail, one of our very brilliant developers, recently brought this >talk to my attention. I just had time to look at this and it is very >good. The talk is a most excellent discussion about making choices about >easy versus simple in software. I recommend everyone to watch this and >absorb its content. > >It is very relevant to the discussion about making CFEngine >easier/simpler, also vis a vis the choices made by Puppet/Chef versus >CFEngine, etc etc - and I very much agree with the speaker's viewpoint. >He does not provide any answers, but he poses important questions: the >best kind of talk. > >M > >PS - Category theory (re: monads) is a form of mathematics, akin to set >theory which is often used to explain anything by pulling the wool over >people's eyes :) > > > > >_______________________________________________ Help-cfengine mailing list >Help-cfengine@cfengine.org<mailto: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 -- Jesse Becker NHGRI Linux support (Digicon Contractor) _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
