Cover V14, i09

Article

sep2005.tar

The Opening of SolarisTM

Peter Baer Galvin

Welcome to the new Sun Microsystems. A couple of years ago, Sun was as closed as a Cape Cod oyster. Communications were very controlled, and the Solaris source code was a very well-guarded secret. Fast forward to June, 2005. Now it seems that everyone within Sun has an opinion or technical detail that they are sharing through blogs.sun.com. Even more startling, Sun has followed through on their promise to open source the Solaris operating system. This month, I'll take a look at the OpenSolaris project, explore what's available, and walk you through downloading, building, and installing Solaris from the OpenSolaris project. What does OpenSolaris mean to Sun? What does it mean to you?

The Theory

Sun has long stated that they would make Solaris an open source project. Along the way, there were unfortunately delays and speed bumps, stretching out the delivery date. Most of these delays seem related to the legal aspects of code ownership and licensing format. The result is that Sun created a new open source license, the CDDL. This CDDL has been covered elsewhere with much detail and quite a bit of gnashing of teeth. I'll leave it to those in the open source community to debate, but the license seems reasonable, and very open, in general. For example (in my opinion -- I'm not a lawyer), anyone could take the OpenSolaris source code, modify it, and sell either the modification or the entire package.

Will the open source community embrace and extend OpenSolaris? That is the big, open question. There are signs that they will, though, and why not? Solaris 10 is "the best" operating system available. Now that developers can get their hands on it and modify it, I believe they will. Details of CDDL are available at:

http://www.opensolaris.org/os/licensing/
But what is the OpenSolaris project? It is a community development effort based on the Solaris source code. Sun acknowledges that it is a work in progress that will evolve (in full public view). Currently, there is some complexity involving what is available and how to use it. That is the topic of the remainder of this column.

Overview

http://opensolaris.org is ground zero of the OpenSolaris project. There you can find instructions on downloading and building OpenSolaris. There are quite a few surprises in store for anyone exploring opensolaris.org. Not the least of which is that the project is well cooked and ready for prime time. Following the instructions on the site, it is rather easy to download the source for OpenSolaris and build the entire binary set that comprises commercial Solaris.

If your purpose is just to peruse the source code, a tarball download gets all of the available code. Note that this is not the same as all of the code that goes into Solaris. There are some files that Sun does not own the rights to redistribute as source code, so those are provided in a separate binary-only tarball. A count of the directory tree from the "closed" tarball shows ~6,500 entries, but many of those are empty directories. This is opposed to ~85,000 entries from the source code tree. So, in fact almost all of the OpenSolaris project distribution is available in source format.

To actually compile the source and create binaries, you first need a very recent build of Solaris. In fact, the version you need is the Solaris Express: Community Release (currently "Nevada build 16"), which is more recent than the one currently available via the standard Solaris Express. (That release is "Nevada build 15".) Apparently this build is needed to fix bugs in the ability to build OpenSolaris. Moving forward, any release from Nevada 16 onward should be able to build the OpenSolaris project.

Note that the Solaris Express release goes through multiple weeks of testing before it is made available, and that no such testing is done of the builds available via OpenSolaris. Clearly, this release should be used only for development. I intentionally do not call Nevada 16 either Solaris 10 or Solaris 11. All of the bits of a new minor or major release from Sun tend to get mixed together until decisions are made about release dates and feature sets. Within Sun engineering, all changes are added to the most recently opened "gate" (or development tree). That is, if a Solaris 11 gate is created, all changes must be added there first and then integrated into the older gates (i.e., Solaris 10 Update 1) over time. This required "soak" time of changes results in higher quality and lower bug counts. Nevada is the latest gate, and features from it may show up in Solaris 10 Update 1, Solaris 11, or both.

A further surprise is that the source can be compiled via GCC or the Sun Studio compiler suite, and that a license for Sun Studio is available at no cost. The site (http://www.opensolaris.org/os/community/tools/sun_studio_tools/) states that Sun Studio software "is being provided, free and unrestricted, to participants in the OpenSolaris Community". Whether this means that Sun Studio can be used for free on platforms other than Nevada 16, or for purposes other than compiling OpenSolaris, is currently unclear.

A final pleasant surprise is that the source code is very up to date. According to sources at Sun, the source code at OpenSolaris is about 2 weeks behind the bits that are currently checked in to the Solaris source at Sun. As of the time of this writing, the source was for Nevada build 17 plus some bits of build 18. That difference is expected to close over time, to the point that OpenSolaris gets the code from Sun at the same time as it is injected into the commercial Solaris source tree. Simply astounding!

In terms of unhappy surprises, there are still a few rough edges. For example, you can't create official "packages" out of any source builds at the moment. More is documented in the release notes that accompany the source downloads.

In general, the launch of OpenSolaris seems well thought out, and has a lot of momentum. Available with the project is a bug database, a source browser, and lots of community discussion.

The Download

With all of that background in mind, it is finally time to download OpenSolaris. There is a good overview of the steps needed to download and build OpenSolaris available at the main site, along with a roadmap of the future of OpenSolaris. The download process is simply a matter of reading the release notes, selecting the appropriate files to download, and waiting for all the bits to move. Sun actually provides three ways to move bits -- the Sun Download Center, BitTorrent, and genunix.org.

Actually, there are two choices to make. For example, OpenSolaris can be built from a set of pre-built archives, or you can build it from source. Also, you need to select the compiler.

The files to download include the current Solaris Express: Community Release build (i.e., Nevada Build 16 binaries), the chosen compilers (Sun Studio or GCC), tools to use to build OpenSolaris (the "ON" tools package), and the source or pre-built archive files. Unpack each file according to its kind and the instructions, and then it's (almost) time for the big build.

Before we look at building OpenSolaris, we should take a moment to admire the OpenSolaris source. The choice of parent directory is yours. I selected /opt/src/nevada. Note that selecting to download the source results in a directory tree of 1.8 GB, so there is a lot of source to explore. Actually, the tree includes "usr", which is the source tree; "archives", which is the output of a build; "closed", which includes the encumbered binaries that are not provided in source form; and a "proto" directory for use by Install(1). Using the online source browser is a nice way to find what you are looking for, without manually searching through the code. There you can search by definition, symbol, file path, and history, as well as do a full search on everything. For example, a "path" search for "usr/src/cmd/ls" reveals "ls.c" as well as some make files. Clicking on "ls.c" shows the formatted and highlighted full source for the ls command.

Build

Once a system is built based on Nevada 16, compiling the source into usable binaries can begin. Some patches are required, as spelled out in the release notes. There is a full Developer's Reference manual as well that describes the entire build process, archives, BFUs, and so on, available at:

http://www.opensolaris.org/os/community/onnv/devref_toc/
Also included there is a nice tour of the source code organization.

Next, an environment file is needed to guide the build. One can be copied from usr/src/tools/env/opensolaris.sh to opensolaris.sh (or some other name) and then modified to include path and permission information (the GATE, CODEMGR_WS, VERSION, and STAFFER variables).

The system I used for testing is a slow-ish (1 GHz) x86-based PC. Running the nightly command performs a full, silent build of the entire OpenSolaris source tree as in nightly ./opensolaris.sh &. On my system, it took between 3 and 4 hours. Once a full build is done, builds of only the changed components can be done via nightly -i ./opensolaris.sh &. A complete log is created in log/nightly.log, and the build progress can be monitored via ptree.

Install

Once a build is complete, the binaries can be used in situ or can be installed into the proper places on the current system. If you want to do a full install of the binaries built during a full build, it's best to run nightly with the -a and -z options to build gzip archives. Then the bfu command can install the archive on the system. A reboot then brings up OpenSolaris as built from source.

If you just want to build a new kernel (say kernel.peter), there are a few options and some best practices. First, perform a "nightly" to build the whole source, including the kernel. Second, source the build environment script file (in this example "opensolaris.sh") to set the variables in your shell. Third, use "Install -XG kernel.peter" to create a tar file in /tmp/Install.root of kernel.peter including all of the kernel modules you built. Fourth, untar the tarball in "/". And, finally, boot the system using the new kernel via the boot path:

kernel.peter/sparcv9/unix - for SPARC
kernel.peter/unix - for x86 32-bit
kernel.peter/amd64/unix - for x86 64-bit
When using Install, keep in mind that you should always specify your own path like "kernel.peter" so that you can boot back to the known working kernel if your new one fails to boot.

Other Stuff

Open Solaris is very big. People outside of Sun are just starting to find their way around it. The Sun blogs help a lot. Specifically, check out those by Eric Boutilier and Bryan Cantrill. Eric Schrock is blogging about how to add a system call and source in general to OpenSolaris.

Another good way to track all of the blogging about OpenSolaris is to use the Technorati tags:

http://www.technorati.com/tag/opensolaris
As a final off-topic note, there is a good Sun Blueprint now available describing zone and including best practice information. Have a look at:

http://www.sun.com/blueprints/0505/819-2679.html
Special thanks go to Mike Shapiro, Jackie Bao, and Kristin McClintock for providing information for this column.

Conclusions

We are indeed facing a brave, new, open Sun. There are early signs that Sun's efforts at building a vibrant open source community around OpenSolaris are working. Within days of the release of OpenSolaris, a team of OpenSolaris beta testers released the ShilliX project. The first piece of the project is an .iso file that can be used to create an OpenSolaris-based CD. This CD can be used as a "live CD" -- boot it and run OpenSolaris without having to install OpenSolaris to a hard drive. It can also be used as an install CD for OpenSolaris. Very handy indeed. Let's hope there is much more to follow from ShilliX and others. OpenSolaris should allow for a lot of innovation in and around the standard Sun Solaris.

Peter Baer Galvin (http://www.petergalvin.info) is the Chief Technologist for Corporate Technologies (www.cptech.com), a premier systems integrator and VAR. Before that, Peter was the systems manager for Brown University's Computer Science Department. He has written articles for Byte and other magazines, and previously wrote Pete's Wicked World, the security column, and Pete's Super Systems, the systems management column for Unix Insider (http://www.unixinsider.com). Peter is coauthor of the Operating Systems Concepts and Applied Operating Systems Concepts textbooks. As a consultant and trainer, Peter has taught tutorials and given talks on security and systems administration worldwide.