OpenSolaris: Five updates conservative developers should make

It’s been almost two-and-a-half years since Solaris 10 was released, and if we look at Nevada (via Developer Edition or one of the other distributions), we can see that many of the technologies introduced in S10 are becoming still more capable. At this point, even the most conservative software developer can assume that certain features are always present. So, for the conservative OpenSolaris application developer, here are the five low-risk, high-reward updates you should make to your application:

1. Provide x86 and SPARC versions. OpenSolaris has two primary instruction set targets, i386 and sparc. Each of these has both a 32- and a 64-bit variant. The metrics on Solaris 10 and SX:CE/DE downloads tell us that the Solaris volume is substantial on both targets so, for maximum uptake, you should attempt to offer software on both.

On x86, you should consider delivering both 32- and 64-bit versions, if your application can take advantage of a 64-bit address space. But there is a large contingent of 32-bit only users, so don’t stop delivering appropriate binaries prematurely.

Of course, if you’re writing at a hardware-independent level, like on a Java language platform, then you get x86 and SPARC (and presumably others) for free.

2. Make packages that deliver into sparse zones. The primary software delivery mechanism is still System V packages—but your software’s already packaged properly, so that’s not an issue. (Right?) With Solaris 10, the Zones feature offers a sparse variant that requires package support. Roughly, this support means that the package author shouldn’t deliver into /usr and should add the three properties needed to the pkginfo file.

There are some fairly serious Zones deployers out there; <a href="http://www.joyent.com"  >Joyent</a> is probably the most public example, but there are plenty of corporate datacentres using Zones to their advantage. If you want your software run by them or their customers, providing a Zones-compatible package seems like the easiest way to get it into their hands and onto their Zones.

3. Replace your init.d scripts with smf(5) manifests. The Service Management Facility (smf(5)) provides a collection of capabilities that make service administration easier, while also reducing the development burden on application authors. Converting your service from the rc*.d script to a service description and methods means that administrators get automatic restart (and higher service availability), an easy on/off switch, and a place to make site-specific annotations (using the various template properties). There’s a free comptetive advantage here, if your service runs under smf(5) and a rival’s doesn’t.

Of course, you can do more: placing key configuration values in the service repository means that various administrative utilities can be taught to make manipulating your application’s feature set easy to the deploying administrator. But that won’t happen without an initial service conversion.

(Once you write a manifest for your service, you’ll also probably want to write a rights profile, so that administrative authority for your service and its instances can be easily delegated.)

4. Understand needed privileges. One of the more interesting features in Solaris 10 and later is the work Casper did to split out the absolute privilege owned by root into a specific collection of privileges. That means that you can take away a process’s ability to fork or exec, change file ownership, or manipulate or utilize various subsystems of the operating system. If your application runs with the minimal set of privileges it needs to function, then the set of actions a hypothetical exploit against your application can invoke becomes limited, which reduces the impact of an intrusion. You can reduce your privileges via the smf(5) manifest you wrote for #3, via the role-based access control (RBAC) configuration, or via the privileges API.

5. Don’t unnecessarily ship duplicate components. The various OpenSolaris distributions include a lot of software; most of these offer one or more update mechanisms for the components they include. Whether or not you prefer minimal patches to wholesale package replacements, if you ship a duplicate component, it’s your responsiblity to update it if a defect or security hole is found. Sometimes you have to ship a component—the distros don’t update it often enough—but private libraries (or private copies of the Java runtime) have a collection of costs, many of which are imposed on your customer.

For specific kinds of software, there’s more to investigate. Language interpreters and byte-code virtual machines (and probably complex daemons) should have DTrace providers. Network device drivers should write to the latest version of the generic LAN device (gld) interface. Archival programs should be ZFS-compatible—there’s going to be a lot of data on ZFS. Daemons should investigate using libumem for memory allocation (and event ports in place of poll(2) or select(3C)). And so on.

There are OpenSolaris communities for each of these topics but, if you’re having trouble getting started, I would suggest an email to opensolaris-code, that reads something like: “I have a [daemon/driver/app] that does [practical purpose/amazing feat/curious entertainment]. Are there any OpenSolaris features I can use to make it better?”

Looking forward to your mail.

Thanks to Dave for #5. Dave also confesses to being keen on #3.

[ T: OpenSolaris Solaris smf privilege RBAC zones ]