On Mon, 30 Apr 2012 16:24:52 +0200 (CEST) msvob...@linkedin.com wrote: n> Giving developers root access to development machines is a known evil. n> I would rather not give root access to people who aren't n> administrators, but in reality, this doesn't happen.
n> Folks that run QA, performance environments, etc. want to be able to n> do basic administration to infrastructure they "own." Cfengine still n> runs on these machines, because ultimately, we still own them as well. OK, I would recommend simply splitting your policies between your environments. Keep common files in a shared place and each environment can have its own specific implementation. n> I haven't looked at cfsketch yet, but I have seen some of the n> discussion happening over on the design center. By splitting n> poilcies up to a per-host level, I just see the huge additional load n> in Cfengine administration. The power of using automation is that n> you write policies as generically as possible and bring your entire n> datacenter into convergance. If you split configuration up into n> small identicial chunks, administration overhead goes way up on where n> changes need to be made in policy files + complexity. I dont think n> this is the right approach.. I wasn't suggesting to split up per host. There are three kinds of things you can split up: 1) common libraries. Usually there are no secrets here. 2) implementation bundles. These usually need to be split between environments (or colocation, or owner group, etc), keeping some shared and some not. If you keep your code in Git, you can use Git's merge/branch support to easily keep multiple branches of the main configuration, so common changes flow down to each branch and coexist with the local changes. 3) bundle configurations. This is a cfsketch concept, where you can "activate" a sketch with specific parameters. So maybe on your QA environment the XYZ sketch runs with user=foo but in your DEV environment user=bar. You can split these per host, per environment, per colocation... same as (2). But because they are pure data, splitting them up is a much more "meta" problem that doesn't require you to rewrite policies. So, if your bundles are designed to be configurable, you can make this a configuration problem instead of an implementation problem. n> This way, it doesn't matter what your client can do with root n> privledges on the client. He can't decrypt /var/cfengine without n> authentication to the master policy server [after the first time]. If the server provided a decryption key that's only valid within a limited time and the client wiped it as soon as it was used, this could work, but it would be a tremendous headache and fairly easy to defeat by capturing the decryption key. Ted _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
