Puppet 3.3.0 发布,系统管理工具

来源: 投稿
作者: fei
2013-09-14 00:00:00

Puppet,是基于Ruby的一个工具,可以集中管理每一个重要方面,使用的是跨平台的规范语言,管理所有单独的元素,通常聚集在不同的文件,如用户, CRON作业,和主机一起的离散元素,如包装,服务和文件。



集中式系统管理工具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新版本发布太快了。


Puppet 3.3.0

Released September 12, 2013.

3.3.0 is a backward-compatible feature and fix release in the Puppet 3 series.

Upgrade Warning

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.

See the note below on yaml deprecation for details.

Configurable Resource Ordering

(Issue 22205: Order of resource application should be selectable by a setting.)

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

(Issue 16856: puppet should support 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

(Issue 21427: Deprecate YAML for network data transmission)

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.)

(Issue 2628: It would be useful if node name regexps set $1)

Node definitions now set the standard regex capture variables, similar to the behavior of conditional statements that use regexes.

Redirect Response Handling

(Issue 18255: accept 301 response from fileserver)

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.

Filebucket Improvements

(Issue 22375: File bucket and Puppet File resource: fails with “regexp buffer overflow” when backing up binary file)

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

(Issue 21831: Generate a UUID for catalog retrieval and report posts)

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

(Issue 21749: Make attributes readable 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

(Issue 6561: Better looking CSS for puppet doc rdoc mode)

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

(Issue 20284: Output one item per line for 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

(Issue 21170: enhancement of the module generate functionality)

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

(Issue 16792: permit to remove more than 1 package using 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

(Issue 19875: Get package descriptions from 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.

(Issue 21930: Enchance OpenBSD pkg.conf handling)

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.

(Issue 22021: Implement (un)install options feature for OpenBSD package provider)

It is now possible to specifyinstall_optionsanduninstall_optionsfor the OpenBSD package provider. These were previously not available.

(Issue 22023: Implement purgeable feature for OpenBSD package provider)

It is now possible to use thepurgedvalue forensurewith the OpenBSD package provider.

Yumrepo Type: AWS S3 Repos

(Issue 21452: Adds3_enabledoption to the yumrepo type)

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.



9 收藏
0 评论
9 收藏