smf(5) GUI construction?

Darren has a neat example of using zenity(1) and smf(5) to make an "on-off" switch for his laptop's network connection. The result:

where "Up" brings up network/physical and "Down" shuts it down—convenient for Solaris laptop users. zenity, by Glynn Foster, makes writing little panels like this so easy I suspect there might be a naescent cottage industry of smf–zenity panels. Let me know if you've written your own.

Update: Darren's new zsvcadm example is even better!

Finding the real smf(5) conversation

I was a bit surprised by how little discussion of smf(5) I'd found (or how little emotional discussion, perhaps). comp.unix.solaris regulars figured things out moments after the images were posted to the Download Center, while the discussion of Predictive Self-Healing forum at BigAdmin focused on futures and further integration with management software. But it turns out that the largest discussion is at the solarisx86 Yahoo! Group.

I've signed up just now, and I'll get a few more smf(5) types to join in as well—sorry for not realizing that this forum is so active, and so populated with early adopters.

(And before I neglect your favourite forum: please tell me what other forums we need to watch.)

Conversions, conversions

I mentioned that I'd converted a few of the F/OSS software packages that we use on our home system. Of course, the point of smf(5) isn't to force you to rewrite all of your init.d scripts—it's to force you to encourage your vendor to do so. (Wait, that's not right, either.) I'll come back to this aspect, but let's talk a bit about service bundles.

The service bundle (or service manifest) is meant to accompany the package delivering the software. If a System V-style package uses the i.manifest class action script to identify its manifests, then these will be automatically imported into the repository upon package installation. (The class action script knows about zones, LiveUpgrade, and a couple of complicated circumstances where it's not safe to import automatically.) In any case, upon the next reboot, unimported manifests in /var/svc/manifest will be automatically imported, and such services will be present in the graph.

Service manifests should deliver services disabled by default, so no one gets surprised by "hey, port N is now open—why's that?" after a package installation. For these cases, all the administrator needs to do is

# svcadm enable service_fmri

That is, the intentions for the service are owned by the system administrator. (There are exceptions for service complexes, where multiple services are involved, but manipulating interior services of a complex should be done by using temporary enable/disable requests. See svcadm(1M) and smf_enable_instance(3SCF).)

If you're delivering software outside of the System V packaging, your installer can do the equivalent: use svccfg(1M) to import the service. If you support some form of upgrade, you can enable the service if you detected that the service was effectively enabled already. Remember to think about your uninstall action as well. For the default packages, we disallow deletion of a package that contains an enabled service instance. (A check on accidental removal.)

So those are the fundamentals—more detail is available in our service developer introduction. But the big question is what F/OSS software would you like to see example conversions for, first? (And tell us what commercial packages matter, too.) I'm going to start describing a few of the ones I mentioned a few days ago but, again, the goal isn't to cause the creation of hundreds or thousands of custom descriptions of a standard software service, but to get the service described and to have that description accompany the service to deployment.