Puppet and SMF in Solaris 11.2

In a former post I covered already my enthusiasm for Puppet support in Solaris 11.2. But what does it really mean? Is Puppet now the strategic systems management framework for all the Solaris stuff? In my opinion this is definitely not the case. The Solaris developers invested many years into good base technologies for systems management like the “Service Management Facility” (SMF). And with new Solaris releases, more and more systems configuration moves into SMF, into so called “SMF properties”. For example since Solaris 11 the DNS servers need to be configured in SMF properties and no longer in /etc/resolv.conf.
So if Puppet can talk to SMF the full power of SMF is also available in Puppet. In this post I will show how the managing of SMF in Puppet is possible in Solaris 11.2.

Solaris interfaces for Puppet

Puppet can use the following interfaces on Solaris to manage system configuration.

  • Command line interface (CLI): Puppet mimics a human and just calls a CLI tool. For example the user Puppet provider just calls /sbin/useradd in order to add a new user.
  • Files: A lot of the configuration is stored in text files, Puppet can manipulate existing files or just overwrite files with Puppet templates completely.
  • SMF: Puppet can talk to SMF directly, see next chapter.
  • Remote administration daemon (RAD): This is a future technology. Administrative commands are once implemented as RAD module and multiple clients can just use this implementation. RAD provides an API and several language bindings, so it is for example possible to implement a CLI client in C and a web interface in Python. And of course a Puppet module which interacts directly with the API without risky CLI output parsing.

CLI and Files are the standard interfaces on most platforms. AFAIK there are not yet RAD based Puppet modules, but SMF is already easy to use.

Service Management Facility (SMF)

SMF was introduced with Solaris 10, so it is almost 10 years old. Since the initial release it has been improved successively. The primary features of SMF are:

  • Replacement of init.d start and stop scripts.
  • Dependency handling of SMF services.
  • Automated restart of processes (self-healing).
  • Configuration storage: Properties for services can be directly stored and managed on SMF service level.

For a further description of SMF you can read the excellent SMF tutorial of Joerg Moellenkamp.

Adapting an application to store its configuration in SMF was not that easy. With Solaris 11.2 it is, thanks to “SMF Stencils”. With Stencils you can tell SMF to create or refresh a configuration file before it starts the application. The file is assembled according to a given template file and the variables which are managed as SMF properties.

Puppetize SMF

Install Puppet if not yet done:

# pkg install puppet

There is an own Puppet provider to manage SMF properties called svccfg. Managing the service status with Puppet is already possible with the service provider for a long time. In the following example we manage the NTP client with Puppet, we activate the slew_always option and take care that the service is started.

ntp-conf.pp
1
2
3
4
5
6
7
8
9
10
11
12
13
14
svccfg { 'ntp_slew_always' :
  fmri => 'svc:/network/ntp:default',
  property => 'config/slew_always',
  type => 'boolean',
  value => 'true',
  ensure => 'present',
  notify => Service['ntp']
}

service { 'ntp':
  ensure => 'running',
  enable => 'true',
  provider => 'smf',
}

The /etc/inet/ntp.conf can be managed with stencils or a simple Puppet template for example. At least a minimal configuration like the following needs to exist:

/etc/inet/ntp.conf
1
server 127.0.0.1

You can apply the manifest and check whether the ntpd process is started with the slew_always (--slew) option.

# puppet apply ntp-conf.pp
Notice: /Stage[main]/Main/Svccfg[ntp_slew_always]/ensure: created
Notice: /Stage[main]/Main/Service[ntp]/ensure: ensure changed 'stopped' to 'running'
Notice: Finished catalog run in 1.93 seconds

# svcs -lp ntp | egrep "name|process"
name         Network Time Protocol (NTP) Version 4
process      2426 /usr/lib/inet/ntpd -p /var/run/ntp.pid -g --slew

SMF has more efficient features to manage SMF properties changes, for example SMF profiles. But in my opinion it is a huge advantage that you can document the whole configuration in a Puppet manifest, because it is easier to overview and manage. Especially if you put the manifests in a source code version control system like Git, you will get a nice change history.

Share Comments