集中式系统管理工具Puppet发布3.3.1。这是新的产品线系列3.3的第一个Bug修正版。经过3个RC。2013-10-07 上个版本是2013-09-13的3.3.0.其他产品线3.1.1 3.0.2 2.7.23。
Released October 7, 2013.
3.3.1 is a bug fix release in the Puppet 3.3 series. The focus of the release is fixing backwards compatibility regressions that slipped in via the YAML deprecations in 3.3.0.
The release of Puppet 3.3.1 supersedes the upgrade warning for Puppet 3.3.0. As of this release, agent nodes are compatible with all Puppet 3.x masters with no extra configuration.
Fixes for Backwards Compatibility Regressions in 3.3.0
- Issue 22535: puppet 3.3.0 ignores File ignore in recursive copy
- Issue 22608: filebucket (backup) does not work with 3.3.0 master and older clients
- Issue 22530: Reports no longer work for clients older than 3.3.0 when using a 3.3.0 puppet master
- Issue 22652: ignore doesn’t work if pluginsync enabled
New backward compatibility issues were discovered after the release of 3.3.0, so we changed our handling of deprecated wire formats.
Starting with 3.3.1, you do not need to set additional settings in puppet.conf on your agent nodes in order to use newer agents with puppet masters running 3.2.4 or earlier. Agents will work with all 3.x masters, and they will automatically negotiate wire formats as needed. This behavior supersedes the behavior described for 3.3.0; thereport_serialization_formatsetting is now unnecessary.
Additionally, this release fixes:
- Two cases where 3.3.0 masters would do the wrong thing with older agents. (Reports would fail unless the master hadreport_serialization_formatset toyaml, which was not intended, and remote filebucket backups would always fail.)
- A regression where files that should have been ignored during pluginsync were being copied to agents.
Miscellaneous Regression Fixes
This was a regression in 3.3.0, caused by deprecating YAML for content we send to remote filebuckets.
This was a regression in 3.3.0.
When using multiple values in an array for the file type’ssourceattribute, Puppet will check them in order and use the first one it finds; whenever it doesn’t find one, it will log a note at the “info” log level, which is silent when logging isn’t verbose. In 3.3.0, the level was accidentally changed to the “notice” level, which was too noisy.
This was a regression in 3.3.0. Theaptpackage provider was logging bogus warnings when processing resources withensurevalues ofabsentorpurged.
This problem was probably introduced in Puppet 3.2, when our Windows installer switched to Ruby 1.9; a fix was attempted in 3.2.4, but it wasn’t fully successful.
The behavior was caused by a bug in one of the Ruby libraries Puppet relies on. We submitted a fix upstream, and packaged a fixed version of the gem into the Windows installer.
Fixes for Long-Standing Bugs
This bug dates to Puppet 2.6 or earlier.
The bug behavior was weird. Basically:
- Your manifests include multiplessh_authorized_keyresources for multiple user accounts.
- One of the users has messed-up permissions for their authorized keys file, and their resource fails because Puppet tries to write to the file as that user.
- All remaining key resources also fail, because Puppet tries to write the rest of them to that same user’s file instead of the file they were supposed to go in.
This bug dates to 3.0.0. It was causing problems when using plugins that use SOAP libraries, such as the types and providers in the puppetlabs/f5 module.
This bug dates to 3.0.0, and caused Puppet to fail when running on a copy of Ruby without zlib compiled in.
This bug dates to 3.0.0, and could cause occasional agent run failures under Ruby 1.9 or 2.0.