Part 2: Top Questions on Puppet and Windows
A few days ago, I left you with Part 1: Top Questions on Puppet and Windows. As I mentioned in that blog post, I received a ton of questions during a Puppet Enterprise and Windows webinar that I recently hosted -- so many that I couldn't get to all of them. In part 1, I answered questions such as: how is Puppet Enterprise different from SCCM, future plans for Windows-capable modules on Puppet Forge, and whether or not the puppet master role can be installed on a Windows machine. Today, I complete the blog series with answers to more questions on Puppet and Windows. Enjoy!
Q: Can Puppet be used to copy contents recursively from one Windows shared folder to another Windows shared folder?
You can do this using a Puppet file type with a local source parameter. Puppet makes no particular distinction between any folder, regardless of whether it is shared (Windows), mounted over NFS (Linux), or on the same disk partition as the OS. The Puppet file type works at the filesystem layer so as long as it's attached, it can be used.
To recursively ensure that one folder contains the same content as another using Puppet, you can specify a resource such as the following:
file { 'C:/packages':
ensure => directory,
source => 'Z:/depot',
recurse => true,
}
Q: Is it possible to install Puppet with the MSI but without starting the service?
To achieve this currently, the MSI file needs to be edited (e.g. using Orca) to change the startup type. A feature request has been filed to expose this option on the command line so that it can be specified without adjustments to the MSI.
Q: How does Puppet for Windows handle file permissions (AD rights, etc.). When a file is copied from a share, what permissions are inherited?
Puppet can manage file owner and group per typical Puppet practice. For Windows ACLs, Puppet currently uses an interpretation of Posix-style modes to set permissions, but does not support enforcing more complex ACLs. Josh Cooper (Puppet Labs, Developer) describes the behavior in a little more detail:
If owner, group and mode are unspecified, then [a given] file/dir receive the default ACL for the user Puppet is running as, e.g. LocalSystem. If owner, group, or mode are specified, then Puppet maps the POSIX style permissions to Windows ACLs, similarly to how cygwin does this. Each file/dir is "protected" meaning it does not inherit from higher level containers, so that Puppet can explicitly manage the effective state of the resource.In the Windows world, using Puppet to manage file ACLs more directly would be hugely useful. The correct approach for managing ACLs would be to create a separate type/provider to apply ACLs on top of managed or unmanaged files. Some discussion to that effect can be found here and a feature request can be found here. Q: How does Puppet help with backup and disaster recovery for Windows? Configuration management is all about defining and enforcing the important parts of your configuration in a central revision-controlled "source of truth." If you use Puppet to define every piece of configuration implemented on a production system, you get two benefits:
- The first is that if an inadvertent manual change is made to something managed through Puppet and forgotten, at the next agent run the change will be reverted and the remediation step logged in the report sent to the Puppet master.
- The second benefit is that if the entire system is lost the configuration layer can be rebuilt automatically on a new node and in such a way that you are assured it will be a functional replacement for its lost predecessor. In these ways, Puppet centralizes and tracks configuration of systems allowing individual infrastructure components to become more disposable, as they can be replaced quickly and automatically with a lightweight and portable collection of plain text description.
- Facter is run on the agent node and the resulting fact information uploaded to the master node.
- The fact information for the agent is compiled against the manifests on the master node to produce a catalog. Like all function calls, hiera calls are executed as part of catalog generation and so hiera is run on the master node.
- The catalog is sent back to the client, which then applies it locally. A report is generated as the catalog is applied.
- The report is sent back from the agent node to the master.
Learn More
- Check out Part 1: Top Questions on Puppet and Windows
- Register for an upcoming Puppet Enterprise webinar
- Download the Puppet Enterprise + Windows on-demand webinar
- Docs on Puppet and Windows
- Download Puppet Enterprise -- the first 10 nodes are free