On Mon, Feb 22, 2010 at 2:53 PM, Paul DiSciascio <the...@bytemonkey.net> wrote: > I'll try to keep this from getting too religious: >
You fell victim to one of the classic blunders - The most famous of which is "never get involved in a land war in Asia" - but only slightly less well-known is this: "Never ask a broad configuration management tool question and hope religion doesn't get involved." :-) (Sorry, couldn't resist) > There is no way that root ssh access is going to fly in my environment (even > with forced commands), which means I'd be looking at piecing together > something that uses ssh and sudo to accomplish this. This has the obvious > drawback of now being dependent on the accounts of the user being in good > standing on all of the servers we're trying to access. For myself, this will > not be an issue, but if this is something that I'm looking at handing off to > junior admins or an operations team, this may be a very different story. > Then create a non-uid0 service account that is locked down to only be accessible from your bcfg2 server and change the command="" in the authorized_keys to invoke bcfg2 via sudo. If running an always-on agent is a requirement for your CM model, then bcfg2 is likely not the right tool for you. The method I pointed out is the best and safe way to do it as described by the bcfg2 folks. You might want to look into cfengine instead. Travis -- Travis Campbell hcoy...@ghostar.org _______________________________________________ Discuss mailing list Discuss@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
