<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<!--

 CDDL HEADER START

 The contents of this file are subject to the terms of the

 Common Development and Distribution License (the "License").

 You may not use this file except in compliance with the License.

 You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE

 or http://www.opensolaris.org/os/licensing.

 See the License for the specific language governing permissions

 and limitations under the License.

 When distributing Covered Code, include this CDDL HEADER in each

 file and include the License file at usr/src/OPENSOLARIS.LICENSE.

 If applicable, add the following below this CDDL HEADER, with the

 fields enclosed by brackets "[]" replaced with your own identifying

 information: Portions Copyright [yyyy] [name of copyright owner]

 CDDL HEADER END

 NOTE:  This service manifest is not editable; its contents will

 be overwritten by package or patch operations, including

 operating system upgrade.  Make customizations in a different

 file.

-->

<service_bundle type="manifest" name="puppet">

  <service name="application/puppet" type="service" version="1">

    <dependency name="filesystem" grouping="require_all" restart_on="error" type="service">

      <service_fmri value="svc:/system/filesystem/minimal"/>

    </dependency>

    <dependency name="network" grouping="require_all" restart_on="error" type="service">

      <service_fmri value="svc:/milestone/network"/>

    </dependency>

    <dependency name="identity" grouping="require_all" restart_on="error" type="service">

      <service_fmri value="svc:/system/identity:node"/>

    </dependency>

      <service_fmri value="svc:/milestone/self-assembly-complete"/>

    </dependency>

    <exec_method type="method" name="start" exec=":true" timeout_seconds="60"/>

    <exec_method type="method" name="stop" exec=":kill" timeout_seconds="60"/>

    <exec_method type="method" name="refresh" exec=":true" timeout_seconds="0"/>

    <property_group name="general" type="framework">

      <!-- to start stop puppet -->

      <propval name="action_authorization" type="astring" value="solaris.smf.manage.puppet"/>

      <!-- to change puppet properties -->

      <propval name="value_authorization" type="astring" value="solaris.smf.value.puppet"/>

    </property_group>

    <property_group name="puppet_stencil" type="configfile">

      <propval name="path" type="astring" value="/etc/puppetlabs/puppet/puppet.conf"/>

      <propval name="stencil" type="astring" value="puppet.stencil"/>

      <propval name="mode" type="astring" value="0444"/>

    </property_group>

    <instance name="upgrade" enabled="true">

      <!--

           The upgrade instance performs migration and cleanup steps if needed

       -->

      <exec_method type="method" name="start" exec="/usr/puppetlabs/puppet/bin/upgrade.sh" timeout_seconds="0"/>

      <exec_method type="method" name="stop" exec=":true" timeout_seconds="0"/>

      <property_group name="startd" type="framework">

        <propval name="duration" type="astring" value="transient"/>

      </property_group>

      <property_group name="upgrade" type="application">

        <propval name="4.x" type="boolean" value="false"/>

      </property_group>

    </instance>

    <instance name="main" enabled="false">

      <!--

          The main instance exists to hold shared configuration values.

       -->

      <property_group name="config" type="application">

        <propval name="vardir" type="astring" value="/var/cache/puppetlabs"/>

        <propval name="rundir" type="astring" value="/var/run/puppetlabs"/>

        <propval name="confdir" type="astring" value="/etc/puppetlabs/puppet"/>

      </property_group>

    </instance>

    <instance name="user" enabled="false">

      <!--

          user is used by the Puppet apply command, as well as many of the less

          common Puppet subcommands.

       -->

      <property_group name="config" type="application">

        <propval name="vardir" type="astring" value="/var/cache/puppetlabs"/>

        <propval name="rundir" type="astring" value="/var/run/puppetlabs"/>

        <propval name="confdir" type="astring" value="/etc/puppetlabs/puppet"/>

      </property_group>

    </instance>

    <instance name="master" enabled="false">

      <exec_method type="method" name="start" exec="/usr/sbin/puppet master --logdest %{config/logdest}" timeout_seconds="600"/>

      <property_group name="config" type="application">

        <propval name="logdest" type="astring" value="/var/log/puppetlabs/puppet/puppet-master.log"/>

      </property_group>

    </instance>

    <instance name="agent" enabled="false">

      <exec_method type="method" name="start" exec="/usr/sbin/puppet agent --logdest %{config/logdest}" timeout_seconds="600"/>

      <property_group name="config" type="application">

        <propval name="logdest" type="astring" value="/var/log/puppetlabs/puppet/puppet-agent.log"/>

      </property_group>

    </instance>

    <stability value="Unstable"/>

    <template>

      <common_name>

        <loctext xml:lang="C">Puppet</loctext>

      </common_name>

      <documentation>

        <manpage title="puppet-master" section="8" manpath="/usr/share/man"/>

      </documentation>

      <pg_pattern required="false" type="application" name="config">

        <prop_pattern required="false" type="astring" name="agent_catalog_run_lockfile">

          <description>

            <loctext xml:lang="C">

A lock file to indicate that a puppet agent catalog run is currently in

progress. The file contains the pid of the process that holds the lock on the

catalog run.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="agent_disabled_lockfile">

          <description>

            <loctext xml:lang="C">

A lock file to indicate that puppet agent runs have been administratively

disabled.  File contains a JSON object with state information.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="allow_duplicate_certs">

          <description>

            <loctext xml:lang="C">

Whether to allow a new certificate request to overwrite an existing

certificate.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="always_cache_features">

          <description>

            <loctext xml:lang="C">

This setting is deprecated and has been replaced by always_retry_plugins.

Affects how we cache attempts to load Puppet 'features'.  If false, then calls

to `Puppet.features.<feature>?` will always attempt to load the feature (which

can be an expensive operation) unless it has already been loaded successfully.

This makes it possible for a single agent run to, e.g., install a package that

provides the underlying capabilities for a feature, and then later load that

feature during the same run (even if the feature had been tested earlier and

had not been available).  If this setting is set to true, then features will

only be checked once, and if they are not available, the negative result is

cached and returned for all subsequent attempts to load the feature.  This

behavior is almost always appropriate for the server, and can result in a

significant performance improvement for features that are checked frequently.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="always_retry_plugins">

          <description>

            <loctext xml:lang="C">

Affects how we cache attempts to load Puppet resource types and features.  If

true, then calls to `Puppet.type.<type>?` `Puppet.feature.<feature>?` will

always attempt to load the type or feature (which can be an expensive

operation) unless it has already been loaded successfully. This makes it

possible for a single agent run to, e.g., install a package that provides the

underlying capabilities for a type or feature, and then later load that type or

feature during the same run (even if the type or feature had been tested

earlier and had not been available).  If this setting is set to false, then

types and features will only be checked once, and if they are not available,

the negative result is cached and returned for all subsequent attempts to load

the type or feature.  This behavior is almost always appropriate for the

server, and can result in a significant performance improvement for types and

features that are checked frequently.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="app_management">

          <description>

            <loctext xml:lang="C">

Whether the application management feature is on or off. You must restart

Puppet Server after changing this setting.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="host" name="archive_file_server">

          <description>

            <loctext xml:lang="C">

During an inspect run, the file bucket server to archive files to if

archive_files is set.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="archive_files">

          <description>

            <loctext xml:lang="C">

During an inspect run, whether to archive files whose contents are audited to a

file bucket.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="autoflush">

          <description>

            <loctext xml:lang="C">

Whether log files should always flush to disk.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="autosign">

          <description>

            <loctext xml:lang="C">

Whether (and how) to autosign certificate requests. This setting is only

relevant on a puppet master acting as a certificate authority (CA).  Valid

values are true (autosigns all certificate requests; not recommended), false

(disables autosigning certificates), or the absolute path to a file.  The file

specified in this setting may be either a **configuration file** or a **custom

policy executable.** Puppet will automatically determine what it is: If the

Puppet user (see the `user` setting) can execute the file, it will be treated

as a policy executable; otherwise, it will be treated as a config file.  If a

custom policy executable is configured, the CA puppet master will run it every

time it receives a CSR. The executable will be passed the subject CN of the

request _as a command line argument,_ and the contents of the CSR in PEM format

_on stdin._ It should exit with a status of 0 if the cert should be autosigned

and non-zero if the cert should not be autosigned.  If a certificate request is

not autosigned, it will persist for review. An admin user can use the `puppet

cert sign` command to manually sign it, or can delete the request.  For info on

autosign configuration files, see [the guide to Puppet's config files](http://d

ocs.puppetlabs.com/puppet/latest/reference/config_about_settings.html).

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="basemodulepath">

          <description>

            <loctext xml:lang="C">

The search path for **global** modules. Should be specified as a list of

directories separated by the system path separator character. (The POSIX path

separator is ':', and the Windows path separator is ';'.)  These are the

modules that will be used by _all_ environments. Note that the `modules`

directory of the active environment will have priority over any global

directories. For more info, see

<https://docs.puppet.com/puppet/latest/reference/environments.html>

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="net_address" name="bindaddress">

          <description>

            <loctext xml:lang="C">

The address a listening server should bind to.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="binder_config">

          <description>

            <loctext xml:lang="C">

The binder configuration file. Puppet reads this file on each request to

configure the bindings system. If set to nil (the default), a

$confdir/binder_config.yaml is optionally loaded. If it does not exists, a

default configuration is used. If the setting :binding_config is specified, it

must reference a valid and existing yaml file.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="bucketdir">

          <description>

            <loctext xml:lang="C">

Where FileBucket files are stored.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="ca">

          <description>

            <loctext xml:lang="C">

Whether the master should function as a certificate authority.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="ca_name">

          <description>

            <loctext xml:lang="C">

The name to use the Certificate Authority certificate.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="integer" name="ca_port">

          <description>

            <loctext xml:lang="C">

The port to use for the certificate authority.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="host" name="ca_server">

          <description>

            <loctext xml:lang="C">

The server to use for certificate authority requests.  It's a separate server

because it cannot and does not need to horizontally scale.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="integer" name="ca_ttl">

          <description>

            <loctext xml:lang="C">

The default TTL for new certificates. This setting can be a time interval in

seconds (30 or 30s), minutes (30m), hours (6h), days (2d), or years (5y).

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="cacert">

          <description>

            <loctext xml:lang="C">

The CA certificate.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="cacrl">

          <description>

            <loctext xml:lang="C">

The certificate revocation list (CRL) for the CA. Will be used if present but

otherwise ignored.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="cadir">

          <description>

            <loctext xml:lang="C">

The root directory for the certificate authority.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="cakey">

          <description>

            <loctext xml:lang="C">

The CA private key.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="capass">

          <description>

            <loctext xml:lang="C">

Where the CA stores the password for the private key.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="caprivatedir">

          <description>

            <loctext xml:lang="C">

Where the CA stores private certificate information.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="capub">

          <description>

            <loctext xml:lang="C">

The CA public key.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="catalog_cache_terminus">

          <description>

            <loctext xml:lang="C">

How to store cached catalogs. Valid values are 'json', 'msgpack' and 'yaml'.

The agent application defaults to 'json'.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="catalog_terminus">

          <description>

            <loctext xml:lang="C">

Where to get node catalogs.  This is useful to change if, for instance, you'd

like to pre-compile catalogs and store them in memcached or some other easily-

accessed store.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="cert_inventory">

          <description>

            <loctext xml:lang="C">

The inventory file. This is a text file to which the CA writes a complete

listing of all certificates.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="certdir">

          <description>

            <loctext xml:lang="C">

The certificate directory.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="certificate_revocation">

          <description>

            <loctext xml:lang="C">

Whether certificate revocation should be supported by downloading a Certificate

Revocation List (CRL) to all clients.  If enabled, CA chaining will almost

definitely not work.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="hostname" name="certname">

          <description>

            <loctext xml:lang="C">

The name to use when handling certificates. When a node requests a certificate

from the CA puppet master, it uses the value of the `certname` setting as its

requested Subject CN.  This is the name used when managing a node's permissions

in [auth.conf](https://docs.puppetlabs.com/puppet/latest/reference/config_file_

auth.html). In most cases, it is also used as the node's name when matching

[node definitions](https://docs.puppetlabs.com/puppet/latest/reference/lang_nod

e_definitions.html) and requesting data from an ENC. (This can be changed with

the `node_name_value` and `node_name_fact` settings, although you should only

do so if you have a compelling reason.)  A node's certname is available in

Puppet manifests as `$trusted['certname']`. (See [Facts and Built-In Variables]

(https://docs.puppetlabs.com/puppet/latest/reference/lang_facts_and_builtin_var

s.html) for more details.)  * For best compatibility, you should limit the

value of `certname` to   only use letters, numbers, periods, underscores, and

dashes. (That is,   it should match `/A[a-z0-9._-]+Z/`.) * The special value

`ca` is reserved, and can't be used as the certname   for a normal node.

Defaults to the node's fully qualified domain name.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="boolean" name="cfacter">

          <description>

            <loctext xml:lang="C">

Whether to enable a pre-Facter 3.0 release of native Facter (distributed as the

"cfacter" package). This is not necessary if Facter 3.0 or later is installed.

This setting is deprecated, as Facter 3 is now the default in puppet-agent.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="classfile">

          <description>

            <loctext xml:lang="C">

The file in which puppet agent stores a list of the classes associated with the

retrieved configuration.  Can be loaded in the separate `puppet` executable

using the `--loadclasses` option.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="client_datadir">

          <description>

            <loctext xml:lang="C">

The directory in which serialized data is stored on the client.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="clientbucketdir">

          <description>

            <loctext xml:lang="C">

Where FileBucket files are stored locally.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="clientyamldir">

          <description>

            <loctext xml:lang="C">

The directory in which client-side YAML data is stored.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="code">

          <description>

            <loctext xml:lang="C">

Code to parse directly.  This is essentially only used by `puppet`, and should

only be set if you're writing your own Puppet executable.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="codedir">

          <description>

            <loctext xml:lang="C">

The main Puppet code directory.  The default for this setting is calculated

based on the user.  If the process is running as root or the user that Puppet

is supposed to run as, it defaults to a system directory, but if it's running

as any other user, it defaults to being in the user's home directory.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="color">

          <description>

            <loctext xml:lang="C">

Whether to use colors when logging to the console.  Valid values are `ansi`

(equivalent to `true`), `html`, and `false`, which produces no color. Defaults

to false on Windows, as its console does not support ansi colors.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="confdir">

          <description>

            <loctext xml:lang="C">

The main Puppet configuration directory.  The default for this setting is

calculated based on the user.  If the process is running as root or the user

that Puppet is supposed to run as, it defaults to a system directory, but if

it's running as any other user, it defaults to being in the user's home

directory.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="config">

          <description>

            <loctext xml:lang="C">

The configuration file for the current puppet application.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="config_file_name">

          <description>

            <loctext xml:lang="C">

The name of the puppet config file.

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="config_version">

          <description>

            <loctext xml:lang="C">

How to determine the configuration version.  By default, it will be the time

that the configuration is parsed, but you can provide a shell script to

override how the version is determined.  The output of this script will be

added to every log message in the reports, allowing you to correlate changes on

your hosts to the source version on the server.  Setting a global value for

config_version in puppet.conf is not allowed (but it can be overridden from the

commandline). Please set a per-environment value in environment.conf instead.

For more info, see

<https://docs.puppet.com/puppet/latest/reference/environments.html>

	    </loctext>

          </description>

        </prop_pattern>

        <prop_pattern required="false" type="astring" name="configprint">

          <description>

            <loctext xml:lang="C">