Feel free to ping me if you have any questions, or better yet, ping the mailing list for the NY Puppet UG: <a href="http://groups.google.com/group/puppet-nyc">http://groups.google.com/group/puppet-nyc</a><br><br><div class="gmail_quote">
On Sat, Apr 18, 2009 at 7:17 PM, Matt Juszczak <span dir="ltr"><<a href="mailto:matt@atopia.net">matt@atopia.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Setting this up on two test servers and seeing how it does :) I had just read before that it had serious limitations working with multiple operating systems.<div><div></div><div class="h5"><br>
<br>
On Sat, 18 Apr 2009, Brian Gupta wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
Matt,<br>
<br>
I'm gonna talk about puppet since that's what I know. With puppet, since you are running a centralized configuration<br>
management system, you can keep your config files in puppet.<br>
<br>
Puppet understands a number of resources types. These include:<br>
- Files<br>
- Users<br>
- Packages<br>
- Services<br>
- Cron<br>
- sshkeys<br>
<br>
and many more.. See here for a relatively full list: <a href="http://reductivelabs.com/trac/puppet/wiki/TypeReference" target="_blank">http://reductivelabs.com/trac/puppet/wiki/TypeReference</a><br>
<br>
In addition.. Puppet can exec arbitrary code in the event that what you need to do is not yet supported.<br>
<br>
Puppet let's you structure nodes and classes in an object hierarchy. Very cool when work with related machine types.<br>
<br>
I'm curious how you found puppet limited? (Particularly as compared to your SVN proposal).<br>
<br>
Thanks,<br>
Brian<br>
<br>
On Fri, Apr 17, 2009 at 11:01 PM, Matt Juszczak <<a href="mailto:matt@atopia.net" target="_blank">matt@atopia.net</a>> wrote:<br>
That's what I'm trying to figure out. These two questions sort of intertwine themselves. If we decide to go<br>
the "ports scripted" route, we'll most likely have scripts like this in SVN:<br>
<br>
./webserver-setup.sh -h<option1> -i<option2><br>
<br>
which will basically do a cvsup /etc/ports-supfile, install necessary ports (all the same version of course),<br>
install php, etc. Then, we'd push the configuration files via svn as well.<br>
<br>
If we decide to go a package route, we might even put the packages in SVN, so that you can "check out" the<br>
repository of packages.<br>
<br>
I've looked at puppet, and I've looked at CF engine: puppet seems limited, and CF Engine seems complex.<br>
Seems like it's a pick your poison.<br>
<br>
<br>
On Fri, 17 Apr 2009, Brian Gupta wrote:<br>
<br>
Not to start up the cfengine vs puppet debate again, but one question. How do you plan to handle<br>
package installation?<br>
That's one thing where CMS can really help.<br>
<br>
-Brian<br>
<br>
On Fri, Apr 17, 2009 at 1:42 PM, Matt Juszczak <<a href="mailto:matt@atopia.net" target="_blank">matt@atopia.net</a>> wrote:<br>
We're launching an entirely new setup across FreeBSD boxes - about 50<br>
servers total. I have two things which I'm still somewhat debating, and<br>
thought I'd get a second opinion.<br>
<br>
First, instead of using CFEngine to manage the boxes, I was thinking of<br>
using an SVN-based setup. Each server would checkout their appropriate<br>
files via SVN, and I would "trigger" each server when it needs an update<br>
via config files that would be fetched often via either ftp or svn. This<br>
is neat and flexible, but not as complex as CFEngine. Thoughts?<br>
<br>
Second, I'm trying to decide how to do packages. Across the 50 servers<br>
we'll have about 6 or 7 different hardware sets. Some will be Dell, some<br>
IBM, etc. Most will be 64 bit boxes (to address larger memory ranges).<br>
Should I set up a single server for each class (and do make package to<br>
create packages for each box), or should I just compile ports from source<br>
on each box, verifying that I'm installing the same package version each<br>
time (which will allow each box to take advantage of the benefits of its<br>
specific hardware).<br>
<br>
Those are my two questions, and I'd appreciate any input anyone can<br>
provide. Thanks!<br>
<br>
-Matt<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@lists.nycbug.org" target="_blank">talk@lists.nycbug.org</a><br>
<a href="http://lists.nycbug.org/mailman/listinfo/talk" target="_blank">http://lists.nycbug.org/mailman/listinfo/talk</a><br>
<br>
<br>
<br>
<br>
--<br>
- Brian Gupta<br>
<br>
New York City user groups calendar:<br>
<a href="http://nyc.brandorr.com/" target="_blank">http://nyc.brandorr.com/</a><br>
<br>
<br>
<br>
<br>
<br>
--<br>
- Brian Gupta<br>
<br>
New York City user groups calendar:<br>
<a href="http://nyc.brandorr.com/" target="_blank">http://nyc.brandorr.com/</a><br>
<br></div></div>
[tooltip_18px_18px.png]<br>
<br>
</blockquote>
</blockquote></div><br><br clear="all"><br>-- <br>- Brian Gupta<br><br>New York City user groups calendar:<br><a href="http://nyc.brandorr.com/">http://nyc.brandorr.com/</a><br><br>