// How to start with Puppet (system config management tool): useful links and resources

Puppet is a1) powerful open source tool to automate the configuration of and software management on Unix-like2) operating systems. This posting is a distillate of the resources I collected during my Puppet learning phase. I hope it helps to get an overview about what Puppet can do for you and how to use it (plus providing existing Puppet users some new ideas or tips).

Selected slides and presentations (overview, use-cases, experts, tips)

How to start

Puppet vs. [insert other tool here]

“Masterless” (Puppet without central server)

Source code standards

Source code tools


Useful source code, modules, blue prints, examples, inspiration

Design patterns, module organization strategies

Puppet security (basic thoughts)

Miscellaneous but useful

Starting points to find more useful content:



  • Puppet Labs provides YUM and APT repositories. If you need a newer Puppet version than the one offered by your distro repository, have a look at yum.puppetlabs.com and apt.puppetlabs.com. You might need to tinker a little bit to get a working repository file.
    Fedora YUM repository example:
    name=Puppet Labs - Products
    name=Puppet Labs - Dependencies
  • Puppet is also useful in very small IT environments like e.g. your home network. Even with only one system to maintain, you may want to automate things e.g. for fast re-installation (a central Puppetmaster server is not mandatory, cf. so called “masterless” mode → puppet apply site.pp). Compare the situation with a source code VCS: Thousands of developers are using something like Git for their source code, even if they are the only developer of a specific project. The reason is that Git is not just a tool for “big teams and corporations”. It provides functionality every developer can benefit from. Same for Puppet: even if you got only a few computers to maintain, you may want to automate things plus documenting your setup by doing so. Puppet provides functionality every administrator can benefit from.
IMHO the tool of choice
The current MS Windows support is not really worth to mention.
Don't forget to install rdoc on your system if you want to use puppetdoc --mode rdoc


No. 1 @ 2012/02/05 20:00

Thanks for the great list of links. One minor bone I'd pick is the Windows support is now excellent. Since 2.7.6 and later Windows support is very solid and most of the common types and providers (the ones that are relevant to Windows anyway) work. Cheers!

No. 2 @ 2012/02/06 22:37

Great Stuff! I'm missing from this list mentioning of Puppet Dashboard (http://puppetlabs.com/puppet/related-projects/dashboard/) and Foreman (http://theforeman.org).

No. 3 @ 2012/02/10 09:07

@James Turnbull:

One minor bone I'd pick is the Windows support is now excellent.

Well, I got a divided opinion. It is nice to know that Puppet's most important types and features are working on MS Windows (kudos to you!). I may need this some day e.g. on stand-alone Windows machines. I'm looking forward to manage those boxes with Puppet. :-)

But IMHO the situation is completely different when looking at a MS Windows based corporate network with Domain Controller, no matter if Puppet is working on Windows or not. Feel free to correct me if I'm wrong (as you know, I'm new to Puppet).

First of all, Active Directory/GPO is established and existing by default. An additional component like Puppet does not make the life of a common Windows administrator easier regarding most basic tasks:

  • Windows component configuration
  • Access control
  • File system permissions
  • User management
    • However, a mixed environment (Windows plus MacOS/Linux) would benefit from a Puppet based user management by reducing config redundancy.

Then there are just more general problems on Windows at all. All of them are not Puppet's fault and do affect comparable solutions or tools in the same way. But these issues exist and can't be ignored. There is a massive lack of standardized functionality (official or de-facto) to access/remove/install/configure third party resources and software. But dozens of special-purpose and/or vendor-specific solutions. Therefore, there is no sane way for tools like Puppet to built a good management layer on top of them. At least nothing better than Microsoft's Active Directory with GPOs. Some examples to make clear what I am talking about:

  • Microsoft never established a central internet based software deployment system. Most Windows software is not Open Source, preventing others to create a solution. Therefore, the lack of software repositories and a way to extend them by setting up own software package repos is still a big problem. No widely adopted repository standard = nothing Puppet (or a GPO) can easily use to download and provide applications and non-MS application updates.
  • The lack of a widely used package format (MSI exists but many companies are not using it. Just visit AppDeploy if you don't know what I mean). No widely adopted package standard = nothing Puppet (or a GPO) can easily use to make the software roll-out or removal massively less PITA like it does on Unix-like systems where RPM, APT, or PKG exists.
  • I deployed tons of software on MS Windows:
    • Sometimes you are lucky and the software vendor provides MSI packages. Or you are able to create them by yourself. However, you can deploy them by GPO. Puppet would not make this easier. It does not matter if I add a package by creating a GPO or by writing a Puppet module/manifest.
    • Sometimes there is no other sensible way than writing massive installation or removal scripts to get things done. But you can deploy them by GPO as startup or shutdown script. Puppet would not make this easier. It does not matter if I manage a script execution by creating a GPO or by writing a Puppet module/manifest.
    • The massive lack of Open Source spirit in the Windows ecosystem is leading to software license and DRM hell. Sometimes you just can't automate a stupid activation process of crappy software. No tool can provide a general solution for these problems.
    • Software configuration files are not as common in the Windows world as they are on Mac/Linux. This makes it hard for Puppet to help a Windows admin. IMHO it is more worthwhile to teach yourself how to write ADM templates to control the registry by GPO. Plus – if a software is using config files – modify such files by GPO controlled scripts. Puppet would not make this easier. It does not matter if I manage the script by creating a GPO or by writing a Puppet module/manifest.

And last but not least: Puppet Labs has not yet released a Puppet client MSI package to take away the pain when rolling it out in a real, non-lab environment. However, your company is working on this AFAIK. :-)

In summary, I personally think: Puppet totally rocks on Linux/Mac OS/BSD. It is especially helpful in mixed environments. It even makes the whole operating system exchangeable as never before. But it is able to do so because the ecosystems around Linux, BSD, and partially Mac OS are sane and free. But Puppet does not have many opportunities to provide a comparable benefit on pure Windows environments because the Windows ecosystem is insane and not free (but this also affects other tools). And regarding Windows configuration itself, it competes with Active Directory GPOs. Because Windows configuration itself naturally is Windows-only, not even the argument “Puppet manifests are managing the same resources on different operating systems” is relevant. Exceptions: Users and groups.

Just an idea as I'm writing this comment: What about an ADM or GPO type for Puppet? I think this would be a useful feature and a reason to use Puppet on Windows. It would enable e.g. a Linux dominated environment managed by Puppet to add some Windows boxes without the need to teach the admins a completely different tool-chain and/or run a Windows Domain Controller with Active Directory. The admins just would have to learn how to write ADM-templates plus taking the ones Microsoft provides. But one could still manage everything by just using Puppet. However, Puppet Labs would need to implement an ADM template parser to create GPO objects plus logic to enforce them on the client. Bad idea?

Leave a comment…

H U᠎ U E K
  • E-Mail address will not be published.
  • Formatting:
    //italic//  __underlined__
    **bold**  ''preformatted''
  • Links:
    [[http://example.com|Link Text]]
  • Quotation:
    > This is a quote. Don't forget the space in front of the text: "> "
  • Code:
    <code>This is unspecific source code</code>
    <code [lang]>This is specifc [lang] code</code>
    <code php><?php echo 'example'; ?></code>
    Available: html, css, javascript, bash, cpp, …
  • Lists:
    Indent your text by two spaces and use a * for
    each unordered list item or a - for ordered ones.
I'm no native speaker (English)
Please let me know if you find any errors (I want to improve my English skills). Thank you!
QR Code: URL of current page
QR Code: URL of current page 2012:02:05:how-to-start-puppet-system-config-links-resources-tutorials (generated for current page)