Support for Solaris Service Management Facility

Archives Ansible Project
1

I’d like to get support for Solaris’ SMF into the core, but I think there will be some discussion involved as to the implementation strategy.

I’ve got a module ready for testing at https://github.com/brontitall/ansible/blob/smf/library/smf. This module adds support for SMF on solaris. It supports enabling, disabling, restarting and refreshing services. Also allows setting property values.

I understand that adding a separate module for this conflicts with the intended goal of having a generic “service” module. Some background for discussion:

The basic unit of SMF is the service. Services are identified by a thing called an FMRI (like a name) which has a form like this: svc:/network/dhcp/server:ipv4 For all commands that can be abbreviated, so that all the following refer to the same service:

network/dhcp/server:ipv4
dhcp/server:ipv4

… or several other unambiguous abbreviations.

SMF on Solaris does more that just starting and stopping services. It also provides an arbitrary set of properties for each service that can control the behavior of the service. These services are not only for daemons, but for every run-on-boot and run-once type operation and the properties are used to configure many aspects of the system. On Solaris 11, for example, SMF properties are used to configure the DNS client (like resolv.conf), name service switch (like nsswitch.conf), hostname, etc. Basically many things that on a RHEL-alike would be put into /etc/sysconfig. In fact, properties are the only directly supported way of configuring the system during automated installs. Properties are namespaces as property_group/property and permissions and access controls are available per service per property group. These properties are set with a 2-step process of:

  • Set one or more properties on the service with “svccfg -s pkg/server:default setprop pkg/port = 5555”. If the property does not already exist, a data type need to be provided (e.g. count:, astring:), etc. Note that the current implementation does not support supplying a type, but I would want to add that before it was integrated. I’m not sure how to fit it into the arguments for the module, and want to get the broader questions sorted out before going there.

  • Make all the new changes active simultaneously with “svcadm refresh pkg/server:default”

So, with that background in mind, I’m not sure how all this would fit into a generic “service” module. It seems that the criteria that apply to keeping packaging modules separate (differing names between distros, don’t want the “lowest common denominator” behaviour) equally apply to these SMF services.

There may be ways to implement this that aren’t distasteful that I haven’t seen, so I’m after some opinions on the way forward for this.

Thanks,

Boyd

2

...

So, with that background in mind, I'm not sure how all this would fit into a
generic "service" module. It seems that the criteria that apply to keeping
packaging modules separate (differing names between distros, don't want the
"lowest common denominator" behaviour) equally apply to these SMF services.

There may be ways to implement this that aren't distasteful that I haven't
seen, so I'm after some opinions on the way forward for this.

Hi Boyd, It's true that SMF can do a lot that doesn't fit into a more
generic "service" type module. So I would think having a full blown
SMF module that supports all these features would make sense. But, I
do think that it also makes sense for us to have SMF's features that
are equivalent to RHEL's chkconfig/service and debian's update-rc.d
etc... in the generic service module. I think we can mimic those
features quite well, for example:

RHEL's 'service start' and 'service stop' could be mapped to 'svcadm
-t enable' and 'svcadm -t disable'
RHEL's 'chkconfig <service> on/off' can be mapped to 'svcadm enable/disable'

Just my 2cents. :slight_smile:

3

So it is acceptable for a module that has some OS/platform specific
flags to add options that just don't do anything on those other
platforms.

So a smf_ prefix on some parameters would be acceptable, but where
possible, we want things to line up.

4

Ok, that’s fine. What about property setting? At the moment, I’m accepting
arbitrary group/prop=value arguments. That seems not appropriate for a
shared module. I suppose we could make that something like
“smf_prop_group/prop=value”, but that starts to feel a bit like fake
namespaces.

5

you could maybe do something like this (not knowing what SMF properties are)

smf_properties="a=b dog=cat shot_sherriff=no shot_deputy=yes"

In the worst case, you may have to use interior quotes.

(Generally I DO want modules to validate all properties given to them,
so we should generally not turn module argument validation off so
taking first class arguments does not seem like a good idea)

6

Hi - did this manage to gain any traction? I’ve checked the ansible code (>v2), looks like there’s support for service control but not service property definition.

Thanks!

A