On Fri, Aug 5, 2011 at 10:59 AM, Richard Taylor <span dir="ltr"><<a href="mailto:richard@richt.co.uk">richard@richt.co.uk</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

                <div>I wrote conman (sorry it's a bit rough round the edges), it was out of frustration for the ridiculous learning curve to get puppet or chef working for small-ish deployments.</div></blockquote><div>
<br></div><div>This is what I've been doing lately.  My tips would be</div><div><br></div><div>(1) don't bother with the agent, at least initially.  Write a manifest on the local machine, call it using "puppet apply" on the local machine.  When you've got to grips with the config language and have something running that works locally, your motivation for figuring out all the ssl certificates will be that much greater.</div>
<div><br></div><div>(2) if your dns is in any way weird or less than perfect (often the case if you're e.g. creating new VM images, or if you have multiple network interfaces, or for all kinds of other possible reasons), puppet will have trouble working its hostname out.  You can force it to use a specific hostname for matching "node '<a href="http://foo.example.com">foo.example.com</a>'" clauses by passing "--certname <a href="http://foo.example.com">foo.example.com</a>" to "puppet apply".  You will get some warning messages, which look like they are from other parts of puppet which want to know the hostname for other reasons, but it works anyway.</div>
<div><br></div><div>(3) the "package/file/service pattern" described on the cheat sheet and on the puppetlabs site is really worth absorbing</div><div><br></div><div><br></div></div>