OpenSolaris is essentially GNU-Solaris. When talking about the user experience, one could say that since the GNOME desktop is used, running OpenSolaris is no different from running Linux. For the casual Web, e-mail, and office applications user this may be true. For us network and systems administrators, however, we need to be more careful about jumping ships.
This article will explore some not-so-obvious considerations we must pay attention to if we expect to switch desktops and remain productive.
A robust package manager backed by a large open source software repository is useful for more than just convenience. It allows the user to test software they may have not previously heard of. Being able to quickly install a piece of software you’ve heard about to give it a test is extremely useful.
We also need to have the ability to test things that may end up on production systems. Ruby or Perl modules, for example, are often needed when developing automation scripts. Of course, this often leads to frustration if we aren’t careful. Say a fancy new Perl module is available via CPAN, so we install it and start to depend on it. Then when it come time to run the new script on production server, which probably don’t use CPAN, we find out that the module isn’t available as a package.
In addition to writing scripts, it is also a good idea to ensure your desktop is running the same OS version as your production servers so that you can test other configuration aspects as well. Unless, of course, it is easy enough to run virtual machines; more on that in a bit.
The OpenSolaris software repository has almost doubled in size in the last year. At over 25,000 packages, it is beginning to rival the package count of many Linux distributions.
Dealing With Java
Unfortunately, a large majority of management interfaces require Java. Storage arrays, blade servers, servers’ lights-out management, application server administrative interfaces; the list is endless. The bright side is that OpenSolaris is from Sun, and its Firefox ships with Java working. The not-so-bright side it is often necessary to have an old version of Java lying around to run older applications. In the end, this comes down to package management.
There is only one Java available in the OpenSolaris repositories at this time. That means you will need to manually install older versions of Java or run VMs with older OS versions to connect to those aging management consoles.
We often need to implement some fancy networking tricks in order to test or administer services. The two most often used advanced networking features are: 802.1q tagging and VPNs.
Using 802.1q VLAN tagging allows you to configure your machine to live on multiple VLANs with only one physical link. This is extremely useful for testing, where you need to ensure everything works on various networks. Plopping your desktop on a management network also allows you to access management interfaces without resorting to VPN or adjusting firewall rules. OpenSolaris does support 802.1q tagging, but only on a subset of network cards. You will need to ensure your network card driver supports tagging if you wish to use this feature.
Connecting to VPNs is often necessary to gain access to management networks or other secure networks you need to administer. Connecting to the various types of VPN technologies is not as easy in Solaris as it is in Linux, but it is possible. Solaris supports everything from IPIP tunnels to IPSEC VPNs, and recently someone even ported the Linux PPTP client (for connecting to Windows VPNs) to work on Solaris.
Since September of 2008, Sun’s virtualization solution has been open source and easily available. Sun xVM, as it’s called, is actually four different technologies combined into one umbrella service. The main “guts” of xVM for our desktop usage is VirtualBox, which Sun acquired and began improving a few years ago.
VirtualBox runs on Windows, Linux and even Mac OS X. On OpenSolaris, however, VirtualBox has distinct advantages. In Solaris, each guest operating system can run under a Solaris Container, which allows administrators to apply constraints that Containers support. These include broad RAM and CPU limits, in addition to even more granular controls that Solaris Containers are known for.
Running test instances on your desktop, as mentioned earlier, allows for the testing of applications and services that are destined to move into production. Virtualization, in this use-case, is an indispensable tool for systems testing and development. If your site uses Sun’s xVM Ops Center and xVM Server, then the testing and development in xVM VirtualBox on your desktop is a great starting point for testing VMs before deploying them on xVM server.
OpenSolaris has been running on my work desktop for the last four months. ZFS snapshots make testing dangerous things much less frightening, and VirtualBox allows me to run CentOS, FreeBSD, and anything else I need to. The Java issues mentioned above are really the only pain points with using OpenSolaris at this time, but they exist with any operating system.
Overall, OpenSolaris is easy to work with as a desktop. The ever-increasing number of pre-built, open source software packages means that you won’t be left stranded when the need for “the next best thing” comes up. OpenSolaris’s advantages including xVM and ZFS snapshots, provide a big advantage. You will run into things, like connecting to a VPN, that are far simpler in Linux. In the end, it’s all about what features you wish to have, and what features you can handle pulling your hair out for.