Metaparameter Reference

This version of Puppet is not included in Puppet Enterprise. The latest version of PE includes Puppet 4.10. A newer version is available; see the version menu above for details.

Metaparameter Reference

This page is autogenerated; any changes will get overwritten (last generated on Thu Sep 05 14:13:25 -0700 2013)

Metaparameters

Metaparameters are parameters that work with any resource type; they are part of the Puppet framework itself rather than being part of the implementation of any given instance. Thus, any defined metaparameter can be used with any instance in your manifest, including defined components.

Available Metaparameters

alias

Creates an alias for the object. Puppet uses this internally when you provide a symbolic title:

file { 'sshdconfig':
  path => $operatingsystem ? {
    solaris => "/usr/local/etc/ssh/sshd_config",
    default => "/etc/ssh/sshd_config"
  },
  source => "..."
}

service { 'sshd':
  subscribe => File['sshdconfig']
}

When you use this feature, the parser sets sshdconfig as the title, and the library sets that as an alias for the file so the dependency lookup in Service['sshd'] works. You can use this metaparameter yourself, but note that only the library can use these aliases; for instance, the following code will not work:

file { "/etc/ssh/sshd_config":
  owner => root,
  group => root,
  alias => 'sshdconfig'
}

file { 'sshdconfig':
  mode => 644
}

There’s no way here for the Puppet parser to know that these two stanzas should be affecting the same file.

See the Language Guide for more information.

audit

Marks a subset of this resource’s unmanaged attributes for auditing. Accepts an attribute name, an array of attribute names, or all.

Auditing a resource attribute has two effects: First, whenever a catalog is applied with puppet apply or puppet agent, Puppet will check whether that attribute of the resource has been modified, comparing its current value to the previous run; any change will be logged alongside any actions performed by Puppet while applying the catalog.

Secondly, marking a resource attribute for auditing will include that attribute in inspection reports generated by puppet inspect; see the puppet inspect documentation for more details.

Managed attributes for a resource can also be audited, but note that changes made by Puppet will be logged as additional modifications. (I.e. if a user manually edits a file whose contents are audited and managed, puppet agent’s next two runs will both log an audit notice: the first run will log the user’s edit and then revert the file to the desired state, and the second run will log the edit made by Puppet.)

before

References to one or more objects that depend on this object. This parameter is the opposite of require — it guarantees that the specified object is applied later than the specifying object:

file { "/var/nagios/configuration":
  source  => "...",
  recurse => true,
  before  => Exec["nagios-rebuid"]
}

exec { "nagios-rebuild":
  command => "/usr/bin/make",
  cwd     => "/var/nagios/configuration"
}

This will make sure all of the files are up to date before the make command is run.

check

Audit specified attributes of resources over time, and report if any have changed. This parameter has been deprecated in favor of ‘audit’.

loglevel

Sets the level that information will be logged. The log levels have the biggest impact when logs are sent to syslog (which is currently the default). Valid values are debug, info, notice, warning, err, alert, emerg, crit, verbose.

noop

Boolean flag indicating whether work should actually be done. Valid values are true, false.

notify

References to one or more objects that depend on this object. This parameter is the opposite of subscribe — it creates a dependency relationship like before, and also causes the dependent object(s) to be refreshed when this object is changed. For instance:

  file { "/etc/sshd_config":
    source => "....",
    notify => Service['sshd']
  }

  service { 'sshd':
    ensure => running
  }

This will restart the sshd service if the sshd config file changes.

require

References to one or more objects that this object depends on. This is used purely for guaranteeing that changes to required objects happen before the dependent object. For instance:

# Create the destination directory before you copy things down
file { "/usr/local/scripts":
  ensure => directory
}

file { "/usr/local/scripts/myscript":
  source  => "puppet://server/module/myscript",
  mode    => 755,
  require => File["/usr/local/scripts"]
}

Multiple dependencies can be specified by providing a comma-separated list of resources, enclosed in square brackets:

require => [ File["/usr/local"], File["/usr/local/scripts"] ]

Note that Puppet will autorequire everything that it can, and there are hooks in place so that it’s easy for resources to add new ways to autorequire objects, so if you think Puppet could be smarter here, let us know.

In fact, the above code was redundant — Puppet will autorequire any parent directories that are being managed; it will automatically realize that the parent directory should be created before the script is pulled down.

Currently, exec resources will autorequire their CWD (if it is specified) plus any fully qualified paths that appear in the command. For instance, if you had an exec command that ran the myscript mentioned above, the above code that pulls the file down would be automatically listed as a requirement to the exec code, so that you would always be running againts the most recent version.

schedule

On what schedule the object should be managed. You must create a schedule object, and then reference the name of that object to use that for your schedule:

schedule { 'daily':
  period => daily,
  range  => "2-4"
}

exec { "/usr/bin/apt-get update":
  schedule => 'daily'
}

The creation of the schedule object does not need to appear in the configuration before objects that use it.

stage

Which run stage a given resource should reside in. This just creates a dependency on or from the named milestone. For instance, saying that this is in the ‘bootstrap’ stage creates a dependency on the ‘bootstrap’ milestone.

By default, all classes get directly added to the ‘main’ stage. You can create new stages as resources:

stage { ['pre', 'post']: }

To order stages, use standard relationships:

stage { 'pre': before => Stage['main'] }

Or use the new relationship syntax:

Stage['pre'] -> Stage['main'] -> Stage['post']

Then use the new class parameters to specify a stage:

class { 'foo': stage => 'pre' }

Stages can only be set on classes, not individual resources. This will fail:

file { '/foo': stage => 'pre', ensure => file }

subscribe

References to one or more objects that this object depends on. This metaparameter creates a dependency relationship like require, and also causes the dependent object to be refreshed when the subscribed object is changed. For instance:

class nagios {
  file { 'nagconf':
    path   => "/etc/nagios/nagios.conf"
    source => "puppet://server/module/nagios.conf",
  }
  service { 'nagios':
    ensure    => running,
    subscribe => File['nagconf']
  }
}

Currently the exec, mount and service types support refreshing.

tag

Add the specified tags to the associated resource. While all resources are automatically tagged with as much information as possible (e.g., each class and definition containing the resource), it can be useful to add your own tags to a given resource.

Multiple tags can be specified as an array:

file {'/etc/hosts':
  ensure => file,
  source => 'puppet:///modules/site/hosts',
  mode   => 0644,
  tag    => ['bootstrap', 'minimumrun', 'mediumrun'],
}

Tags are useful for things like applying a subset of a host’s configuration with the tags setting:

puppet agent --test --tags bootstrap

This way, you can easily isolate the portion of the configuration you’re trying to test.


This page autogenerated on Thu Sep 05 14:13:27 -0700 2013

↑ Back to top