Deprecated Resource Type Features

Included in Puppet Enterprise 3.8. A newer version is available; see the version menu above for details.

The following features of Puppet’s built-in resource types are deprecated, and will be removed in Puppet 4.0.

file

Non-String mode Values

Now

The file type’s mode attribute will accept both numbers and strings to represent numeric permissions (like 0644).

In Puppet 4.0

Numeric modes must be represented as quoted strings. Un-quoted numbers in the mode attribute will raise a compilation error.

    file { '/etc/sudoers':
      ensure => file,
      # BAD:
      mode   => 0400,
      # GOOD:
      mode   => '0400',
    }

Detecting and Updating

If you are using unquoted numbers in the mode attribute, Puppet will log the following deprecation warning on the Puppet master:

Warning: Non-string values for the file mode property are deprecated. It must be a string, either a symbolic mode like 'o+w,a+r' or an octal representation like '0644' or '755'.

Context

In the Puppet 4 language, numbers starting with 0 are interpreted as octal, but they get converted to decimal once they reach resource types and providers. This could cause bizarre file modes, so we now prevent it.

Default Copying of Source Permissions

Now

If a file resource uses the source attribute and doesn’t specify any of the owner, group, or mode attributes, Puppet will default to using the ownership and permissions from the source file, which is usually a file from a Puppet module. You can use the source_permissions attribute to override this behavior.

In Puppet 4.0

Puppet will not default to using ownership and permissions from the source file. If you wish to copy the source permissions, you can opt in using the source_permissions attribute.

In other words, the default value of source_permissions will change from use to ignore.

Detecting and Updating

Puppet will not log deprecation warnings if you use this feature.

If you were implicitly relying on copied source permissions, you may need to re-examine all of your file resources. But for most users’ files, the new default permissions (puppet agent’s user and that user’s default umask or DACL) will be just as appropriate as the source permissions.

If you identify any files that DID rely on source permissions, you can:

  • Set source_permissions => use on the affected files
  • Explicitly set ownership and permissions on the affected files
  • Set a resource default in the main manifest to restore Puppet’s 3.x behavior in 4.x (e.g. File { source_permissions => use })

Context

Nonsensical *nix permissions being copied to Windows nodes revealed the problems with this default behavior. After we considered it further, we decided that most module files probably don’t have meaningful permissions in the first place, and use of the source permissions should be the exception rather than the rule.

recurse => inf

Now

The file type’s recurse attribute allows a value of inf. (It’s a synonym for true.)

In Puppet 4.0

Setting recurse => inf will cause a compilation error.

Detecting and Updating

Puppet will not log deprecation warnings if you use this feature.

Instead, do a global search of your Puppet code, making sure to handle varying whitespace and quoting. Use a regex-supporting search tool and search for something like:

recurse\s*=>\s*['"]?inf

Replace any occurrences with recurse => true.

Context

The behavior of recurse and recurselimit used to both be crammed into the recurse attribute, which could be set to numbers and inf in addition to its current values. Now that they’re handled separately, inf is nonsensical as a value for recurse.

cron

Conservative Purging of Cron Resources

Now

If you purge unmanaged cron resources, like so:

    resources { 'cron':
      purge => true,
    }

…then Puppet will only delete cron jobs from its own user’s crontab file. (Usually, puppet agent’s user is root.)

In Puppet 4.0

If you purge unmanaged cron resources, Puppet will purge cron jobs from every user’s crontab file.

Detecting and Updating

If you are purging cron jobs, Puppet will log the following change warning:

Warning: Change notice: purging cron entries will be more aggressive in future versions, take care when updating your agents. See http://links.puppetlabs.com/puppet-aggressive-cron-purge

Context

We’ve found that users expect “purge” to mean “PURGE,” especially since Puppet can manage cron jobs for any user.

package

Old msi Package Provider

Now

Puppet includes a less useful msi package provider, in addition to the more flexible windows provider (which duplicates all of the msi provider’s features).

In Puppet 4.0

Goodbye, msi provider! Use the windows provider instead.

Detecting and Updating

Puppet will not log deprecation warnings if you use this feature.

If you never specified a provider for your Windows packages, they’re already using the windows provider, since msi is no longer the default. To find any packages that do specify msi, do a global search of your Puppet code, making sure to handle varying whitespace and quoting. Use a regex-supporting search tool and search for something like:

provider\s*=>\s*['"]?msi

Replace or delete any occurrences.

Context

Having a single Windows package provider that handles both MSIs and executable installers turned out to be much nicer.

↑ Back to top