Whether specified attribute value pairs should be treated as the complete list (inclusive) or the minimum list (minimum) of attribute/value pairs for the user. Defaults to minimum.

Whether the user is a system user, according to the OS's criteria; on most platforms, a UID less than or equal to 500 indicates a system user. Defaults to false.

Whether specified key/value pairs should be considered the complete list (inclusive) or the minimum list (minimum) of the user's attributes. Defaults to minimum.

Whether specified groups should be considered the complete list (inclusive) or the minimum list (minimum) of groups to which the user belongs. Defaults to minimum.

Whether specified roles should be treated as the complete list (inclusive) or the minimum list (minimum) of roles of which the user is a member. Defaults to minimum.

The user name. While naming limitations vary by operating system, it is advisable to restrict names to the lowest common denominator, which is a maximum of 8 characters beginning with a letter.

    Note that Puppet considers user names to be case-sensitive, regardless
    of the platform's own rules; be sure to always use the same case when
    referring to a given user.

Whether to allow duplicate UIDs. Defaults to false.

Whether specified auths should be considered the complete list (inclusive) or the minimum list (minimum) of auths the user has. Defaults to minimum.

Whether specified roles should be considered the complete list (inclusive) or the minimum list (minimum) of roles the user has. Defaults to minimum.

The name of the I&A module to use to manage this user.

Whether to manage the home directory when managing the user. Defaults to false.

The user ID; must be specified numerically. If no user ID is specified when creating a new user, then one will be chosen automatically. This will likely result in the same user having different UIDs on different systems, which is not recommended. This is especially noteworthy when managing the same user on both Darwin and other platforms, since Puppet does UID generation on Darwin, but the underlying tools do so on other platforms.

    On Windows, this property is read-only and will return the user's
    security identifier (SID).

The minimum number of days a password must be used before it may be changed.

The home directory of the user. The directory must be created separately and is not currently checked for existence.

The user's login shell. The shell must exist and be executable.

    This attribute cannot be managed on Windows systems.

The auths the user has. Multiple auths should be specified as an array.

Specify user attributes in an array of key = value pairs.

The user's password, in whatever encrypted format the local system requires.

    * Most modern Unix-like systems use salted SHA1 password hashes. You can use
      Puppet's built-in `sha1` function to generate a hash from a password.
    * Mac OS X 10.5 and 10.6 also use salted SHA1 hashes.
    * Mac OS X 10.7 (Lion) uses salted SHA512 hashes. The Puppet Labs [stdlib][]
      module contains a `str2saltedsha512` function which can generate password
      hashes for Lion.
    * Windows passwords can only be managed in cleartext, as there is no Windows API
      for setting the password hash.

    [stdlib]: https://github.com/puppetlabs/puppetlabs-stdlib/

    Be sure to enclose any value that includes a dollar sign ($) in single
    quotes (') to avoid accidental variable interpolation.

The expiry date for this user. Must be provided in a zero-padded YYYY-MM-DD format --- e.g. 2010-02-19.

The name of the project associated with a user.

The maximum number of days a password may be used before it must be changed.

The roles the user has. Multiple roles should be specified as an array.

The user's primary group. Can be specified numerically or by name.

    Note that users on Windows systems do not have a primary group; manage groups
    with the `groups` attribute instead.

Specify AIX attributes for the user in an array of attribute = value pairs.

The profiles the user has. Multiple profiles should be specified as an array.

A description of the user. Generally the user's full name.

The groups to which the user belongs. The primary group should not be listed, and groups should be identified by name rather than by GID. Multiple groups should be specified as an array.

The basic state that the object should be in.

User management for AIX.

User management for HP-UX. This provider uses the undocumented -F switch to HP-UX's special usermod binary to work around the fact that its standard usermod cannot make changes while the user is logged in.

User management via pw on FreeBSD.

Local user management for Windows.

User management via useradd and its ilk. Note that you will need to install Ruby's shadow password library (often known as ruby-libshadow) if you wish to manage user passwords.

User management via LDAP.

This provider requires that you have valid values for all of the
LDAP-related settings in `puppet.conf`, including `ldapbase`.  You will
almost definitely need settings for `ldapuser` and `ldappassword` in order
for your clients to write to LDAP.

Note that this provider will automatically generate a UID for you if
you do not specify one, but it is a potentially expensive operation,
as it iterates across all existing users to pick the appropriate next one.

User and role management on Solaris, via useradd and roleadd.

User management using DirectoryService on OS X.

The full name for this filesystem (including the zpool).

The sharenfs property. Valid values are on, off, share(1M) options

The volsize property. Valid values are <size>

The atime property. Valid values are on, off.

The aclmode property. Valid values are discard, groupmask, passthrough.

The xattr property. Valid values are on, off.

The checksum property. Valid values are on, off, fletcher2, fletcher4, sha256.

The setuid property. Valid values are on, off.

The version property. Valid values are 1, 2, 3, 4, current.

The shareiscsi property. Valid values are on, off, type=<type>.

The recordsize property. Valid values are powers of two between 512 and 128k.

The secondarycache property. Valid values are all, none, metadata.

The quota property. Valid values are <size>, none.

The zoned property. Valid values are on, off.

The aclinherit property. Valid values are discard, noallow, restricted, passthrough, passthrough-x.

The canmount property. Valid values are on, off, noauto.

The sharesmb property. Valid values are on, off, sharemgr(1M) options

The compression property. Valid values are on, off, lzjb, gzip, gzip-[1-9], zle.

The primarycache property. Valid values are all, none, metadata.

The nbmand property. Valid values are on, off.

The snapdir property. Valid values are hidden, visible.

The copies property. Valid values are 1, 2, 3.

The mountpoint property. Valid values are <path>, legacy, none.

The logbias property. Valid values are latency, throughput.

The reservation property. Valid values are <size>, none.

The refquota property. Valid values are <size>, none.

The refreservation property. Valid values are <size>, none.

The exec property. Valid values are on, off.

The devices property. Valid values are on, off.

The vscan property. Valid values are on, off.

The readonly property. Valid values are on, off.

Provider for Solaris zfs.

The host name that the key is associated with.

The file in which to store the ssh key. Only used by the parsed provider.

The encryption type used. Probably ssh-dss or ssh-rsa.

The key itself; generally a long string of hex digits.

Any aliases the host might have. Multiple values must be specified as an array.

Parse and generate host-wide known hosts files for SSH.

The name of the resource being managed. The default naming convention follows Directory Service paths:

    /Computers/localhost
    /Groups/admin
    /Users/localadmin

The `ds_type` and `ds_name` type parameters are not necessary if the
default naming convention is followed.

The DirectoryService type this MCX setting attaches to.

The name to attach the MCX Setting to. (For example, localhost when ds_type => computer.) This setting is not required, as it can be automatically discovered when the resource name is parseable. (For example, in /Groups/admin, group will be used as the dstype.)

Create or remove the MCX setting.

The XML Plist used as the value of MCXSettings in DirectoryService. This is the standard output from the system command:

    dscl localhost -mcxexport /Local/Default/<ds_type>/ds_name

Note that `ds_type` is capitalized and plural in the dscl command.

MCX Settings management using DirectoryService on OS X.

This provider manages the entire MCXSettings attribute available to some directory services nodes. This management is 'all or nothing' in that discrete application domain key value pairs are not managed by this provider.

It is recommended to use WorkGroup Manager to configure Users, Groups, Computers, or ComputerLists, then use 'ralsh mcx' to generate a puppet manifest from the resulting configuration.

Original Author: Jeff McCune (mccune.jeff@gmail.com)

The name of the filebucket.

The path to the local filebucket. If this is unset, then the bucket is remote. The parameter server must can be specified to set the remote server.

The server providing the remote filebucket. If this is not specified then path is checked. If it is set, then the bucket is local. Otherwise the puppetmaster server specified in the config or at the commandline is used.

    Due to a known issue, you currently must set the `path` attribute to
    false if you wish to specify a `server` attribute.

The host name.

The file in which to store service information. Only used by those providers that write to disk. On most systems this defaults to /etc/hosts.

A comment that will be attached to the line with a # character.

Any aliases the host might have. Multiple values must be specified as an array.

The host's IP address, IPv4 or IPv6.

The name assigned to the scheduled task. This will uniquely identify the task on the system.

The password for the user specified in the 'user' attribute. This is only used if specifying a user other than 'SYSTEM'. Since there is no way to retrieve the password used to set the account information for a task, this parameter will not be used to determine if a scheduled task is in sync or not.

One or more triggers defining when the task should run. A single trigger is represented as a hash, and multiple triggers can be specified with an array of hashes.

  A trigger can contain the following keys:

  * For all triggers:
      * `schedule` **(Required)** --- The schedule type. Valid values are
        `daily`, `weekly`, `monthly`, or `once`.
      * `start_time` **(Required)** --- The time of day when the trigger should
        first become active. Several time formats will work, but we
        suggest 24-hour time formatted as HH:MM.
      * `start_date` ---  The date when the trigger should first become active.
        Defaults to "today." Several date formats will work, including
        special dates like "today," but we suggest formatting dates as
        YYYY-MM-DD.
  * For daily triggers:
      * `every` --- How often the task should run, as a number of days. Defaults
        to 1. ("2" means every other day, "3" means every three days, etc.)
  * For weekly triggers:
      * `every` --- How often the task should run, as a number of weeks. Defaults
        to 1. ("2" means every other week, "3" means every three weeks, etc.)
      * `day_of_week` --- Which days of the week the task should run, as an array.
        Defaults to all days. Each day must be one of `mon`, `tues`,
        `wed`, `thurs`, `fri`, `sat`, `sun`, or `all`.
  * For monthly-by-date triggers:
      * `months` --- Which months the task should run, as an array. Defaults to
        all months. Each month must be an integer between 1 and 12.
      * `on` **(Required)** --- Which days of the month the task should run,
        as an array. Each day must beeither an integer between 1 and 31,
        or the special value `last,` which is always the last day of the month.
  * For monthly-by-weekday triggers:
      * `months` --- Which months the task should run, as an array. Defaults to
        all months. Each month must be an integer between 1 and 12.
      * `day_of_week` **(Required)** --- Which day of the week the task should
        run, as an array with only one element. Each day must be one of `mon`,
        `tues`, `wed`, `thurs`, `fri`, `sat`, `sun`, or `all`.
      * `which_occurrence` **(Required)** --- The occurrence of the chosen weekday
        when the task should run. Must be one of `first`, `second`, `third`,
        `fourth`, `fifth`, or `last`.

  Examples:

      # Run at 8am on the 1st, 15th, and last day of the month in January, March,
      # May, July, September, and November, starting after August 31st, 2011.
      trigger => {
        schedule   => monthly,
        start_date => '2011-08-31',   # Defaults to 'today'
        start_time => '08:00',        # Must be specified
        months     => [1,3,5,7,9,11], # Defaults to all
        on         => [1, 15, last],  # Must be specified
      }

      # Run at 8am on the first Monday of the month for January, March, and May,
      # starting after August 31st, 2011.
      trigger => {
        schedule         => monthly,
        start_date       => '2011-08-31', # Defaults to 'today'
        start_time       => '08:00',      # Must be specified
        months           => [1,3,5],      # Defaults to all
        which_occurrence => first,        # Must be specified
        day_of_week      => [mon],        # Must be specified
      }

Whether the triggers for this task should be enabled. This attribute affects every trigger for the task; triggers cannot be enabled or disabled individually.

Any arguments or flags that should be passed to the command. Multiple arguments should be specified as a space-separated string.

The full path to the application to run, without any arguments.

The full path of the directory in which to start the command.

The user to run the scheduled task as. Please note that not all security configurations will allow running a scheduled task as 'SYSTEM', and saving the scheduled task under these conditions will fail with a reported error of 'The operation completed successfully'. It is recommended that you either choose another user to run the scheduled task, or alter the security policy to allow v1 scheduled tasks to run as the 'SYSTEM' account. Defaults to 'SYSTEM'.

This provider uses the win32-taskscheduler gem to manage scheduled tasks on Windows.

Puppet requires version 0.2.1 or later of the win32-taskscheduler gem;
previous versions can cause "Could not evaluate: The operation completed
successfully" errors.

The name of the stage. This will be used as the 'stage' for each resource.

The numerical ID of the zone. This number is autogenerated and cannot be changed.

Arguments to the zonecfg create command. This can be used to create branded zones.

Instead of installing the zone, clone it from another zone. If the zone root resides on a zfs file system, a snapshot will be used to create the clone; if it resides on a ufs filesystem, a copy of the zone will be used. The zone from which you clone must not be running.

Arguments to the zoneadm install command. This can be used to create branded zones.

The text to go into the sysidcfg file when the zone is first booted. The best way is to use a template:

      # $confdir/modules/site/templates/sysidcfg.erb
      system_locale=en_US
      timezone=GMT
      terminal=xterms
      security_policy=NONE
      root_password=<%= password %>
      timeserver=localhost
      name_service=DNS {domain_name=<%= domain %> name_server=<%= nameserver %>}
      network_interface=primary {hostname=<%= realhostname %>
        ip_address=<%= ip %>
        netmask=<%= netmask %>
        protocol_ipv6=no
        default_route=<%= defaultroute %>}
      nfs4_domain=dynamic

  And then call that:

      zone { myzone:
        ip           => "bge0:192.168.0.23",
        sysidcfg     => template("site/sysidcfg.erb"),
        path         => "/opt/zones/myzone",
        realhostname => "fully.qualified.domain.name"
      }

  The `sysidcfg` only matters on the first booting of the zone,
  so Puppet only checks for it at that time.

The name of the zone.

The root of the zone's filesystem. Must be a fully qualified file name. If you include %s in the path, then it will be replaced with the zone's name. Currently, you cannot use Puppet to move a zone.

The actual hostname of the zone.

The running state of the zone. The valid states directly reflect the states that zoneadm provides. The states are linear, in that a zone must be configured, then installed, and only then can be running. Note also that halt is currently used to stop zones.

Number of FSS CPU shares allocated to the zone.

The list of datasets delegated to the non-global zone from the global zone. All datasets must be zfs filesystem names which are different from the mountpoint.

The resource pool for this zone.

Whether the zone should automatically boot.

The list of directories that the zone inherits from the global zone. All directories must be fully qualified.

The IP stack type of the zone.

The IP address of the zone. IP addresses must be specified with the interface, separated by a colon, e.g.: bge0:192.168.0.1. For multiple interfaces, specify them in an array.

Provider for Solaris Zones.

The mount path for the mount.

The deprecated name for the mount point. Please use name now.

Whether the mount can be remounted mount -o remount. If this is false, then the filesystem will be unmounted and remounted manually, which is prone to failure.

Whether to dump the mount. Not all platform support this. Valid values are 1 or 0. or 2 on FreeBSD, Default is 0.

The mount type. Valid values depend on the operating system. This is a required option.

The device to fsck. This is property is only valid on Solaris, and in most cases will default to the correct value.

Whether to mount the mount at boot. Not all platforms support this.

The file in which to store the mount table. Only used by those providers that write to disk.

The device providing the mount. This can be whatever device is supporting by the mount, including network devices or devices specified by UUID rather than device path, depending on the operating system.

The pass in which the mount is checked.

Mount options for the mounts, as they would appear in the fstab.

Control what to do with this mount. Set this attribute to umounted to make sure the filesystem is in the filesystem table but not mounted (if the filesystem is currently mounted, it will be unmounted). Set it to absent to unmount (if necessary) and remove the filesystem from the fstab. Set to mounted to add it to the fstab and mount it. Set to present to add to fstab but not change mount/unmount status.

An arbitrary tag for your own reference; the name of the message.

Whether to show the full object path. Defaults to false.

The message to be sent to the log.

If set true, SELinux booleans will be written to disk and persist accross reboots. The default is false.

The name of the SELinux boolean to be managed.

Whether the the SELinux boolean should be enabled or disabled.

Manage SELinux booleans using the getsebool and setsebool binaries.

Whether specified attribute value pairs should be treated as the only attributes of the user or whether they should merely be treated as the minimum list.

Whether the group is a system group with lower GID.

The group name. While naming limitations vary by operating system, it is advisable to restrict names to the lowest common denominator, which is a maximum of 8 characters beginning with a letter.

    Note that Puppet considers group names to be case-sensitive, regardless
    of the platform's own rules; be sure to always use the same case when
    referring to a given group.

Whether to allow duplicate GIDs. Defaults to false.

whether the provider is authoritative for group membership.

The name of the I&A module to use to manage this user

Create or remove the group.

The group ID. Must be specified numerically. If no group ID is specified when creating a new group, then one will be chosen automatically according to local system standards. This will likely result in the same group having different GIDs on different systems, which is not recommended.

    On Windows, this property is read-only and will return the group's security
    identifier (SID).

Specify group AIX attributes in an array of key=value pairs.

The members of the group. For directory services where group membership is stored in the group objects, not the users.

Group management for AIX.

Group management via pw on FreeBSD.

Local group management for Windows. Nested groups are not supported.

Group management via LDAP.

This provider requires that you have valid values for all of the
LDAP-related settings in `puppet.conf`, including `ldapbase`.  You will
almost definitely need settings for `ldapuser` and `ldappassword` in order
for your clients to write to LDAP.

Note that this provider will automatically generate a GID for you if you do
not specify one, but it is a potentially expensive operation, as it
iterates across all existing groups to pick the appropriate next one.

Group management via groupadd and its ilk. The default for most platforms.

Group management using DirectoryService on OS X.

The earliest and latest that a resource can be applied. This is always a hyphen-separated range within a 24 hour period, and hours must be specified in numbers between 0 and 23, inclusive. Minutes and seconds can optionally be provided, using the normal colon as a separator. For instance:

        schedule { 'maintenance':
          range => "1:30 - 4:30",
        }

    This is mostly useful for restricting certain resources to being
    applied in maintenance windows or during off-peak hours. Multiple
    ranges can be applied in array context.

The name of the schedule. This name is used to retrieve the schedule when assigning it to an object:

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

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

How often a given resource may be applied in this schedule's period. Defaults to 1; must be an integer.

The period of repetition for a resource. The default is for a resource to get applied every time Puppet runs.

    Note that the period defines how often a given resource will get
    applied but not when; if you would like to restrict the hours
    that a given resource can be applied (e.g., only at night during
    a maintenance window), then use the `range` attribute.

    If the provided periods are not sufficient, you can provide a
    value to the *repeat* attribute, which will cause Puppet to
    schedule the affected resources evenly in the period the
    specified number of times.  Take this schedule:

        schedule { 'veryoften':
          period => hourly,
          repeat => 6,
        }

    This can cause Puppet to apply that resource up to every 10 minutes.

    At the moment, Puppet cannot guarantee that level of
    repetition; that is, it can run up to every 10 minutes, but
    internal factors might prevent it from actually running that
    often (e.g., long-running Puppet runs will squash conflictingly scheduled runs).

    See the `periodmatch` attribute for tuning whether to match
    times by their distance apart or by their specific value.

Whether periods should be matched by number (e.g., the two times are in the same hour) or by distance (e.g., the two times are 60 minutes apart).

Whether to log output. Defaults to logging output at the loglevel for the exec resource. Use on_failure to only log the output when the command reports an error. Values are true, false, on_failure, and any legal log level.

If this parameter is set, then this exec will only run if the command returns 0. For example:

        exec { "logrotate":
          path   => "/usr/bin:/usr/sbin:/bin",
          onlyif => "test `du /var/log/messages | cut -f1` -gt 100000"
        }

    This would run `logrotate` only if that test returned true.

    Note that this command follows the same rules as the main command,
    which is to say that it must be fully qualified if the path is not set.

    Also note that onlyif can take an array as its value, e.g.:

        onlyif => ["test -f /tmp/file1", "test -f /tmp/file2"]

    This will only run the exec if _all_ conditions in the array return true.

The directory from which to run the command. If this directory does not exist, the command will fail.

A file that this command creates. If this parameter is provided, then the command will only be run if the specified file does not exist.

        exec { "tar -xf /Volumes/nfs02/important.tar":
          cwd     => "/var/tmp",
          creates => "/var/tmp/myfile",
          path    => ["/usr/bin", "/usr/sbin"]
        }

    In this example, if `/var/tmp/myfile` is ever deleted, the exec
    will bring it back by re-extracting the tarball.

The command should only be run as a refresh mechanism for when a dependent object is changed. It only makes sense to use this option when this command depends on some other object; it is useful for triggering an action:

        # Pull down the main aliases file
        file { "/etc/aliases":
          source => "puppet://server/module/aliases"
        }

        # Rebuild the database, but only when the file changes
        exec { newaliases:
          path        => ["/usr/bin", "/usr/sbin"],
          subscribe   => File["/etc/aliases"],
          refreshonly => true
        }

    Note that only `subscribe` and `notify` can trigger actions, not `require`,
    so it only makes sense to use `refreshonly` with `subscribe` or `notify`.

Any additional environment variables you want to set for a command. Note that if you use this to set PATH, it will override the path attribute. Multiple environment variables should be specified as an array.

If this parameter is set, then this exec will run unless the command returns 0. For example:

        exec { "/bin/echo root >> /usr/lib/cron/cron.allow":
          path   => "/usr/bin:/usr/sbin:/bin",
          unless => "grep root /usr/lib/cron/cron.allow 2>/dev/null"
        }

    This would add `root` to the cron.allow file (on Solaris) unless
    `grep` determines it's already there.

    Note that this command follows the same rules as the main command,
    which is to say that it must be fully qualified if the path is not set.

The time to sleep in seconds between 'tries'.

The actual command to execute. Must either be fully qualified or a search path for the command must be provided. If the command succeeds, any output produced will be logged at the instance's normal log level (usually notice), but if the command fails (meaning its return code does not match the specified code) then any output is logged at the err log level.

The search path used for command execution. Commands must be fully qualified if no path is specified. Paths can be specified as an array or as a ':' separated list.

The number of times execution of the command should be tried. Defaults to '1'. This many attempts will be made to execute the command until an acceptable return code is returned. Note that the timeout paramater applies to each try rather than to the complete set of tries.

The group to run the command as. This seems to work quite haphazardly on different platforms -- it is a platform issue not a Ruby or Puppet one, since the same variety exists when running commands as different users in the shell.

The user to run the command as. Note that if you use this then any error output is not currently captured. This is because of a bug within Ruby. If you are using Puppet to create this user, the exec will automatically require the user, as long as it is specified by name.

How to refresh this command. By default, the exec is just called again when it receives an event from another resource, but this parameter allows you to define a different command for refreshing.

The maximum time the command should take. If the command takes longer than the timeout, the command is considered to have failed and will be stopped. Use 0 to disable the timeout. The time is specified in seconds.

The expected return code(s). An error will be returned if the executed command returns something else. Defaults to 0. Can be specified as an array of acceptable return codes or a single value.

Passes the provided command through /bin/sh; only available on POSIX systems. This allows the use of shell globbing and built-ins, and does not require that the path to a command be fully-qualified. Although this can be more convenient than the posix provider, it also means that you need to be more careful with escaping; as ever, with great power comes etc. etc.

This provider closely resembles the behavior of the `exec` type
in Puppet 0.25.x.

Execute external binaries on Windows systems. As with the posix provider, this provider directly calls the command with the arguments given, without passing it through a shell or performing any interpolation. To use shell built-ins --- that is, to emulate the shell provider on Windows --- a command must explicitly invoke the shell:

    exec {'echo foo':
      command => 'cmd.exe /c echo "foo"',
    }

If no extension is specified for a command, Windows will use the `PATHEXT`
environment variable to locate the executable.

**Note on PowerShell scripts:** PowerShell's default `restricted`
execution policy doesn't allow it to run saved scripts. To run PowerShell
scripts, specify the `remotesigned` execution policy as part of the
command:

    exec { 'test':
      path    => 'C:/Windows/System32/WindowsPowerShell/v1.0',
      command => 'powershell -executionpolicy remotesigned -file C:/test.ps1',
    }

Executes external binaries directly, without passing through a shell or performing any interpolation. This is a safer and more predictable way to execute most commands, but prevents the use of globbing and shell built-ins (including control logic like "for" and "if" statements).

A read-only parameter set by the package.

A read-only parameter set by the package.

A read-only parameter set by the package.

A read-only parameter set by the package.

Newer versions of OpenBSD support 'flavors', which are further specifications for which type of package you want.

Tells apt to allow cdrom sources in the sources.list file. Normally apt will bail if you try this.

Deprecated form of provider.

Whether configfiles should be kept or replaced. Most packages types do not support this parameter. Defaults to keep.

A hash of additional options to pass when installing a package. These options are package-specific, and should be documented by the software vendor. The most commonly implemented option is INSTALLDIR:

        package { 'mysql':
          ensure          => installed,
          provider        => 'msi',
          source          => 'N:/packages/mysql-5.5.16-winx64.msi',
          install_options => { 'INSTALLDIR' => 'C:\mysql-5.5' },
        }

    Since these options are passed verbatim to `msiexec`, any file paths
    specified in `install_options` should use a backslash as the separator
    character rather than a forward slash. This is the **only** place in Puppet
    where backslash separators should be used. Note that backslashes in
    double-quoted strings _must_ be double-escaped and backslashes
    in single-quoted strings _may_ be double-escaped.

A read-only parameter set by the package.

Where to find the actual package. This must be a local file (or on a network file system) or a URL that your specific packaging type understands; Puppet will not retrieve files for you, although you can manage packages as file resources.

A file containing any necessary answers to questions asked by the package. This is currently used on Solaris and Debian. The value will be validated according to system rules, but it should generally be a fully qualified path.

A read-only parameter set by the package.

The package name. This is the name that the packaging system uses internally, which is sometimes (especially on Solaris) a name that is basically useless to humans. If you want to abstract package installation, then you can use aliases to provide a common name to packages:

      # In the 'openssl' class
      $ssl = $operatingsystem ? {
        solaris => SMCossl,
        default => openssl
      }

      # It is not an error to set an alias to the same value as the
      # object name.
      package { $ssl:
        ensure => installed,
        alias  => openssl
      }

      . etc. .

      $ssh = $operatingsystem ? {
        solaris => SMCossh,
        default => openssh
      }

      # Use the alias to specify a dependency, rather than
      # having another selector to figure it out again.
      package { $ssh:
        ensure  => installed,
        alias   => openssh,
        require => Package[openssl]
      }

A read-only parameter set by the package.

A file containing package defaults for installing packages. This is currently only used on Solaris. The value will be validated according to system rules, which in the case of Solaris means that it should either be a fully qualified path or it should be in /var/sadm/install/admin.

What state the package should be in. On packaging systems that can retrieve new packages on their own, you can choose which package to retrieve by specifying a version number or latest as the ensure value. On packaging systems that manage configuration files separately from "normal" system files, you can uninstall config files by specifying purged as the ensure value.

Package management via apt-get.

Installation from the AIX software directory.

Installation from NIM LPP source.

Support for the Package Manager Utility (pacman) used in Archlinux.

Package management based on Apple's Installer.app and DiskUtility.app. This package works by checking the contents of a DMG image for Apple pkg or mpkg files. Any number of pkg or mpkg files may exist in the root directory of the DMG file system. Subdirectories are not checked for packages. See the wiki docs on this provider for more detail.

Provides packaging support for Gentoo's portage system.

Package management using Blastwave.org's pkg-get command on Solaris.

HP-UX's packaging system.

Package management via aptitude.

The specific form of package management on FreeBSD. This is an extremely quirky packaging system, in that it freely mixes between ports and packages. Apparently all of the tools are written in Ruby, so there are plans to rewrite this support to directly use those libraries.

Package management via fink.

Support for SuSE zypper package manager. Found in SLES10sp2+ and SLES11

Support via urpmi.

Package management via apt-get ported to rpm.

Support for FreeBSD's ports using the portupgrade ports management software. Use the port's full origin as the resource name. eg (ports-mgmt/portupgrade) for the portupgrade port.

Support via yum.

Windows package management by installing and removing MSIs.

This provider requires a `source` attribute, and will accept paths to local
files, mapped drives, or UNC paths.

Package management using sunfreeware.com's pkg-get command on Solaris. At this point, support is exactly the same as blastwave support and has not actually been tested.

OpenBSD's form of pkg_add support.

OpenSolaris image packaging system. See pkg(5) for more information

RPM packaging support; should work anywhere with a working rpm binary.

Support for FreeBSD's ports. Note that this, too, mixes packages and ports.

Python packages via pip.

Package management using Peter Bonivart's pkgutil command on Solaris.

Package management which copies application bundles to a target.

Package management using MacPorts on OS X.

Supports MacPorts versions and revisions, but not variants.
Variant preferences may be specified using
[the MacPorts variants.conf file](http://guide.macports.org/chunked/internals.configuration-files.html#internals.configuration-files.variants-conf).

When specifying a version in the Puppet DSL, only specify the version, not the revision.
Revisions are only used internally for ensuring the latest version/revision of a port.

Support for suse rug package manager.

Package management via dpkg. Because this only uses dpkg and not apt, you must specify the source of any packages you want to manage.

Ruby Gem support. If a URL is passed via source, then that URL is used as the remote gem repository; if a source is present but is not a valid URL, it will be interpreted as the path to a local gem file. If source is not present at all, the gem will be installed from the default gem repositories.

Sun's packaging system. Requires that you specify the source for the packages you're managing.

Package management based on OS X's builtin packaging system. This is essentially the simplest and least functional package system in existence -- it only supports installation; no deletion or upgrades. The provider will automatically add the .pkg extension, so leave that off when specifying the package name.

Support for Red Hat's proprietary up2date package update mechanism.

The authoritative 'short' name of the computer record.

The 'long' name of the computer record.

The IP Address of the Computer object.

The MAC address of the primary network interface. Must match en0.

Control the existences of this computer record. Set this attribute to present to ensure the computer record exists. Set it to absent to delete any computer records with this name

Computer object management using DirectoryService on OS X. Note that these are distinctly different kinds of objects to 'hosts', as they require a MAC address and can have all sorts of policy attached to them.

This provider only manages Computer objects in the local directory service domain, not in remote directories.

If you wish to manage /etc/hosts on Mac OS X, then simply use the host type as per other platforms.

The alias name.

The file in which to store the aliases. Only used by those providers that write to disk.

Where email should be sent. Multiple values should be specified as an array.

The symbolic name of the cron job. This name is used for human reference only and is generated automatically for cron jobs found on the system. This generally won't matter, as Puppet will do its best to match existing cron jobs against specified jobs (and Puppet adds a comment to cron jobs it adds), but it is at least possible that converting from unmanaged jobs to managed jobs might require manual intervention.

The minute at which to run the cron job. Optional; if specified, must be between 0 and 59, inclusive.

Any environment settings associated with this cron job. They will be stored between the header and the job in the crontab. There can be no guarantees that other, earlier settings will not also affect a given cron job.

  Also, Puppet cannot automatically determine whether an existing,
  unmanaged environment setting is associated with a given cron
  job.  If you already have cron jobs with environment settings,
  then Puppet will keep those settings in the same place in the file,
  but will not associate them with a specific job.

  Settings should be specified exactly as they should appear in
  the crontab, e.g., `PATH=/bin:/usr/bin:/usr/sbin`.

The weekday on which to run the command. Optional; if specified, must be between 0 and 7, inclusive, with 0 (or 7) being Sunday, or must be the name of the day (e.g., Tuesday).

The day of the month on which to run the command. Optional; if specified, must be between 1 and 31.

Where the cron job should be stored. For crontab-style entries this is the same as the user and defaults that way. Other providers default accordingly.

The month of the year. Optional; if specified must be between 1 and 12 or the month name (e.g., December).

The command to execute in the cron job. The environment provided to the command varies by local system rules, and it is best to always provide a fully qualified command. The user's profile is not sourced when the command is run, so if the user's environment is desired it should be sourced manually.

  All cron parameters support `absent` as a value; this will
  remove any existing values for that field.

A special value such as 'reboot' or 'annually'. Only available on supported systems such as Vixie Cron. Overrides more specific time of day/week settings.

The hour at which to run the cron job. Optional; if specified, must be between 0 and 23, inclusive.

The user to run the command as. This user must be allowed to run cron jobs, which is not currently checked by Puppet.

  The user defaults to whomever Puppet is running as.

The name of the component. Generally optional.

The name of the host handling email for the list.

The email address of the administrator.

The description of the mailing list.

The name of the email list.

The name of the host providing web archives and the administrative interface.

The admin password.

The numeric VLAN ID.

The URL of the router or switch maintaining this VLAN.

The VLAN's name.

Cisco switch/router provider for vlans.

The name of the repository. This corresponds to the repositoryid parameter in yum.conf(5).

Password for this proxy. ABSENT_DOC

Whether this repository is enabled, as represented by a 0 or 1. ABSENT_DOC

Number of seconds after which the metadata will expire. ABSENT_DOC

List of shell globs. Matching packages will never be considered in updates or installs for this repo. ABSENT_DOC

Enable or disable protection for this repository. Requires that the protectbase plugin is installed and enabled. ABSENT_DOC

What to cache from this repository. ABSENT_DOC

Cost of this repository. ABSENT_DOC

List of shell globs. If this is set, only packages matching one of the globs will be considered for update or install from this repo. ABSENT_DOC

The URL of a remote file containing additional yum configuration settings. Puppet does not check for this file's existence or validity. ABSENT_DOC

Username for this proxy. ABSENT_DOC

Whether to check the GPG signature on packages installed from this repository, as represented by a 0 or 1. ABSENT_DOC

The URL for the GPG key with which packages from this repository are signed. ABSENT_DOC

Priority of this repository from 1-99. Requires that the priorities plugin is installed and enabled. ABSENT_DOC

URL to the proxy server for this repository. ABSENT_DOC

The URL that holds the list of mirrors for this repository. ABSENT_DOC

The URL for this repository. ABSENT_DOC

The failover methode for this repository; should be either roundrobin or priority. ABSENT_DOC

Whether HTTP/1.1 keepalive should be used with this repository, as represented by a 0 or 1. ABSENT_DOC

A human-readable description of the repository. This corresponds to the name parameter in yum.conf(5). ABSENT_DOC

Whether yum will allow the use of package groups for this repository, as represented by a 0 or 1. ABSENT_DOC

Number of seconds to wait for a connection before timing out. ABSENT_DOC

An SSH or telnet URL at which to access the router, in the form ssh://user:pass:enable@host/ or telnet://user:pass:enable@host/.

The path to the .k5login file to manage. Must be fully qualified.

The principals present in the .k5login file. This should be specified as an array.

The desired permissions mode of the .k5login file. Defaults to 644.

Load only a specific file, e.g. /etc/hosts. This can greatly speed up the execution the resource. When this parameter is set, you must also set the lens parameter to indicate which lens to use.

Whether augeas should perform typechecking. Defaults to false.

Optional colon-separated list or array of directories; these directories are searched for schema definitions. The agent's $libdir/augeas/lenses path will always be added to support pluginsync.

A file system path; all files loaded by Augeas are loaded underneath root.

Optional augeas command and comparisons to control the execution of this type. Supported onlyif syntax:

  * `get <AUGEAS_PATH> <COMPARATOR> <STRING>`
  * `match <MATCH_PATH> size <COMPARATOR> <INT>`
  * `match <MATCH_PATH> include <STRING>`
  * `match <MATCH_PATH> not_include <STRING>`
  * `match <MATCH_PATH> == <AN_ARRAY>`
  * `match <MATCH_PATH> != <AN_ARRAY>`

  where:

  * `AUGEAS_PATH` is a valid path scoped by the context
  * `MATCH_PATH` is a valid match synatx scoped by the context
  * `COMPARATOR` is one of `>, >=, !=, ==, <=,` or `<`
  * `STRING` is a string
  * `INT` is a number
  * `AN_ARRAY` is in the form `['a string', 'another']`

The name of this task. Used for uniqueness.

Optional context path. This value is prepended to the paths of all changes if the path is relative. If the incl parameter is set, defaults to /files + incl; otherwise, defaults to the empty string.

Optional command to force the augeas type to execute even if it thinks changes will not be made. This does not overide the onlyif parameter.

Use a specific lens, e.g. Hosts.lns. When this parameter is set, you must also set the incl parameter to indicate which file to load.

The changes which should be applied to the filesystem. This can be a command or an array of commands. The following commands are supported:

`set <PATH> <VALUE>`
: Sets the value `VALUE` at loction `PATH`


`setm <PATH> <SUB> <VALUE>`
: Sets multiple nodes (matching `SUB` relative to `PATH`) to `VALUE`


`rm <PATH>`
: Removes the node at location `PATH`


`remove <PATH>`
: Synonym for `rm`


`clear <PATH>`
: Sets the node at `PATH` to `NULL`, creating it if needed


`ins <LABEL> (before|after) <PATH>`
: Inserts an empty node `LABEL` either before or after `PATH`.


`insert <LABEL> <WHERE> <PATH>`
: Synonym for `ins`


`mv <PATH> <OTHER PATH>`
: Moves a node at `PATH` to the new location `OTHER PATH`


`move <PATH> <OTHER PATH>`
: Synonym for `mv`


`defvar <NAME> <PATH>`
: Sets Augeas variable `$NAME` to `PATH`


`defnode <NAME> <PATH> <VALUE>`
: Sets Augeas variable `$NAME` to `PATH`, creating it with `VALUE` if needed

If the `context` parameter is set, that value is prepended to any relative `PATH`s.

The expected return code from the augeas command. Should not be set.

The name for this pool.

Determines parity when using the raidz parameter.

List of all the devices to mirror for this pool. Each mirror should be a space separated string:

      mirror => ["disk1 disk2", "disk3 disk4"],

List of all the devices to raid for this pool. Should be an array of space separated strings:

      raidz => ["disk1 disk2", "disk3 disk4"],

Spare disk(s) for this pool.

The disk(s) for this pool. Can be an array or a space separated string.

Log disks for this pool. This type does not currently support mirroring of log disks.

Provider for Solaris zpool.

One or more (shell type) file glob patterns, which restrict the list of files to be tidied to those whose basenames match at least one of the patterns specified. Multiple patterns can be specified using an array.

  Example:

      tidy { "/tmp":
        age     => "1w",
        recurse => 1,
        matches => [ "[0-9]pub*.tmp", "*.temp", "tmpfile?" ]
      }

  This removes files from `/tmp` if they are one week old or older,
  are not in a subdirectory and match one of the shell globs given.

  Note that the patterns are matched against the basename of each
  file -- that is, your glob patterns should not have any '/'
  characters in them, since you are only specifying against the last
  bit of the file.

  Finally, note that you must now specify a non-zero/non-false value
  for recurse if matches is used, as matches only apply to files found
  by recursion (there's no reason to use static patterns match against
  a statically determined path).  Requiering explicit recursion clears
  up a common source of confusion.

Tidy files whose age is equal to or greater than the specified time. You can choose seconds, minutes, hours, days, or weeks by specifying the first letter of any of those words (e.g., '1w').

  Specifying 0 will remove all files.

The path to the file or directory to manage. Must be fully qualified.

Tidy directories in addition to files; that is, remove directories whose age is older than the specified criteria. This will only remove empty directories, so all contained files must also be tidied before a directory gets removed.

Set the mechanism for determining age. Default: atime.

If target is a directory, recursively descend into the directory looking for files to tidy.

Tidy files whose size is equal to or greater than the specified size. Unqualified values are in kilobytes, but b, k, m, g, and t can be appended to specify bytes, kilobytes, megabytes, gigabytes, and terabytes, respectively. Only the first character is significant, so the full word can also be used.

Whether tidied files should be backed up. Any values are passed directly to the file resources used for actual file deletion, so consult the file type's backup documentation to determine valid values.

The interface's name.

The URL at which the router or switch can be reached.

Allowed list of Vlans that this trunk can forward.

Channel group this interface is part of.

Interface speed.

Interface native vlan (for access mode only).

Interface description.

IP Address of this interface. Note that it might not be possible to set an interface IP address; it depends on the interface type and device type.

  Valid format of ip addresses are:

  * IPV4, like 127.0.0.1
  * IPV4/prefixlength like 127.0.1.1/24
  * IPV6/prefixlength like FE80::21A:2FFF:FE30:ECF0/128
  * an optional suffix for IPV6 addresses from this list: `eui-64`, `link-local`

  It is also possible to supply an array of values.

Interface duplex.

Interface switchport mode.

Interface switchport encapsulation.

Cisco switch/router provider for interface.

The SSH key comment. This attribute is currently used as a system-wide primary key and therefore has to be unique.

The absolute filename in which to store the SSH key. This property is optional and should only be used in cases where keys are stored in a non-standard location (i.e.not in ~user/.ssh/authorized_keys`).

The encryption type used: ssh-dss or ssh-rsa.

The user account in which the SSH key should be installed. The resource will automatically depend on this user.

The key itself; generally a long string of hex digits.

Key options, see sshd(8) for possible values. Multiple values should be specified as an array.

Parse and generate authorized_keys files for SSH.