Lately, I have had the chance to dabble a bit in OpenSolaris while working on a particular server installation. OpenSolaris, as you may know, is the recently open-sourced version of Sun's Solaris OS, which in turn is one of the many flavours of Unix. Before I talk a bit about my experience with it, let's consider where OpenSolaris came from. And why should we care about it anyway? The attention is on GNU/Linux as a server OS, and maybe Windows. But traditional Unix OSs - and with that also Solaris - seem to have lost much of their relevance and mind-share. How did that come to pass anyway?

Good times for Sun: The dot-com boom

Let's take a walk back in time. Around 8 to 10 years or so should do. Oh, will you just look at that? We are at the height of the dot-com boom! And wouldn't you know it, Sun and its Sparc-based servers are truly ubiquitous. Any self-respecting, VC-funds-burning startup is running their business on Sun's machines, and even many developers' desktops come from the “Stanford University Network”. I know, I was there in the Silicon Valley when it all happened (“Can you say 'gold-rush'? Yeah, baby!”) and I worked on one of those Sparc/Solaris workstations. Our server room – like that of so many other startups at that time – was stacked full with Sparc/Solaris servers, and our customers were mostly running them as well. Sun at that time was indeed “the dot in .com”, as they claimed in their advertising.

The crash and Sun's declining fortune

Alas, we all know it came to a sad end. With the collapse of the dot-com bubble, Sun was hit hard: Suddenly the excessive flow of VC funds dried up and many of those new, high-flying Sun customers crash landed. Not only did they not buy more Sun gear. No, it was worse: All those failed dot-coms were liquidated, with their assets being cheaply sold off to whoever cared to pick them up. Usually, the only assets they had were their office furniture and their computers. So, at the time of the dot-com bust, not only did lucrative Solaris license sales dry up and support contract sales collapsed as well. No, the Sparc servers themselves couldn't be sold to new customers, since whoever needed a practically new Sparc server was able to pick one up for $2.50 on eBay. Yes, Sun was hit hard. Just take a look at what happened to their stock price during that time:

Sure, Sun had invented Java, which was all the rage back then and which still is very popular. But then and now they have failed completely to monetize on it. Sparc servers really were and are Sun's cash cow. Everything else they did was just aimed at assisting in the sale of more Sparc servers.

Why bother with Solaris now?

But time had moved on. Customers were migrating to Windows, or to the strengthening GNU/Linux. In fact, GNU/Linux made the strongest inroads in the market at the expense of the various Unix variants. Why pay for a commercial, closed-source Unix, if you can get the same sort of look and feel for free and in an open environment? Exactly.

It took Sun many years, but they eventually realised that the only way to remain relevant is to make their products more widely available. To paraphrase a famous line from a certain movie: Build it (or better: Distribute it!) and they (support contracts and such) will come. After years of soul searching and agonising, Sun finally decided to open-source Java and even Solaris itself. Thus, I get back to the start of this article: OpenSolaris. Sun still has the closed-source Solaris, which they probably use for their remaining enterprise customers, but for everyone else who wants to try a 'real' Unix (not some upstart lookalike), well, there is OpenSolaris. Or course, Sun hopes to keep their name relevant, to convert initial OpenSolaris users to their enterprise Solaris, or at least support contracts. Sun has also seen the sign of the times and has made (Open)Solaris work really well on x86 platforms. However, they still like to claim that it actually would run much better on their Sparc architecture. So, it is hoping that eventually some people who start out with OpenSolaris on x86 will move on to Solaris on Sparc.

Technical pros-and-cons of this aside, the jury is still out on whether Sun will manage to stop the bleeding and regain at least some of its former glory with that strategy. Recently, the director of the Linux foundation has laid into Sun, claiming that OpenSolaris is essentially irrelevant. The strongest argument is that OpenSolaris competes with GNU/Linux on basically just a few small features (dtrace, some system management and cool virtualization features (Zones), and of course ZFS, which some people would say is certainly much more than a 'small' feature), but is sorely lacking in community and wider support.

He has a point. Sun, of course, claims that it has signed up more than 160,000 developers to its OpenSolaris community. Well, signing up is not the same as contributing, but some people certainly see the opening of Solaris as a very important and promising point in Sun's history. All criticism from the Linux camp aside, there are still plenty of people who swear by Solaris: It is fast, they claim. For large server installations, it has better maintainability, they claim. It has a reputation of being rock solid. All of these are certainly very interesting points, as well.

Working with OpenSolaris

One of my customers is using OpenSolaris, which gave me the chance now to dust off some of my long forgotten Solaris 'skills' and take another look at it on the server.

Honestly, when you are used to GNU/Linux and log into an OpenSolaris machine for the first time you initially really don't see a difference. Most of the commands you know are there and will work as usual. That is of course no coincidence, since the GNU project set out to specifically provide a familiar environment, re-implementing all the tools and commands people were used to on Unix.

A few minor differences on the command line

Sure, there are some peculiar differences: ifconfig on Solaris requires the '-a' option to show all interfaces, while on GNU/Linux it will do so without any options. To see the running processes, you need to type ps -ef rather than ps auxw. You use snoop rather than tcpdump. The tail command can only watch one file at a time. And so on. It's not huge, but just something to get used to. The GNU developer's tool-chain may also have to be installed first, since it doesn't seem to be there by default.

I was a bit weary, because I needed to install a couple of applications that are common and easily available for GNU/Linux, but are not typically associated with Solaris. Specifically, the nginx web server, squid proxy, django web development framework and the vsftpd FTP server. Fortunately, all of them had been ported to Solaris before, so I just needed to unpack their TAR ball, run the configure script – where available – and then make. Only in the case of vsftpd did I have to track down an issue. I could see that there was specific code and conditional code paths for Solaris in the vsftpd source, but nevertheless, it didn't compile without complaint for me. In the end, I only had to comment out a single line, though. Phew! We have to remember that GNU/Linux and (Open)Solaris are two completely different operating systems, even though at first glance they look and feel the same. So, I was glad that the developers had gone through most of the work for me already.

In general, I would recommend strongly to check whether the particular application one wishes to run has been ported to Solaris before. If so, you are probably good. If not, I know from my previous work experience that it can take quite an effort to get the more esoteric system calls translated in an efficient manner.

The Service Management Facility

What I really liked about Solaris is the Service Management Facility (SMF). I'm sure there are probably comparable tools available for GNU/Linux, but in the case of Solaris, it is all built in by default and very well integrated. The SMF provides a very nice and powerful way to define the services that should run in the system, which other services they depend on, and so on. SMF will resolve those dependencies and arrange the services to start up in the proper order after reboot. If some services fail, dependent services are not started either and the whole thing is logged. The administrator can then resolve the problem. Once given the 'clear' by the administrator, the problematic service and all the services that depend on it are started in one swoop.

SMF also continuously monitors the state of the running service processes. Should they be killed for some reason, SMF will restart them immediately. That is very neat: I can kill nginx, for example, and faster than I can check with ps -ef, it is back up and running again.

You define dependencies, startup, restart and shutdown options and scripts for your services in an XML file, called a 'manifest'. You then tell SMF about the new manifest, and from that moment on, you can use commands like svcadm restart|enable|disable , etc. The svcs -x command shows you all the services that may have had problems starting up, with hints to the relevant log messages that explain the issues. Once fixed, you just say svcadm clear and it should all be up and running.

Very nice, indeed.

None of that is probably very exciting for experience Solaris admins, but for me it certainly was. OpenSolaris is really neat in that way. I hope that it has a good future, since competition is always good for the end user. There are some good ideas in Solaris, which can inspire GNU/Linux as well. In the meantime, I hope that open source projects continue to be ported to OpenSolaris, since as usual, the availability of software really makes or breaks the success of a platform.





Other related posts: