The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Basic Puppet agent support on Windows
|Assignee:||Jason McKerr||% Done:|
|Category:||windows||Estimated time:||400.00 hours|
|Affected Puppet version:||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
We’re targeting Win2003 R2 and Win2008 R2 Servers.
- Full agent support talking to a master
- File resource, owner, group, some form of ACL/mode support
- Local User management
- Local Group management
- Task scheduling via Windows scheduler (new type, not as a provider for the cron type)
- MSI package provider support without a central repository/WSUS.
- Service management (no DACLs, just ensure/enable as per other providers)
- Exec support via WinRM (and/or Powershell, depending upon initial tech evaluation)
Secondary, Optional Features:¶
- Registry management (e.g. inserting installer license keys)
- Package installation via .exe installers
Explicitly out of scope Features:¶
- Puppet master support on Windows
- Group Policy
- Active Directory Support
- Network interfaces
#1 Updated by Josh Cooper almost 4 years ago
From meeting July 8th
- Team to provide Jason with machine specifications for running Windows Server 2008 R2
- Nigel to verify that 2003 support is out of scope
- Customers will be required to install ruby 1.8.7 and necessary gems prior to installing puppet.
- We will try to avoid dependencies on native code, but if we end up using a gem that contains native code, customers will be required to install the RubyInstaller development kit to compile the native code.
- Puppet installation can consist of ruby/batch scripts, delivered in a zip file.
- ACL support will be limited to simple use cases, e.g. make this directory, all subdirectories and file, look like “this”. We will not support adding or removing specific types of access control entries from the list.
- We expect puppet will need to install MSI packages from a network share, e.g. UNC paths or mapped drives.
- We expect puppet will be deployed in a Windows workgroup environment.
Out of scope:
- Running puppet agent as a windows service
- Delivering executable puppet installer (MSI, Wise, etc) nor as a gem
- Windows event log destination
- Support for 2003
- Support for domain-joined servers
#5 Updated by Josh Cooper almost 4 years ago
From meeting 9/1:
- UNC support. Jacob will see if the msi package provider can install from UNC, Nick will check if path validation handles UNC
- User type/provider needs to support windows passwords (see below)
- Need to support managing passwords. For now this means cleartext passwords, though the team will investigate other options
- No SMB mount provider
- No MSI installer for puppet agent itself
- No native support for running puppet agent as a service (daemonized), though we will ensure the agent can run as an agent, and will provide instructions on how users can install and configure using third party service wrapper programs, nssm
- Not all DACL combinations will be supported, e.g. deny access control entries
#6 Updated by Josh Cooper over 3 years ago
- Category set to windows
Whenever we next make a public announcement about our Windows support no longer being “preliminary”, we should update this accordingly http://en.wikipedia.org/wiki/Comparison_of_open_source_configuration_management_software#Platform_support