集中式系统管理工具Puppet发布3.3.0正式版。这是新的产品线系列。经过3个RC.带来了很多增强和改进。2013-09-13上个版本是2013-08-16的3.2.4其他产品线3.1.1 3.0.2 2.7.23 好像Puppet新版本发布太快了。
Released September 12, 2013.
3.3.0 is a backward-compatible feature and fix release in the Puppet 3 series.
Note: Whenever possible, upgrade your puppet masters first.
Although 3.3.0 is backward-compatible, its default configuration will cause reporting failures when ≥ 3.3.0 agent nodes connect to a sub-3.3.0 master.
- This only affects newer agents + older masters; it is not a problem if you upgrade the puppet master first.
- To use ≥ 3.3.0 agents with an older puppet master, setreport_serialization_formattoyamlin their puppet.conf files; this restores full compatibility.
Configurable Resource Ordering
Puppet can now optionally apply unrelated resources in the order they were written in their manifest files.
A neworderingsetting configures how unrelated resources should be ordered when applying a catalog. This setting affects puppet agent and puppet apply, but not puppet master.
The allowed values for this setting aretitle-hash,manifest, andrandom:
- title-hash(the default) will order resources randomly, but will use the same order across runs and across nodes.
- manifestwill use the order in which the resources were declared in their manifest files.
- randomwill order resources randomly and change their order with each run. This can work like a fuzzer for shaking out undeclared dependencies.
Regardless of this setting’s value, Puppet will always obey explicit dependencies set with the before/require/notify/subscribe metaparameters and the->/~>chaining arrows; this setting only affects the relative ordering of unrelated resources.
Data in Modules
This feature makes it possible to contribute data bindings from modules to a site-wide hierarchy of data bindings. This feature is introduced as an opt-in, and it is turned on by settingbindertotruein puppet.conf. It is turned on by default when using the future parser. The implementation is based on ARM-9 Data in Modules, which contains the background, a description, and a set of examples.
Security: YAML Over the Network is Now Deprecated
YAML has been the cause of many security problems, so we are refactoring Puppet to stop sending YAML over the network. Puppet will still write YAML to disk (since that doesn’t add security risks), but all data objects sent over the network will be serialized as JSON. (Or, for the time being, as “PSON,” which is JSON that may sometimes contain non-UTF8 data.)
As of this release:
- All places where the puppet master accepts YAML are deprecated. If the master receives YAML, it will still accept it but will log a deprecation warning.
- The puppet master can now accept reports in JSON format. (Prior to 3.3.0, puppet masters could only accept reports in YAML.)
- The puppet agent no longer defaults to requesting YAML from the puppet master (for catalogs, node objects, etc.).
- The puppet agent no longer defaults to sending YAML to the puppet master (for reports, query parameters like facts, etc.).
Deprecation plan: Currently, we plan to remove YAML over the network in Puppet 4.0. This means in cases where Puppet 3.3 would issue a deprecation warning, Puppet 4 will completely refuse the request.
New Setting for Compatibility With Sub-3.3.0 Masters
Puppet 3.3 agents now default to sending reports as JSON, and masters running Puppet 3.2.4 and earlier cannot understand JSON reports. Using an out of the box 3.3 agent with a 3.2 puppet master will therefore fail.
- To avoid errors, upgrade the puppet master first.
- If you must use ≥ 3.3.0 agents with older puppet masters, set the newreport_serialization_formattoyamlin the agents’ puppet.conf; this restores full compatibility.
Regex Capture Variables from Node Definitions ($1, etc.)
Node definitions now set the standard regex capture variables, similar to the behavior of conditional statements that use regexes.
Redirect Response Handling
Puppet’s HTTP client now follows HTTP redirects when given status codes 301 (permanent), 302 (temporary), or 307 (temporary). The new functionality includes a redirection limit, and recreates the redirected connection with the same certificates and store as the original (as long as the new location is ssl protected). Redirects are performed for GET, HEAD, and POST requests.
This is mostly useful for configuring the puppet master’s front end webserver to send fileserver traffic to the closest server.
There were a number of problems with the remote filebucket functionality for backing up files under Puppet’s management over the network. It is now possible to back up binary files, which previously would consume lots of memory and error out. Non-binary filebucket operations should also be faster as we eliminated an unnecessary network round-trip that echoed the entire contents of the file back to the agent after it was uploaded to the server.
Internal Format and API Improvements
Report Format 4
Puppet’s report format version has been bumped to 4. This is backward-compatible with report format 3, and addstransaction_uuidto reports andcontainment_pathto resource statuses.
Unique Per-run Identifier in Reports and Catalog Requests
Puppet agent now embeds a per-run UUID in its catalog requests, and embeds the same UUID in its reports after applying the catalog. This makes it possible to correlate events from reports with the catalog that provoked those events.
There is currently no interface for doing this correlation, but a future version of PuppetDB will provide this functionality via catalog and report queries.
Readable Attributes on Puppet::ModuleTool::Dependency Objects
This API change enables access to module dependency information via Ruby code.
User Interface Improvements
Improved CSS for Puppet Doc Rdoc Output
The standard skin for rdoc generated from Puppet manifests has been updated to improve readability. Note that puppet doc rdoc functionality remains broken on Ruby 1.9 and up.
Improved Display of Arrays in Console Output
This changes the output to console from faces applications to output array items as one item per line.
Configurable Module Skeleton Directory
Previously, you could provide your own template for thepuppet module generateaction by creating a directory calledskeletonin the directory specified by themodule_working_dirsetting. (The layout of the directory should match that of lib/puppet/module_tool/skeleton.) This directory can now be configured independently with themodule_skeleton_dirsetting.
Improvements to Resource Types
Package Type: Multi-Package Removal With Urpmi Provider
It was tedious to remove some packages when using the urpmi provider since it only allowed to remove one package at the time, and that removal must be made in dependency order. Now, the urpmi provider behaves similar to the apt provider.
Package Type: Package Descriptions in RAL
Previously, rpm and dpkg provider implementations obtained package information from the system without capturing descriptions. They now capture the single line description summary for packages as a read-only parameter.
Package Type: OpenBSD Improvements
Jasper Lievisse Adriaanse contributed several improvements and fixes to the OpenBSD package provider.
It is now possible to use+=when defining theinstallpathfor OpenBSD. Previously, an attempt to use this was ignored; now, it’s possible to have a pkg.conf like:
installpath = foo installpath += bar
Which will be turned into aPKG_PATH: foo:bar.
It is now possible to specifyinstall_optionsanduninstall_optionsfor the OpenBSD package provider. These were previously not available.
It is now possible to use thepurgedvalue forensurewith the OpenBSD package provider.
Yumrepo Type: AWS S3 Repos
It is now possible to use a yum repo stored in AWS S3 (via the yum-s3-iam plugin) by setting the resource’ss3_enabledattribute to1.