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

James Turnbull

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!

ohad

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).

Andreas Haerter

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?