Forge Home

Modules

Puppet

Resources

PuppetEcosystemPuppet CommunityUpdates

smf

This wraps any binary in Solaris SMF and starts the service
Project URLRSS Feed

9,987 downloads

9,767 latest version

1.6 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 1.0.1 (latest)
  • 1.0.0
released Jun 17th 2014

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'ppbrown-smf', '1.0.1'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add ppbrown-smf
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install ppbrown-smf --version 1.0.1

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download
Tags: solaris, smf

Documentation

ppbrown/smf — version 1.0.1 Jun 17th 2014

smf::service is a convenience class to turn a "normal" (aka legacy) boot time service or demon, into an SMF run one.

The first time the class is run, puppet should install the SMF service definition, and ideally, enable the service.

Any subsequent time, it should just make sure the service is enabled.

DISCLAIMER: This does not install or configure any demon. It presumes whatever binaries you need to run, are already fully configured and installed. This class merely creates an SMF layer around it.

USAGE:

smf::service { "yourservice": service_command => "/usr/sbin/somename -optional args"}

REQUIREMENTS:

For any instance, you must provide define:

  1. the service name (which is the 'name' of the resource)
  2. full path to the binary, 'servicecommand' (unless you are providing your own start script with hardcoded path, in which case, you can just fake it) #(optional) the source path for the config file #(optional) whether the demon supports refresh via HUP signal

I toyed with the idea of making optional arguments for things like

#(optional) the source path for the init script style start/stop script #(optional) the source path for the SMF definitions However, I think that would be better done, by creating a whole new class or subclass. ie: smf::yourservice

It would be a little more efficient also, since that way, you could use hardcoded files, rather than templated ones.

AUTHOR

  • Philip Brown