Release Notes
The Release Notes document is a feature roadmap to the various Puppet versions. It details changes to features, functions, language, configuration and types during the course of Puppet’s development. It highlights incompatibilities and specifies when new features were introduced and the extent to which they are backwards-compatible.
Also available is the Roadmap Tracker which lists tickets closed for each release. Just click on the relevant release from the list on the right hand side.
If upgrading you should review this document upward from the version you are upgrading from. Please remember that if upgrading through multiple versions some behaviour may change more than once.
It is also important to note when upgrading that not all versions are backwards compatible. Newer clients may not work with older servers and vice-versa. Where possible backwards-compatibility is maintained but it’s not always totally successful. The best approach is to ensure your master and clients are the same version. When upgrading it is also recommended that you upgrade your master first.
- 2.6.1
- Functions
- Extlookup
- md5
- Documentation
- 2.6.0
- Language
- Support for parameterised classes
- New relationship syntax
- Run Stages
- Support for hashes in the DSL
- The "in" syntax
- Pure Ruby Manifests
- Support for an elsif syntax
- Case and Selectors now support undef
- Stored Configuration
- Facts
- Types and Providers
- Binaries and Configuration
- Single Binary
- New options
- Binary changes
- Functions
- Reports
- Puppet Runner
- Incompatibilities
- 0.25.5
- Binaries and Configuration
- Functions
- Types and Providers
- Error Messages
- 0.25.4
- Binaries and Configuration
- 0.25.3
- 0.25.2
- Binaries and Configuration
- Types and Providers
- Error Messages
- Dependencies
- LDAP
- 0.25.1
- Functions
- Language
- Types and Providers
- Binaries and Configuration
- 0.25.0
- Migration to REST
- Deprecations
- New Language Features
- New functions
- Configuration Versioning
- Command Line Compile & Apply
- puppetmasterd --compile nodename
- Thin Stored Configuration
- Puppet Queuing
- Application Controller
- Types and Providers
- Binary Location Move
- Passenger
- Rails
- 0.24.9
- Binaries and Configuration
- 0.24.8
- Functions
- 0.24.7
- Binary and Configuration
- Types and Providers
- Language and Facts
- Functions
- Stored Configuration
- Errata
- 1922: Severe breakage when using parser functions with complex
- 0.24.6
- Dependencies
- Binary and Configuration
- Language and Facts
- Types and Providers
- 0.24.5
- Binary and Configuration
- Environments
- Types and Providers
- Functions
- Language and Facts
- Modules
- LDAP
- Nodes
- Virtual and Exported/Collected Resources
- 0.24.4
- Binary and Configuration
- Types and Providers
- Documentation
- 0.24.3
- Languages and Facts
- Binaries and Configuration
- External Nodes
- LDAP Nodes
- 0.24.2
- Plugins
- Virtual Resources
- Tags
- Binaries and Configuration
- Language and Facts
- Types and Providers
- 0.24.1
- Binaries and Configuration
- 0.24.0 (misspiggy)
- External Nodes
- LDAP Nodes
- Plugins
- Certificates
- Mongrel
- Language and Facts
- Binaries and Configuration
- Types and Providers
- 0.23.2
- Binaries and Configuration
- Types and Providers
- 0.23.1 (beaker)
- Language and Facts
- Exported/Collected Resources
- Binaries and Configuration
- Types and Providers
- Modules
- Plugins
- 0.23.0
- Functions
- Nodes
- LDAP Nodes
- External Nodes
- Stored Configuration
- File Locations
- Types and Providers
- Language and Facts
- Binaries and Configuration
- 0.22.4
- Modules
- Types and Providers
- Language and Facts
- 0.22.3
- Binaries and Configuration
- Types and Providers
- 0.22.2 (grover)
- Language and Facts
- File Locations
- Mongrel
- Binaries and Configuration
- Certificate Authorities
- Functions
- Types and Providers
- 0.22.1 (kermit)
- Resource Relationships
- Language and Facts
- Types and Providers
- 0.22.0
- Types and Providers
- Stored Configuration
- Language and Facts
- 0.20.0
- Virtual and Exported/Collected Resources
- Resource Relationships
2.6.1
This release is largely a maintenance release for 2.6.0 but also includes basic support for running Puppet under JRuby.
Functions
Extlookup
R.I. Pienaar’s extlookup function has been added to core. This is an initial import of this function. Additional functionality, including YAML and JSON backends, will be added in future releases.
This is a parser function to read data from external files, this version uses CSV files but the concept can easily be adjust for databases, yaml or any other queryable data source.
The object of this is to make it obvious when it’s being used, rather than magically loading data in when an module is loaded I prefer to look at the code and see statements like:
$snmp_contact = extlookup("snmp_contact")
The above snippet will load the snmp_contact value from CSV files, this in its own is useful but a common construct in puppet manifests is something like this:
case $domain {
"myclient.com": { $snmp_contact = "John Doe <john@myclient.com>" }
default: { $snmp_contact = "My Support <support@my.com>" }
}
Over time there will be a lot of this kind of thing spread all over your manifests and adding an additional client involves grepping through manifests to find all the places where you have constructs like this.
This is a data problem and shouldn’t be handled in code, a using this function you can do just that.
First you configure it in site.pp:
$extlookup_datadir = "/etc/puppet/manifests/extdata"
$extlookup_precedence = ["%{fqdn}", "domain_%{domain}", "common"]
The array tells the code how to resolve values, first it will try to find it in web1.myclient.com.csv then in domain_myclient.com.csv and finally in common.csv
Now create the following data files in /etc/puppet/manifests/extdata like this:
domain_myclient.com.csv:
snmp_contact,John Doe <john@myclient.com>
root_contact,support@%{domain}
client_trusted_ips,192.168.1.130,192.168.10.0/24
common.csv:
snmp_contact,My Support <support@my.com>
root_contact,support@my.com
Now you can replace the case statement with the simple single line to achieve the exact same outcome:
$snmp_contact = extlookup("snmp_contact")
The obove code shows some other features, you can use any fact or variable that is in scope by simply using %{varname} in your data files, you can return arrays by just having multiple values in the csv after the initial variable name.
In the event that a variable is nowhere to be found a critical error will be raised that will prevent your manifest from compiling, this is to avoid accidentally putting in empty values etc. You can however specify a default value:
$ntp_servers = extlookup("ntp_servers", "1.${country}.pool.ntp.org")
In this case it will default to “1.${country}.pool.ntp.org” if nothing is defined in any data file.
You can also specify an additional data file to search first before any others at use time, for example:
$version = extlookup("rsyslog_version", "present", "packages")
package{"rsyslog": ensure => $version }
This will look for a version configured in packages.csv and then in the rest as configured by $extlookup_precedence if it’s not found anywhere it will default to “present”, this kind of use case makes puppet a lot nicer for managing large amounts of packages since you do not need to edit a load of manifests to do simple things like adjust a desired version number.
md5
An md5 hashing function
Documentation
Migration of internal Restructured Text Documentation to Markdown
2.6.0
Language
Support for parameterised classes
The Rowlf release provides an extension to the existing class syntax to allow parameters to be passed to classes. This brings classes more in line with definitions, with the significant difference that definitions have multiple instances whilst classes remain singletons.
To create a class with parameters you can now specify:
class apache($version) {
... class contents ...
}
Classes with parameters are NOT added using the include function but rather the resulting class can then be included more like a definition:
node webserver {
class { apache: version => "1.3.13" }
}
Like definitions, you can also specify default parameter values in your class like so:
class apache($version="1.3.13",$home="/var/www") {
... class contents ...
}
New relationship syntax
You can now specify relationships directly in the language:
File[/foo] -> Service[bar]
Specifies a normal dependency while:
File[/foo] ~> Service[bar]
Specifies a subscription.
You can also do relationship chaining, specifying multiple relationships on a single line:
File[/foo] -> Package[baz] -> Service[bar]
Note that while it’s confusing, you don’t have to have all of the arrows be the same direction:
File[/foo] -> Service[bar] <~ Package[baz]
This can provide some succinctness at the cost of readability.
You can also specify full resources, rather than just resource references:
file { "/foo": ensure => present } -> package { bar: ensure => installed }
But wait! There’s more! You can also specify a subscription on either side of the relationship marker:
yumrepo { foo: .... }
package { bar: provider => yum, ... }
Yumrepo <| |> -> Package <| provider == yum |>
This, finally, provides easy many to many relationships in Puppet, but it also opens the door to massive dependency cycles. This last feature is a very powerful stick, and you can considerably hurt yourself with it.
Run Stages
Run Stages are a way for you to provide coarse-grained ordering in your manifests without having to specify relationships to every resource you want in a given order. It’s most useful for setup work that needs to be done before the vast majority of your catalog even works – things like configuring yum repositories so your package installs work.
Run Stages are currently (intentionally) a bit limited – you can only put entire classes into a run stage, you can’t put individual resources there.
There’s a main stage that resources all exist in by default; if you don’t use run stages, everything’s in this, but it doesn’t matter to you. You can define new stages via the new stage resource type:
stage { pre: before => Stage[main] }
Here we’ve used the before metaparameter but you could also use after, require, etc to establish the necessary relationships between stages.
Now you just specify that your class belongs in your new run stage:
class yum { ... }
class redhat {
...
class { yum: stage => pre }
}
This will make sure that all of the resources in the yum are applied before the main stage is applied.
Note that we’re using the new parameterized classes here – this is necessary because of the class-level limitations of Run Stages. These limitations are present because of the complication of trying to untangle resource dependencies across stage boundaries if we allowed arbitrary resources to specify stages.
On a related note, if you specify a stage for a given class, you should specify as few as possible explicit relationships to or from that class. Otherwise you risk a greater chance of dependency cycles.
This can all be visualized relatively easily using the —graph option to puppetd and opening the graphs in OmniGraffle or GraphViz.
Specifying the ordering of Run Stages also works much better when specified using the new relationship syntax, too:
stage { [pre, post]: }
Stage[pre] -> Stage[main] -> Stage[post]
This way it’s very easy to see at a glance exactly how the stages are ordered.
Support for hashes in the DSL
This brings a new container syntax to the Puppet DSL: hashes.
Hashes are defined like Ruby Hashes:
{ key1 => val1, ... }
The Hash keys are strings but hash values can be any possible right values admitted in Puppet DSL (i.e. a function call or a variable)
Currently it is possible:
- to assign hashes to a variable
$myhash = { key1 => "myval", key2 => $b }
- to access hash members (recursively) from a variable containing a hash (works for array too):
$myhash = { key => { subkey => "b" }}
notice($myhash[key][subkey]]
to use hash member access as resource title
to use hash in default definition parameter or resource parameter if the type supports it (none for the moment).
It is not possible to use an hash as a resource title. This might be possible once we support compound resource title.
The “in” syntax
From Puppet 2.6.0 you can also use the “in” syntax. This operator allows you to find if the left operand is in the right one. The left operand must be a string, but the right operand can be:
- a string
- an array
- a hash (the search is done on the keys)
This syntax can be used in any place where an expression is supported:
$eatme = 'eat'
if $eatme in ['ate', 'eat'] {
...
}
$value = 'beat generation'
if 'eat' in $value {
notice("on the road")
}
Pure Ruby Manifests
Puppet now supports pure Ruby manifests as equivalent to Puppet’s custom language. That is, you can now have Ruby programs along side your Puppet manifests. As is our custom, it’s a limited first version, but it covers most of the specification functionality of the current language. For instance, here’s a simple ssh class:
hostclass :ssh do package "ssh", :ensure => :present file "/etc/ssh/sshd_config", :source => "puppet:///ssh/sshd_config", :require => "Package[ssh]" service :sshd, :ensure => :running, :require => "File[/etc/ssh/sshd_config]" end
Similar to the ‘hostclass’ construct here, you can specify defined resource types:
define "apache::vhost", :ip, :docroot, :modperl => false do
file "/etc/apache2/sites-enabled/#{@name}.conf", :content => template("apache/vhost.erb")
end
As you can see from this code, the parameters for the resources become instance variables inside of the defined resource types (and classes, now that we support parameterized classes).
We can do nodes, too:
node "mynode" do include "apache" end
Ruby has become a first-class citizen alongside the existing external DSL. That means anywhere you can put a manifest, you should be able to put ruby code and have it behave equivalently. So, the ‘ssh’ class above could be put into ‘$modules/ssh/manifests/init.rb’, the apache vhost type should be placed in ‘$modules/apache/manifests/vhost.rb’, and the node should probably be in your ‘site.pp’ file. You can also apply ruby manifests directly with puppet:
puppet -e mystuff.rb
Note that the Ruby support does not yet cover all of the functionality in Puppet’s language. For instance, there is not yet support for overrides or defaults, nor for resource collections. Virtual and exported resources are done using a separate method:
virtual file("/my/file", :content => "something")
All of the standard functions are also pulled into Ruby and should work fine — e.g., ‘include’, ‘template’, and ‘require’.
Support for an elsif syntax
Allows use of an elsif construct:
if $server == 'mongrel' {
include mongrel
} elsif $server == 'nginx' {
include nginx
} else {
include thin
}
Case and Selectors now support undef
The case and selector statements now support the undef syntax (see #2818).
Stored Configuration
Support is now added for using Oracle databases as a back-end for your stored configuration.
Facts
There are three new facts available in manifests:
$clientcert– the name of the client certificate$module_name– the name of the current module (see #1545)$caller_module_name– the name of the calling module (see #1545)
In addition all puppet.conf configuration items are now available as facts in your manifests. These can be accessed using the structure:
$settings::setting_name
Where setting_name is the name of the configuration option you’d like to retrieve.
Types and Providers
Basic Windows support has been introduced…
A new provider for pkg has been added to support Solaris and OpenSolaris (pkgadd).
A new package provider has been added to support AIX package management.
The augeas type has added the ‘incl’ and ‘lens’ parameters. These parameters allow loading a file anywhere on the filesystem; using them also greatly speeds up processing the resource.
Binaries and Configuration
Single Binary
Puppet is now available as a single binary with sub-arguments for the functions previously provided by the seperate binaries (the existing binaries remain for backwards compatibility). This includes renaming several Puppet functions to better fit an overall model.
List of binary changes
- puppetmasterd –> puppet master
- puppetd –> puppet agent
- puppet –> puppet apply
- puppetca –> puppet cert
- ralsh –> puppet resource
- puppetrun –> puppet kick
- puppetqd –> puppet queue
- filebucket –> puppet filebucket
- puppetdoc –> puppet doc
- pi –> puppet describe
This also results in a change in the puppet.conf configuration file. The sections, previously things like [puppetd], now should be renamed to match the new binary names. So [puppetd] becomes [agent]. You will be prompted to do this when you start Puppet. You will be prompted to do this when you start Puppet with a log message for each section that needs to be renamed. This is merely a warning – existing configuration file will work unchanged.
New options
A new option is available, ca_name, to specify the name to use for the Certificate Authority certificate. It defaults to the value of the certname option (see http://projects.reductivelabs.com/issues/1507).
A new option, dbconnections, is now available that specifies a limit for the number of database connections made to remote databases (postgreSQL, MySQL).
A new option, dbport, is now available that specifies the database port for remote database connections.
There’s also a new option/feature that lets the puppet client use HTTP compression (—http_compression):
Allow http compression in REST communication with the master. This setting might improve performance for agent –> master communications over slow WANs. Your puppetmaster needs to support compression (usually by activating some settings in a reverse-proxy in front of the puppetmaster, which rules out webrick).
It is harmless to activate this settings if your master doesn’t support compression, but if it supports it, this setting might reduce on high-speed LANs.
Binary changes
The puppetd (or puppet agent) binary now supports the —detailed-exitcodes option available in the puppet binary.
The puppet agent will now create the ssl when passed the —noop option.
Certificates cleaned with puppetca (or puppet cert) are now also revoked.
The puppetca (puppet cert) and puppetd (puppet agent) binaries now have support for certificate fingerprinting and support for specifying digest algorithms. To display the fingerprint of a client certificate use:
$ puppetd --fingerprint
or
$ puppet agent --fingerprint
To specify a particular digest algorithm use —digest DIGESTNAME.
To fingerprint a certificate with puppetca use:
$ puppetca --fingerprint host.example.com
or
$ puppet cert --fingerprint host.example.com
Also supported is the —digest option.
The puppetdoc binary now documents inheritance between nodes, shows classes added via the require function and resources added via the realize function.
Functions
The regsubst function now takes arrays as input (see #2491).
Reports
There is a new report type called http. If you specify:
reports = http
Then the new report processor will make a HTTP POST of the report in YAML format to a specified URL. By default this URL is the report import URL for a local Puppet Dashboard installation. You can override this with the new reporturl setting.
reports = http
reporturl = http://yoururl/post/
Puppet Runner
In order for this to run at all:
puppetrun --foreground --host XXX
you must alter auth.conf to include:
path /run
method save
allow *
otherwise you will receive:
Host $PUPPET failed: Error 403 on SERVER: Forbidden request: $MASTER(X.X.X.X) access to /run/$PUPPET [save] authenticated at line 101
Incompatibilities
PID files for puppet and master used to be named:
puppetd.pid
puppetmasterd.pid
new names are:
agent.pid
master.pid
0.25.5
Binaries and Configuration
The default location for Puppet’s dynamic files, the $vardir option, has changed from /var/puppet to /var/lib/puppet. This is already the default for the Fedora EPEL and Debian/Ubuntu packages and brings Puppet into FHS compliance.
The default factpath is now $vardir/lib/facter/.
The “use_cached_catalog” option is available. This determines whether to only use the cached catalog rather than compiling a new catalog on every run. Puppet can be run with this enabled by default and then selectively disabled when a recompile is desired. The option defaults to false.
Functions
The generate function now sets the working directory to the directory containing the specified command.
Types and Providers
You can now specify checksum => none in the file type to disable file check-summing.
Error Messages
The “warning: Value of ‘preferred_serialization_format’ (‘pson’) is invalid, using default (‘yaml’)” is now a debug level message.
0.25.4
Binaries and Configuration
- Pre- and Post- transaction hooks.
These hooks allow you to specify commands that should be run pre and post a Puppet configuration transaction. They are set with the prerun_command and postrun_command settings in the puppet.conf configuration file:
prerun_command = /bin/runbeforetransaction
postrun_command = /bin/runaftertransaction
The command must exit with 0, i.e. succeed, otherwise the transaction will fail – if the pre command fails before the transaction is run and if the post command fails at the end of the transaction.
0.25.3
No major notes.
0.25.2
Binaries and Configuration
Puppet now has the manage_internal_file_permissions option which allows you to enable or disable Puppet management of internal files, for example those in /var/lib/puppet. When false Puppet will NOT manage these files. Defualt is true.
The puppetdoc binary now works with Regex node names
Fix for temporary file issues (https://bugzilla.redhat.com/show_bug.cgi?id=502881)
Types and Providers
Cron type now supported on AIX
Mailist type is now working again
SELinux now supports contexts with upper case titles
When setting aliases using the host and sshkey types now use the host_aliases attribute rather than alias.
Error Messages
File serving permissions error messages enhanced
The debug format message has been changed and clarified from:
debug: Format s not supported for Puppet::FileServing::Metadata; has not implemented method 'from_s'
to:
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml; using pson
Dependencies
When running the tests you no longer need to use RSpec version 1.2.2 but rather versions including and newer than.
LDAP
There are now valid and proper OIDs in the LDAP puppet.schema that are unique and registered for Puppet.
0.25.1
Functions
We’ve clarified that the new ‘require’ function only works for 0.25.x clients. If the function is specified with 0.24.x or earlier clients the class will be included but the inherent dependency will not be created. A warning message will be generated informing you of this.
Language
Node regular expression matching rules have been clarified you can see the rules [[Language_Tutorial#matching-nodes-with-regular-expressions|Language Tutorial]] .
Types and Providers
The Nagios serviceescalation type now supports the use of the servicegroup_name attribute.
Binaries and Configuration
The Puppet gem now installs all binaries to the ‘bin’ directory because Gems lack support for both a bin and sbin directory. Facter (version later than 1.5.1) is now also a dependency for the gem.
0.25.0
Migration to REST
There are substantial changes in Puppet 0.25.0 and more changes to come in the future. Most of the changes in 0.25.0 are internal refactoring rather than behavioural. The 0.25.0 release should be fully backwards compatible behaviourally with the 0.24.x branch.
This means a 0.25.0 master will be able to manage 0.24.x clients. You will need, however, to upgrade both your master and your clients to take advantage of all the new features and the substantial gains in performance offered by 0.25.0.
The principal change is the introduction of Indirected REST to replace XML-RPC as the underlying Puppet communications mechanism.
This is a staged change with some functions migrated in this release and some in the next release. In the first stage of the Indirected REST implementation the following functions have been migrated:
- Certificates
- Catalogue
- Reports
- Files
In 0.26.0 (the next release) the following remaining functions will be migrated:
- Filebucket
- Resource handler
- Runner handler
- Status handler
The new REST implementation also comes with authorisation configuration in a similar style to the namespaceauth used for XML-RPC. This new authorisation is managed through the auth.conf file (there is an example file in the conf directory of the tarball). This does not yet fully replace the namespaceauth.conf file but will when the remaining handlers are migrated to REST. It works in a similar way to the namespaceauth.conf file and the example file contains additional documentation.
As a result of the introduction of REST and other changes you should see substantial performance improvements in this release. These particularly include improvements in:
- File serving
- The performance of large graphs with lots of edges
- Stored configuration (see also Puppet Queuing below)
Other new features include (this is not a complete list – please see the Roadmap for all tickets closed in this release):
Deprecations
Custom types and facts in modules have been moved from the module/plugins to module/lib. Please rename your directories.
The modules share and the module name must now be specified in source attributes of the file type, i.e:
file { "file":
source => "puppet://server/modules/module_name/file",
}
Binary-specific configuration files, such as puppetd.conf or puppetmasterd.conf are now totally deprecated and ignored.
New Language Features
Regular expression matching is now possible in node definitions:
node /web|db/ {
include blah
}
node /^(foo|bar)\.example\.com$/ {
include blah
}
Puppet now also allows regular expressions in if statements with the use of the =\~ (match) and !\~ (not match) operators:
if $uname =~ /Linux|Debian/ {
...
}
Also available are ephemeral variables ($0 to $9) in the current scope which contain regex captures:
if $uname =~ /(Linux|Debian)/ {
notice("this is a $1 system")
}
Similar functionality is available in case and selector statements:
$var = "foobar"
case $var {
"foo": {
notify { "got a foo": }
}
/(.*)bar$/: {
notify{ "hey we got a $1": }
}
}
$val = $test ? {
/^match.*$/ => "matched",
default => "default"
}
New functions
There are four new functions:
require – Similar to the include function but creates a dependency on the required class in the current class. This means the required class will be loaded before the current class is processed.
split – allows you to split strings and arrays
versioncmp – allows you to compare versions
shellquote – Quote and concatenate arguments for use in the shell, for example as part of Exec type commands.
Configuration Versioning
A new configuration option, config_version, is now available:
config_version = /usr/local/bin/return_version
The option allows you to specify a command that returns a version for the configuration that is being applied to your hosts. The command should return a string, such as a version number or name.
Puppet then runs this command at compile time. Each resource is marked with the value returned from this command. This value is also added to the log instance, serialised and sent along with any report generated. This allows you to parse your report output and ascertain which configuration version was used to generate the resource.
Command Line Compile & Apply
Puppet now has the capability to compile a catalogue and output it in JSON from the Puppet master. You can do this via the —compile command line option.
puppetmasterd —compile nodename
Corresponding with this feature is the ability to apply a JSON configuration from the puppet binary using the —apply option.
$ puppet --apply cataloguefile
Or you can use – to read the JSON in from standard input. Puppet will then compile and apply the configuration.
Thin Stored Configuration
0.25.0 also introduces the concept of “thin” stored configurations. This is a version of stored configuration that only stores the facts and exported resources in the database. This will perform better than full stored configuration but because not all resources are available this may not suit all purposes.
Thin stored configurations are initiated by setting the thin_storeconfigs option on the Puppet master or on the puppetmasterd command line using —thin_storedconfigs.
Puppet Queuing
There is a new binary called puppetqd that supports queuing for stored configurations. You can read about how it works and how to implement it at:
Further documentation is in the README.queuing file in the tarball.
Application Controller
All the logic has been moved out of the binary commands and added to an Application Controller. You can see the controller code at lib/puppet/application.rb and the logic for each application at lib/puppet/application/binaryname.rb.
Types and Providers
The return values from the Exec type can now be specified as an array.
The SMF and daemontools service providers can now import a configuration file.
The mailist type is now supported on Red Hat, CentOS and Fedora distributions
The NetInfo provider has been deprecated for OSX in favour of the Directory Services provider.
Binary Location Move
To bring Puppet more in line with general packaging standards the puppetd, puppetca, puppetrun, puppetmasterd, and puppetqd binaries now reside in the sbin directory rather than the bin directory when installed from the source package.
Passenger
Ensure you have the latest version of the config.ru file from the ext/rack/files/ directory in the tarball.
Rails
Rails versions up to 2.3.x are now supported. Rails version 2.2.2 or greater is required.
0.24.9
Binaries and Configuration
Fix for temporary file issues (https://bugzilla.redhat.com/show_bug.cgi?id=502881)
0.24.8
Functions
Added sprintf function
Added regsubst function
0.24.7
Binary and Configuration
The puppetdoc binary has been updated to output manifest and module documentation
Removed conf/debian directory and Debian packaging information now maintained downstream
The puppetca binary can now clean unsigned certificates
Removed all the vendor gems
Added Rake tasks to support continuous integration
Types and Providers
Added augeas type
Added MCX type
Add the macauthorization type
Add the directoryservice type
Deprecated the NetInfo nameservice provider
Added zfs, zpool types and branded zones support to the zones type
Added uninstall functionality to yum provider
Added preseed support to apt provider’s uninstall and purge functions
Added versionable feature to the RPM provider
Replaced SELInux calls to binaries with Ruby SELinux bindings
Updates to the Nagios types
Language and Facts
Added support for @doc type and manifest documentation support
Added multiline comment support
Classes and nodes should set $name variables
Functions
Add inline_template function
Stored Configuration
The environment has been added to the stored configuration database structure. You will need to specify the dbmigrate = true in your puppet.conf to ensure your database is upgraded to the new schema.
Errata
1922: Severe breakage when using parser functions with complex
arguments.
0.24.6
Dependencies
#1553: Depends on Facter 1.5
Binary and Configuration
Added —detailed-exits option to puppet binary that adds specific exit codes after runs.
Log messages are now tagged with the log level, making it easier to match messages in the tagmail report.
Added support for running Puppet inside a Rack application (mod_rails) with Passenger and Apache
Fixed the puppetca —clean —all binary so that both signed and unsigned certificates are cleaned.
Moved individual functions out of functions.rb into lib/puppet/parser/functions directory. New functions should be created in this directory.
Added the -P/—ping option to puppetrun.
Allow specification of —bindir —sbindir —sitelibdir —mandir —destdir in installation
Language and Facts
Allow multiple overrides in one statement
Fixed #1585 – Allow complex ‘if’ and variable expressions
Fixed #1584 – Added support for appended variables
Types and Providers
Feature #1624 – Added RBAC roles to solaris user provider
Fixed #1586 – Specifying “fully qualified” package names in Gentoo
Fixed #1530 – ssh_authorized_keys provider does not crash anymore on SSH type 1 keys
Fixes #1455 – Adds HP-UX support for user type
Added daemontools and runit providers for service type
Fixed #1508 – Added HP-UX package provider
Fixed #1456 – add proxy configuration capability to yum repo
0.24.5
Binary and Configuration
Added the catalog_format configuration option which accepts the yaml or marshal options. This option allows you to switch the catalog formatting from YAML to Marshal. Marshal formatting should provide significant performance enhancement over YAML.
The return code from waitpid now right shifted 8 bits.
Added support for the —all option to puppetca —clean. If puppetca —clean —all is issued then all client certificates are removed.
Environments
The default environment is now production.
Types and Providers
The interface type is buggy and has been disabled.
A native type type for managing ssh authorized_keys files is available
The gem package type can now specify source repositories.
The service type now supports HP-UX.
On Red Hat instead of deleting the init scripts (with chkconfig —del) we disable it with chkconfig service off, and do the same for enable => true;
Added LDAP providers for users and groups.
Functions
Added SHA1 function from DavidS to core
Language and Facts
Facts in plugin directories should now be autoloaded, as long as you’re using Facter 1.5.
Aliases to titles now work for resources.
Modified the ‘factpath’ setting to automatically configure Facter to load facts there if a new enough version of Facter is used.
Modules
Templates in the templatedir are preferred to module templates.
LDAP
Removed support for the ‘node_name’ setting in LDAP and external node lookups.
Nodes
Removed support for ‘default’ nodes in external nodes. LDAP nodes now use the certificate name, the short name, and ‘default’, but external nodes just use the certificate name and any custom terminus types will use just the certificate name.
Virtual and Exported/Collected Resources
Exporting or collecting resources no longer raises an exception when no storeconfigs is enabled, it just produces a warning.
0.24.4
Binary and Configuration
The http keep-alive is now disabled by default. There is now a constant in Puppet::Network::HttpPool that will disable or enable this feature but it you enable it you may be at risk of corruption, especially in file serving.
The yamldir is automatically created by the server now that it’s in the puppetmasterd section rather than a separate yaml section.
Types and Providers
In the OpenBSD package provider, assume a source ending in a / indicates it is a directory, and pass it to pkg_add via PKG_PATH. Allows pkg_add to resolve dependencies, and make it possible to specify packages without version numbers.
Provider suitability is now checked at resource evaluation time, rather than resource instantiation time. This means that you don’t catch your “errors” as early, but it also means you should be able to realistically configure a whole host in one run.
Documentation
Puppet now has man pages available. These are recreated at each release. They are located in the man directory and are installed into mandir.
0.24.3
Languages and Facts
Downloading plugins and facts now ignores noop. Note that this changes the behaviour of a resource’s noop setting. The resources noop setting will now alway override the global setting (previously, whichever was true would win).
Host names can now have dashes anywhere.
Binaries and Configuration
The CA serial file will no longer ever be owned by root.
External Nodes
External node commands can specify an environment and Puppet will now use it.
LDAP Nodes
LDAP nodes now support environments, and the schema has been updated accordingly.
0.24.2
Plugins
Autoloading now searches the plugins directory in each module, in addition to the libdir directory. The libdir directory is also deprecated, but supported for now to give people a chance to convert.
Virtual Resources
Virtual defined types are no longer evaluated. This introduces a behaviour change, in that you previously could realize a resource within a virtual defined resource, and now you must realize the entire defined resource, rather than just the contained resource.
Tags
The full name of qualified classes and the class parts are now added as tags. This is supported by the new Tagging module.
Binaries and Configuration
The rundir directory permissions are again set to 1777.
The yamldir setting has been moved to its own yaml section. This should keep the yamldir from being created on clients.
Language and Facts
Classes can once again be included multiple times.
Exec resources must now have unique names, although the commands can still be duplicated. This is easily accomplished by just specifying a unique name with whatever (unique or otherwise) command you need.
There is a change in Puppet’s parser – the order of statement evaluation is no longer changed. This means case statements can now set variables that can be used by other variables.
Types and Providers
Added built-in support for Nagios types using Naginator to parse and generate the files.
The package type (and Puppet overall) is now compatible with gems 1.0.1.
You can now copy links using the file type.
Removed the loglevels from the valid values for logoutput in the exec resource type — the log levels are specified using the loglevel parameter, not logoutput.
0.24.1
Binaries and Configuration
Removed the ability to disable http keep-alive.
Removed warning about deprecated explicit plugins mounts.
0.24.0 (misspiggy)
External Nodes
External node support now requires that you set the node_terminus setting to exec:
node_terminus = exec
External nodes can now co-exist with manifest-based nodes. Previously you had to select one or the other.
LDAP Nodes
LDAP nodes can now co-exist with manifest-based nodes. Previously you had to select one or the other.
Plugins
Added plugins mount – see PluginsInModules on the wiki for information.
Certificates
Certificates now always specify a subjectAltName, but it defaults to *`, meaning that it doesn’t require DNS names to match. You can override that behaviour by specifying a value for the ``certdnsnames configuration option which will then require that hostname as a match.
The behaviour of the certdnsnames setting has changed. It now defaults to an empty string, and will only be used if it is set to something else. If it is set, then the host’s FQDN will also be added as an alias. The default behaviour is now to add puppet and puppet.$domain as DNS aliases when the name for the cert being signed is equal to the signing machine’s name, which will only be the case for CA servers. This should result in servers always having the alias set up and no one else, but you can still override the aliases if you want.
Mongrel
Changed the behaviour of —debug to include Mongrel client debugging information. Mongrel output will be written to the terminal only, not to the puppet debug log.
Language and Facts
The node scope is now above all other scopes besides the main scope, which should help make its variables visible to other classes, assuming those classes were not included in the node’s parent.
Relationship metaparameters :notify, :require, :subscribe, and :before now stack when they are collecting metaparameter values from their containers. For instance, if a resource inside a definition has a value set for require, and you call the definition with require, the resource gets both requires, where before it would only retain its initial value.
Binaries and Configuration
Added the —no-daemonize option to puppetd and puppetmasterd which prevents both binaries from daemonizing. If you use daemontools or runit you must pass the —no-daemonize to puppetd and puppetmasterd. Additionally, the default behavior of —verbose and —debug no longer cause puppetd and puppetmasterd to not daemonize.
The —use-nodes and —no-nodes options are now obsolete. Puppet automatically detects when nodes are defined, and if they are defined it will require that a node be found, else it will not look for a node nor will it fail if it fails to find one.
You now must specify an environment and you are required to specify the valid environments for your site.
The http_enable_post_connection_check added as a configuration option for puppetd. This defaults to true, which validates the server SSL certificate against the requested host name in new versions of Ruby.
Types and Providers
Added k5login type.
Removed type and running as valid attributes from the service types as they are both deprecated.
Modified how services manage their list of paths. Services now default to the paths specified by the provider classes.
0.23.2
Binaries and Configuration
The —gen_config option now generates a configuration with all parameters under a heading that matches the relevant process name, rather than keeping section headings.
Types and Providers
Added support for managing interfaces on Red Hat.
0.23.1 (beaker)
Language and Facts
You can now specify relationships to classes, which work exactly like relationships to defined types:
require => Class[myclass]
This works with qualified classes, too.
Added the +> syntax to resources, so parameter values can be added to.
Hostnames can now be double quoted.
Both class and node names must both now be unique, for example you cannot have a node and class with the same name.
Exported/Collected Resources
You can now do simple queries in a collection of exported resources. You still cannot do multi-condition queries, though.
Binaries and Configuration
Running puppetca with —clean now exits with a non-zero code if it cannot find any host certificates to clean.
The Rails log level can now be set via the rails_loglevel parameter.
Puppet clients now have http proxy support.
Types and Providers
Added the maillist type for managing mailing lists.
Added a mailalias type for managing mail aliases.
Modules
Added autoloading of modules – you can now ‘include’ classes from modules without ever needing to specifically load them.
Plugins
The configuration client now pulls libraries down to $libdir, and all autoloading is done from there with full support for any reloadable file, such as types and providers. This is not backward compatible — if you’re using pluginsync you’ll need to disable it on your clients until you can upgrade them.
0.23.0
Functions
Fixed functions so that they accept most other rvalues as valid values.
Nodes
From 0.23.0 only ONE node source can be used – you can either use LDAP, code, or an external node program, but not more than one.
LDAP Nodes
LDAP node support has two changes, first, the “ldapattrs” attribute is now used for setting the attributes to retrieve from the server (in addition to required attributes), and second, all retrieved attributes are set as variables in the top scope. This means you can set attributes on your LDAP nodes and they will automatically appear as variables in your configurations.
External Nodes
External node support has been completely rewritten – this breaks compatibility with earlier versions and older external node scripts will not work. External node scripts must now generate a YAML dump of a hash, with “classes” and “parameters” keys. The classes should be an array, and the parameters should be a hash. The external node program has no support for parent nodes — the script must handle that on its own.
Stored Configuration
Reworked the database schema used to store configurations with the —storeconfigs option.
File Locations
Changed the location of the classes.txt to the state directory.
Moved puppetd and puppetmasterd to sbin.
Types and Providers
Added a package provider called appdmg able to install .app packages on .dmg files on OS X.
Added fink package provider (#642), as provided by ‘do’.
Marked the dpkg package provider as versionable (#647).
Language and Facts
Added an ‘undef’ keyword, which will evaluate to “” within strings but when used as a resource parameter value will cause that parameter to be evaluated as undefined.
Tags, definitions, and classes can now be a single character.
Binaries and Configuration
Significantly reworking configuration parsing. Executables all now look for puppet.conf rather than the older configuration binary-specific configuration files. The old-style configuration files will be parsed if they are present, although they throw a deprecation warning.
Transaction summaries are now available with the —summarize option. These are useful for getting a quick idea of what happened in a transaction. Currently only useful on the client or with the puppet interpreter.
Added the dynamicfact configuration option; any facts in a comma-separated list will be ignored when comparing facts to see if they have changed and thus whether a recompile is necessary.
Added a splay option to randomly distribute client connections. The value is random but cached. It defaults to the runinterval but can be tuned with —splaylimit. It’s disabled when running under —test in puppetd.
0.22.4
Modules
Modules no longer return directories in the list of found manifests.
Types and Providers
The crontab provider now defaults to root when there is no USER set in the environment.
The useradd provider for the user type can now manage passwords. No other providers can, at this point.
Language and Facts
Added a syntax for referring to variables defined in other classes (e.g., $puppet::server).
0.22.3
Binaries and Configuration
Added a stand-alone filebucket client, named filebucket.
Types and Providers
The -M option is no longer added when home directories are being managed on Red Hat with the user type.
0.22.2 (grover)
Language and Facts
Definitions now support both ‘name’ and ‘title’, just like any other resource type.
Import statements can now specify multiple comma-separated arguments:
import apache, mongrel, squid
Changed the servername fact set on the server to use the server’s fqdn, instead of the short-name.
File Locations
Changing the location of the configuration cache. It now defaults to being in the state directory, rather than in the configuration directory.
Mongrel
Support for Mongrel added. Currently you need to start each individual process and it requires you setup a proxy in front of the mongrel processes.
Binaries and Configuration
Renamed x2puppet to ralsh.
The bind address for puppetmasterd can now be specified with —bindaddress.
Added the ignorecache option to tell puppetd to ignore the cache and force a recompile.
Certificate Authorities
You can now run seperate Certificate Authorities rather than using the inbuilt CA.
Functions
Added a file() function to read in files with no interpolation. The first found file has its content returned.
Added the generate() function which sets values to the result of an external command.
Functions can now be called with no arguments.
Types and Providers
When doing file recursion, ensure only affects the top-level directory.
Users can now manage their home directories, using the managehome parameter.
Using the package type you can now purge apt and dpkg packages.
Made up2date the default for RHEL < 4 and yum the default for the rest.
The yum provider now supports versions.
Switched apt/aptitide to using “apt-cache policy” instead of “apt-cache showpkg” for determining the latest available version.
States have been renamed to Properties.
0.22.1 (kermit)
Resource Relationships
Explicit relationships now override automatic relationships, allowing you to manually specify deletion order when removing resources.
Resources with dependencies can now be deleted as long as all of their dependencies are also being deleted.
Language and Facts
Downcasing of facts can be selectively disabled.
Types and Providers
The netinfo mounts provider was commented out, because it really doesn’t work at all.
0.22.0
Types and Providers
Added the resources type which includes the ability to purge unwanted resources.
All providers now directly execute commands instead of going through a sub-shell – this means arguments don’t need to be quoted or escaped.
Stored Configuration
Export and collect updated making the database incompatible with the 0.20 version. You will need to re-create your database.
Language and Facts
Facts are no longer down-cased and the language is case-insensitive.
0.20.0
Virtual and Exported/Collected Resources
Virtual resources are now represented by single sigils, @user, and exported/collected resources are represented by double sigils, @@sshkey.
Resource Relationships
Resources relationships are now identified by capitalizing the resource like so:
File["/etc/passwd"]