Hi,<div class="gmail_extra"><br><div class="gmail_quote">2012/12/6 Karl Ward <span dir="ltr"><<a href="mailto:kw1213@nyu.edu" target="_blank">kw1213@nyu.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span style="font-family:arial,sans-serif;font-size:13px">Sorry for the late response, it has been a busy few days, plus my laptop is dying so I've been on borrowed computers while Apple refuses to acknowledge that my system has a problem. </span><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">Puppet is great for system administration primarily because of the documentation aspect. Most routine operations (creating users, setting passwords, installing software, starting services, configuring services) can be done in a Puppet manifest. The major benefit is that the act of configuration becomes self-documenting. You mentioned documentation of system configuration as a separate step--yes, documentation is easy, but it's usually the step that gets skipped. </div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">As for the need for a Puppet server, I agree that setting up a Puppet server is not how you want to spend your time. However, you don't actually need a Puppet server at all. Many large sites use Git or another repo system to store the Puppet manifests, and instead of contacting a server, each managed node looks at its own local copy of the Puppet manifests. Each node periodically does a repo pull and keeps its own copy up to date. The only central server involved is a repo, which you probably have anyway. This practice is pretty common at very large Puppet sites (I've heard it is what Google uses, for instance). We don't do this yet, but as soon as we have nodes on a public cloud we will. Using Git to distribute Puppet manifests is described in one or more of the Puppet books, and a somewhat old post about it is online here: <a href="http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control" target="_blank">http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control</a></div>
<div class="gmail_extra"><div><div class="h5"><br><br></div></div></div></blockquote><div><br></div><div>True, one recommended way of doing puppet configuration is to have a github repository and pull it directly on the node (+cron job). That is quite easy to setup.</div>
<div><br></div><div>Concerning the usage of puppet itself, I think it is worth the effort, if you have more than 2 instances to setup. I think <a href="http://ocaml.org">ocaml.org</a> will be more than one instance.</div>
<div><br></div><div>The benefits are not immediate but the long term is better.</div><div><br></div><div>Although, when dealing with configuration setup, I strongly recommend using Augeas. Setup a private github repository (server configuration should not be public) and we can start putting thing here. I'll probably start with configuration of the <a href="http://forge.ocamlcore.org">forge.ocamlcore.org</a> instances, just as an example...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote">On Sat, Dec 1, 2012 at 7:47 PM, Ashish Agarwal <span dir="ltr"><<a href="mailto:agarwal1975@gmail.com" target="_blank">agarwal1975@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi,</div><div><br></div><div>I'm looping in our awesome sys admin Karl, who is our local puppet master. Karl, not sure there is enough info below for you to give input, but maybe you can ask questions or provide general advice.</div>
<div><br></div><div>Just yesterday, Karl offered to do pretty much anything for the <a href="http://ocaml.org" target="_blank">ocaml.org</a> infrastructure if it somehow involved him working on a Rasberry Pi cluster. Anil, can you hook us up?</div>
<div><br></div><div>-Ashish</div><div><br></div><br><div class="gmail_quote">On Sat, Dec 1, 2012 at 1:29 PM, Anil Madhavapeddy <span dir="ltr"><<a href="mailto:anil@recoil.org" target="_blank">anil@recoil.org</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been playing around with Puppet this weekend at last, and I'm less<br>
convinced we really need it. I'm putting the mail server in a VM running<br>
Postfix, and it doesn't seem very necessary to have all the complexity of<br>
Puppet itself when each of the services is essentially running just a<br>
single daemon (email or web or sync, etc).<br>
<br>
So I'm inclined to revert back to the usual XenServer way. Create a<br>
Wheezy VM, add a dssh key to regularly apt-get update on all of them, and<br>
create clones in XenServer for each of the services. This is pretty easy<br>
to back up and document. We can still host your Puppet in a VM too, but<br>
not for the really important services like e-mail, which I'd prefer to<br>
keep configured in a simpler way.<br>
<br>
Thoughts?<br>
<span><font color="#888888"><br>
-anil<br>
</font></span></blockquote></div><br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Karl Ward</div><br>
</font></span></div>
</blockquote></div><br></div>