Or perhaps in the case of VPS's, do you just clone a generic setup and use that same image for multiple slices/nodes?

And for the record I personally use Debian Lenny and have been doing manual configuration on my VPS slices.

  • "What doesn't work? You, with the install disk, making with the clickey..." --Adam Jacobs, VelocityConf 2011
    – gWaldo
    Jan 6, 2012 at 2:25

7 Answers 7



  • I don't disagree with using puppet, but I think it's more useful once the machine is installed, so it should be a part of your install image, right? Dec 12, 2009 at 22:08
  • yes, kickstart to install the system and puppet to manage the configuration
    – Daniel
    Dec 12, 2009 at 22:13

If you're running a RedHat based machine, then you definitely want to use kickstart.

On Debian system, you can use the Fully Automatic Installers.

If you're in the "automagically configure my machines", then part of your install image should be puppet, because once the machine is installed, you'll need something to control it.

  • 5
    +1 for puppet, (and +1 for Kickstart). Dec 12, 2009 at 22:46
  • 1
    Replace one-off kickstarts with cobbler and you've got yourself a winning combination.
    – Scott Pack
    Dec 13, 2009 at 0:46

I so rarly build a new physical server that I install them from the CD/DVD.

For virtual machines I have a set of templates based on the needed OS, when then gets cloned and configured automatically via VMware.


Puppet + Cobbler for Redhattish systems and some debian-based stuff that's more or less experimental. But definitely puppet based on some very generic kickstart (or equivalent) with your puppet configs stored in SCM and a copy of the installation repositories as they were when you initially configured the box.


Unless you are only managing three servers you absolutely have to automatically configure servers. Even with only a few servers you would be well-served to invest the time to automatically configure them as well. The key thing that scripted or automatic configuration gives you is repeatability. If you don't exactly document your setup process via kickstart, etc. you have very little chance of setting the server back up the same way next year if the hard drive dies. Or say you want to make your network more robust by duplicting servers. If you automatically configured the first machine, setting up the matching second system is trivial.

I am personally a big fan of using a pxe boot server plus clonezilla. Every server or workstation is set to boot off the network via pxe by default. Then, the pxe boot menu includes the option to restore the server from scratch via clonezilla (you should definitely password protect that option!).

My knowledge is in the unix/linux world but I think there are similar tools in the windows world. The idea is to minimize the amount of setup required on a virgin machine. With this configuration all you need to do to a fresh system is set the bios to pxe boot and put it on the network.


I've been testing Puppet + foreman. Foreman takes all the awesomeness of puppet and adds in provisioning for new systems. I've only used it to deploy & configure centos but it comes with templates for debian, ubuntu, solaris and fedora.




Completely optional, but what I did at my last gig was create a base image that talks to my private Chef server (slightly different process than the hosted service, but not bad), make it a template, and se the template to spin up new base-image instances! Configure basic stuff like ssh and ldap and additional packages you always want installed to go in the base Chef config, and more roles & recipes to be added later!

Not the answer you're looking for? Browse other questions tagged or ask your own question.