# Support for Solaris Service Management Facility **URL:** \ **Category:** Ansible Project\ **Tags:** rhel\ **Created:** [November 14, 2012, 2:30am UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083 "2012-11-14T02:30:15Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Boyd\_Adamson](https://avatars.discourse-cdn.com/v4/letter/b/e36b37/32.png) [@Boyd\_Adamson](https://forum.ansible.com/u/Boyd_Adamson)\ **Post date:** [November 14, 2012, 2:30am UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083/1 "2012-11-14T02:30:15Z")
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](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 ---
**Author:** ![Romeo\_Theriault](https://avatars.discourse-cdn.com/v4/letter/r/839c29/32.png) [@Romeo\_Theriault](https://forum.ansible.com/u/Romeo_Theriault)\ **Post date:** [November 14, 2012, 3:14am UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083/2 "2012-11-14T03:14:57Z")
... > 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 \ on/off' can be mapped to 'svcadm enable/disable' Just my 2cents. 🙂 ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [November 14, 2012, 2:38pm UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083/3 "2012-11-14T14:38:11Z")
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. ---
**Author:** ![Boyd\_Adamson](https://avatars.discourse-cdn.com/v4/letter/b/e36b37/32.png) [@Boyd\_Adamson](https://forum.ansible.com/u/Boyd_Adamson)\ **Post date:** [November 15, 2012, 1:07am UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083/4 "2012-11-15T01:07:32Z")
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. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [November 15, 2012, 1:11am UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083/5 "2012-11-15T01:11:55Z")
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) ---
**Author:** ![Asil](https://avatars.discourse-cdn.com/v4/letter/a/74df32/32.png) [@Asil](https://forum.ansible.com/u/Asil)\ **Post date:** [June 23, 2016, 10:29am UTC](https://forum.ansible.com/t/support-for-solaris-service-management-facility/12083/6 "2016-06-23T10:29:37Z")
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