On Thu, Apr 25, 2013 at 1:58 PM, John Stoffel <j...@stoffel.org> wrote:
> This has been the big issue keeping me from deploying configuration > management at $WORK, because I have to convince all the rest of the > team that it's really worth the hassle and change in mind set. > > For me, supporting Solaris 8/10 Sparc/x86_64 systems and a bunch of > RHEL 3/4/5 (mostly 5 now) x86_64 compute nodes, the attraction of > cfengine has always been that it's self contained. I can just drop > the cfengine binaries in place and away I go. > > Chef, puppet, etc all seemed to want me to first install python or > ruby or something else that wasn't part of my base systems. This has > changed over time, and esp as I've finally moved away from Solaris 8 > in a big way. > > So looking at Salt and seeing that it requires Python is still a > gotcha, but possibly one I can deal with now. But again, it's all > about getting a system in place which I can encourage the rest of my > team to use without causing them undue pain. Yes, sometimes you need > to force the change, but it would be better if I didn't have to. > > This would be a good discussion to have, and one I keep wanting to > have. > > John Newer versions of Chef actually embed everything; just drop and go. They call it the omnibus versions. It's great for not having to deal with the headaches of ruby versions... you can still install it via gem if you want, but IMO the omnibus versions are a heck of a lot simpler to manage. Especially for the server. Also, running knife ssh with splay seems to be just fine in my experience. The concept of "every node must have this command executed within the same 5 second time window" seems very broken to me. That's certainly not an architecture that I'd want to support personally. I do miss the "I just pushed this change, tell me who isn't happy about it" concept of mcollective, but yes, it was more trouble than it was worth to set up and try to function. After getting the base system to work on our legacy environment, we ended up giving up on having it control puppet and went back to our custom python script that forked multiple ssh processes instead... much like I'm using knife ssh now in the current platform. "Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients." This is factually incorrect on two counts. The crypto negotiation for knife ssh is not done on the Chef server but instead on the knife client. However, regular Chef client->server communication is done over HTTP(S), depending on how you've configured your settings. --Morgan
_______________________________________________ Discuss mailing list Discuss@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
