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 On Wednesday, November 14, 2012 at 2:30:15 AM UTC, Boyd Adamson wrote: > > 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 > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/3facc747-85cb-40db-9d41-01e7c769000f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
