Forum: CFEngine Help Subject: Re: (addendum) How easy/simple is cfengine? Author: mikesphar Link to topic: https://cfengine.com/forum/read.php?3,24353,24374#msg-24374
Mike Svoboda Wrote: > 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.. What I would love to see would be something akin to a real "curriculum" of a course designed to teach someone how cfengine works and how to use it properly. Just like when teaching programming or other complex concepts, I imagine it would start simple, introduce very basic common scenarios and how to handle them while also using those examples to teach understanding of how the system works. And as much as possible using real-world examples of promises that are the most common ones people start new cfengine deployments with. And each lesson keeps adding to the previous one to ultimately build a well-designed "proper" initial cfengine deployment. For example, the first lesson would simply be how to install and configure a cfengine master and policy server that does nothing but maintains cfengine itself. It's demonstrated how the cfengine agent requests and receives updates from the policy server, how the authentication works, etc. No actually system maintenance is done yet. Then the student is walked through breaking the policy, to see and understand the result of syntax errors in promises and how failsafe is used to recover. Maybe even break the ssh key authentication (say the client is reinstalled and the ssh key is lost) to make sure the student understands how to detect that and how to fix it. (I can't tell you how often this is what I'm called in to fix when cfengine "breaks".) Then, the next lesson might be a simple file promise. Distributing /etc/motd and promising appropriate permissions or something otherwise non-destructive that can be tinkered with and demonstrate concepts like time-based vs checksum based. (Don't even get into templating yet.) Expand to use of classes to distribute different source files (motd.redhat vs motd.debian or motd.32bit or motd.am/motd.pm/motd.weekday/motd.December or whatever). You could go crazy here with examples showing off lots of different types of classes and how to combine them in various ways and how they apply to a cf-agent client, all related to a very simple file promise that can be demonstrated easily and safely. Maybe then an example promise for making sure a process is running and restarting it if not. cf-serverd or ntpd might be good choices. Have the student kill the process and observe cf-agent restarting it, etc. Then the ball might really start rolling with an example of fully managing a service, ntpd is probably a good example. Walk the student through all the best practices of the simple approach to managing such a service. You'd start introducing a lot more promise types here, as to truly fully manage the service you're going to need promises like: ntpd is installed, ntpd is running, ntpd is configured to start a boot, ntpd has the correct ntp.conf file, if the ntp.conf file has changed ntpd is restarted. Now is a time to start talking about best practices for separating things into different promise files, bundles (if they haven't been gone into already), etc. Other lessons might involve the common types of problems that new cfengine users tend to get "wrong" from the cfengine point of view. Typical solutions people just attempt to implement imperatively through shellcommands or scripts rather than thinking through the cfengine way to approach those solutions. Walking through a best practice example of properly setting up and maintaining source control for policies would be another great one. I know this is something that everyone is going to have different ways of doing, but for a newbie, just walk them through *one* way, using git or svn or whatever, and best practices for that. Someone without time or care to have an opinion about the tool can just use the example, while someone with expertise in something else should have the understanding to adopt the example solution to their needs. I'm kind of rambling here but I really do think this is the kind of thing cfengine or any other complex software product really needs to ease and accelerate adoption. Extensive reference guides and how-tos are critical for more experienced users. But for someone trying to learn, a lot more hand-holding through the early phases will go down so much more smoothly. The worst situation is when someone makes bad choices early on in a deployment based on limited understanding or a flawed intention to just "get things done" expediently that become too much work to safely redesign out later. (Something the current cfengine deployment I have inherited is rife with.) Too often the end result of that is that when a new person comes in to take over, they can announce that the real problem is this terrible tool, and that they could fix all the problems by replacing it with puppet/chef/or whatever pet solution they happen to understand better and can build from the ground up. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
