Type Reference

Table of Contents 1. Meta-Parameters 1. Cron 1. Exec 1. File 1. Filebucket 1. Group 1. Host 1. Mount 1. Notify 1. Package 1. Resources 1. Schedule 1. Service 1. Sshkey 1. Tidy 1. User 1. Yumrepo 1. Zone

Meta-Parameters

Metaparameters are parameters that work with any element; 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.

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

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 name, and the library sets that as an alias for the file so the dependency lookup for ``sshd`` works. You can use this parameter 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 tutorial for more information.

languagetutorial.html

before 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 Propertys which should have their values retrieved but which should not actually be modified. This is currently used internally, but will eventually be used for querying, so that you could specify that you wanted to check the install state of all packages, and then query the Puppet client daemon to get reports on all packages.

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 This parameter is the opposite of subscribe—it sends events to the specified object:

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 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"]
}

Note that Puppet will autorequire everything that it can, and there are hooks in place so that it’s easy for elements 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 elements 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.

subscribe One or more objects that this object depends on. Changes in the subscribed to objects result in the dependent objects being refreshed (e.g., a service will get restarted). For instance:

class nagios {
    file { "/etc/nagios/nagios.conf":
        source => "puppet://server/module/nagios.conf",
        alias => nagconf # just to make things easier for me
    }
    service { nagios:
        running => true,
        subscribe => file[nagconf]
    }
}

Currently the ``exec``, ``mount`` and ``service`` type support refreshing.

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

Tags are currently useful for things like applying a subset of a host’s configuration:

puppetd --test --tag mytag

This way, when you’re testing a configuration you can run just the portion you’re testing.

Types

- namevar is the parameter used to uniquely identify a type instance. This is the parameter that gets assigned when a string is provided before the colon in a type declaration. In general, only developers will need to worry about which parameter is the ``namevar``.

In the following code:

file { "/etc/passwd":
    owner => root,
    group => root,
    mode => 644
}

"/etc/passwd" is considered the name of the file object (used for things like
dependency handling), and because ``path`` is the namevar for ``file``, that
string is assigned to the ``path`` parameter.

- parameters determine the specific configuration of the instance. They either directly modify the system (internally, these are called properties) or they affect how the instance behaves (e.g., adding a search path for ``exec`` instances or determining recursion on ``file`` instances).

- providers provide low-level functionality for a given resource type. This is usually in the form of calling out to external commands.

When required binaries are specified for providers, fully qualifed paths
indicate that the binary must exist at that specific path and unqualified
binaries indicate that Puppet will search for the binary using the shell
path.

Resource types define features they can use, and providers can be tested to see
which features they provide.

Site menu:

Puppet Thoughts