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; Joyent 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: ]


So #2 sounds fine, but what are "the three properties needed to the pkginfo file"? Are you talking about SUNW_PKG_ALLZONES and friends? With regards to not delivering to /usr, what's the correct way to install a binary to, say, /usr/local/sbin? Or are you saying that /usr is now out of bounds and we should all go to /opt for our packages (yes, I understand that this has been the situation for a while, but it hasn't broken package installation before)? I'd love to "do the right thing" but it's difficult to decipher exactly what that is (particularly when the documentation on packages and patches seems directly targeted at Sun employees with someone who understands it already sat next to them).

Posted by Ceri on June 07, 2007 at 02:13 AM PDT #

@Ceri: Yes, I mean SUNW_PKG_{ALLZONES,THISZONE,HOLLOW}. The authoritative table on the meaning of the various combinations of these is this section of Resource Management and Solaris Zones. One way to assess appropriate settings for your packages is to compare with the various packages in the ON and other consolidations. (Use OpenGrok to search all the package definitions for these settings.)

It's easiest to install into /opt somewhere, but I can envision an installer program that wraps the pkgadd(1M) invocation with the appropriate tests to see if the global zone has offered a /usr/local writable filesystem. (Or something even more sophisticated, using loopback mounts, etc.) — Stephen

Posted by Stephen on June 07, 2007 at 04:47 AM PDT #

OK, thank you Stephen.

Posted by Ceri on June 07, 2007 at 08:10 PM PDT #

I would like to stress how important item #5 is. Private copies can bring you in the situation that you have to provide security fixes for bugs in 3rd party modules. And for commercial products, it's very often not enough to do so for the currents release only, because of existing service contracts for older releases. We just had something like this with StarOffice, but "fortunately" there was also an other security issue, so we didn't do all the work just for the 3rd party library: See

Posted by Malte Timmermann on June 18, 2007 at 08:27 PM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016
External blogs