OpenSolaris: Picnic, California Edition

OpenSolaris just turned two—enjoy some good food and good company in the Northern California sun. Tomorrow's first ever OpenSolaris picnic [Upcoming] will be at Baylands Park in Sunnyvale, starting at 11:00 a.m..

Tamara and Ben will, of course, be superlative hosts. See you there!

[ T: OpenSolaris picnic ]

Half a week

I was out half this week, helping my younger son deal with a nasty sinus infection—and then an allergic reaction to the prescribed antibiotic. So, between finishing various deliverables, I've been trying to catch up on my opensolaris.org mailing list traffic. This afternoon, I got to ogb-discuss, the Governing Board alias, which has been exploring the next steps for the Architecture Review process for open development.

A few minutes ago, I replied to one message in the thread, and then reread the message was from Tuesday. Given that I was out three days, this makes quasi-arithmetical sense, as

Friday - ~2.5 days = Tuesday

Maybe in an hour or two, I'll be able to prove "Monday = Monday", give or take.

[ T: OpenSolaris OGB ARC ]

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: OpenSolaris Solaris smf privilege RBAC zones ]

SFW: Integrating coreutils and which variants

Last night, I finished up another task, in an attempt to reduce my current multitasking factor: I integrated initial versions of coreutils and which from the GNU Project into the Freeware consolidation. As a lower priority task, it took longer than a more dedicated developer might have managed, but it's reasonably pleasing to look back:

• initial idea, in case form, proposed and repeatedly revised on companion-discuss,

• draft fast track circulated on sfwnv-discuss,

• fast tracks for /usr/gnu, coreutils, and which submitted as open PSARC fast track cases,

• preliminary, intermediate, and final code reviews on sfwnv-discuss, and,

• finally, an integration message to sfwnv-discuss.

There's still a bunch of process associated with SFW that requires redesign—legal review and Section 508 compliance, in particular—but I think, barring the latent intervals, this sequence was a reasonable consensus-driven open development experience.

If you look at other opensolaris.org mailing lists during June – November and February – April, you'll be able to verify that I was indeed working—just on other things, and not just surfing the Web...

Of course, now that I know that these commands will start to show up more widely when Build 67 is released, I can update my dotfiles, so I get the versions I prefer:

$ svn diff
Index: sh-functions
===================================================================
--- sh-functions        (revision 91)
+++ sh-functions        (working copy)
@@ -36,6 +36,10 @@
                        PATH=$HOME/bin:$HOME/bin/$(/usr/bin/uname -p):$PATH
                        MANPATH=$HOME/man:$MANPATH
                        ;;
+               gnu)    # PREPEND: Bundled GNU command variants
+                       PATH=/usr/gnu/bin:$PATH
+                       MANPATH=/usr/gnu/share/man:$PATH
+                       ;;
Index: bashrc
===================================================================
--- bashrc      (revision 91)
+++ bashrc      (working copy)
@@ -49,8 +49,12 @@
        path clear home sfw csw
 fi

-if hash gls > /dev/null 2>&1; then
-       alias ls="gls --color -CF"
+if [ -x /usr/gnu/bin/ls ]; then
+       alias ls="/usr/gnu/bin/ls --color -CF"
 fi

+if [ -x /usr/gnu/bin/which ]; then
+       alias which="/usr/gnu/bin/which"
+fi
+
 export CDPATH=$MACHINE_CDPATH_PRE:$HOME/projects:$HOME:$MACHINE_CDPATH_POST

If you're using a distribution that offers SUNWgnu-coreutils, SUNWgnu-which, and the other /usr/gnu packages, do share your feedback with the maintainers on sfwnv-discuss—or become one and pick your favourite package.

[ T: OpenSolaris Solaris SFW coreutils which ]