Part 2: Top Questions on Puppet and Windows

by rv|12 January 2013
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:
  1. 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.
  2. 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.
Puppet is not a replacement for data-layer backups for variable data or database dumps, but it can be used to install and configure client backup software or ensure that scheduled backup jobs exist. Q: Can I get the status of the installation programmatically from Puppet? The data flow for a Puppet run is roughly as follows:
  1. Facter is run on the agent node and the resulting fact information uploaded to the master node.
  2. 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.
  3. The catalog is sent back to the client, which then applies it locally. A report is generated as the catalog is applied.
  4. The report is sent back from the agent node to the master.
When the report is received by the master it is sent through a series of report processors, according to the master's configuration. The report processor API can be used to write custom report processors that will react programmatically to any configuration management event, whether it is a particular resource failure, a resource change, a threshold number of changes, or any other trigger/condition based on the report data. For more information on report processors, click here. If you would like real-time data about the progress of Puppet runs before the finished report is submitted to the master, open source projects exist to provide this even deeper level of introspection. One such tool is Hunter Haugen’s progress_mq logdest terminus plugin which submits a message to a message bus whenever an event is produced by the puppet application. Readers can then monitor the bus and report in real time the progress of a Puppet run. The progress_mq project can be found here. Q: Can I do provisioning of an environment using Puppet? The Puppet Cloud Provisioner tool allows integration with Puppet for the purposes of creating, bootstrapping, and terminating virtual machines using a command-line or Ruby API through Puppet. More information on the Cloud Provisioner can be found here. Also of interest is the early-alpha Razor application, which is designed to provide profile-based bare-metal provisioning. More information on Razor can be found here. The core Puppet application is designed to run on anything from Just Enough Operating System (JeOS) up and so does not address provisioning directly, leaving that up to the Cloud Provisioner, Razor, or other lower-layer applications. Q: Is there a way to stop an .exe from being installed every 30 minutes? The 'Package' resource for a MSI can include the 'ensure installed' option. The 'Exec' resource will just fire off every time the agent checks in. The 'windows' package provider which ships with Puppet 3.0 can handle arbitrary *.exe installers, can determine whether or not an application needs to be installed, and will not perform extraneous work or reinstallation without a reason. The most common cause of a package resource performing repeat-installation is a name error; the name of the package resource (in Puppet) needs to match exactly the name in Windows (the DisplayName property from Add/Remove Programs) in order for Puppet to detect that the "package" is already installed. For exec resources check out the "refreshonly", "creates", and "unless" parameters. These exec-specific parameters allow for manual specification of condition checks that will determine whether or not to actually run the command specified. Click here for detailed technical information on each of the parameters and what they do.

Learn More

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.