I used to have a soft spot for Sun. I cut my teeth on a Sun 3/50 running SunOS 4.1.1, marvelled at the crystal-clear screen of the SPARCstation SLC, struggled with the half-baked Solaris 2.1 x86, schlepped countless Ultra 10s around a big EDA shop, and ran lots of mid-range Sun hardware. However, since Oracle took over, in my view there has been a loss of interest in small- to medium-sized systems, and a significant regression in the quality of support. For me, it’s no longer a value proposition.
However, I have quite a few (what I now regard as) legacy systems running Solaris, so I have to keep my hand in. At the beginning of the year I decided that I should start playing with Solaris 11 with a view to upgrading my existing systems. Solaris has always been a bit quirky, but it had a few surprises in store for me. Hopefully this post will mitigate the shock of those planning a move to 11.
So without further messing about, here are some things you should know before taking the plunge.
Upgrade or Install? Erm… Install, I suppose…
The first little surprise is to be found in Oracle’s document Transitioning From Oracle Solaris 10 to Oracle Solaris 11:
Ouch. That’s a departure from pretty much every operating system I’ve ever used. It’s an indication of the scale of change from Solaris 10 to 11 that Oracle decided not to provide a simple upgrade path. I admit to being entirely ignorant of the reasons behind this decision, but it seems very odd to me. What’s more, users of Solaris 11 Express have been having all sorts of problems upgrading to the release version.
There are no upgrade methods or tools available to transition from Oracle Solaris 10 to Oracle Solaris 11. You cannot use an installer to upgrade from Oracle Solaris 10 to Oracle Solaris 11. You must perform a fresh installation of Oracle Solaris 11 by using one of the installation options described in this chapter.
Oracle does provide a procedure called Transitioning an Oracle Solaris 10 Instance to an Oracle Solaris 11 System, enabling you to port your Solaris 10 global (or non-global) zone to Solaris 11. However, you will end up with a non-global zone, even if your original system only had a single zone (and if you use Solaris but don’t know what zones are, this includes you). In other words, you can virtualise your Solaris 10 system inside Solaris 11, but that’s the closest thing there is to an upgrade. Given that Solaris 10 will get patched until January 2018, do you really want to do this now?
While we’re talking about installation, you can also wave goodbye to
- Installing with flash archives (flar)
- Live upgrade (lu* commands)
- Jumpstart (gasp!)
Jumpstart is now ‘Automated Installer’ (or ‘AI’). There’s a document with a migration procedure from Jumpstart to AI. Unfortunately,
JumpStart installs the Oracle Solaris 10 OS and earlier versions of the Oracle Solaris OS. AI installs the Oracle Solaris 11 OS.
So if you have a mixed environment, you’ll need a Jumpstart server and an AI server. What’s more, you’ll need to oil your angle bracket keys, as AI uses XML for its config files. My personal opinion: yuck.
Packages and patches
Ah, something good to talk about. After years of unbearably slow patching and terrible package dependency handling, the packaging and patching system used in every previous version of Solaris has finally been replaced. The headline ‘gotchas’:
- Wave goodbye to pkgadd and patchadd
- /var/sadm/install/contents begins life as an empty file
- At the time of writing, Patch Check Advanced (pca) only supports Solaris 11 with its development version
In fact, pkgadd and friends are still there for legacy packages, but the preferred method for managing software is to use the ‘Image Packaging System’ (IPS). Apparently there’s a GUI (I haven’t tried it), but on the command line everything centres around the pkg command. Both package management and patching use the IPS, and files are retrieved automatically from Oracle (and perhaps other vendors) as required.
You’ll already know that you can’t get Oracle’s patches without an active support contract, so you have to tell the IPS the credentials you use to access Oracle’s horrible support portal. This is a bit of a faff involving the download of an SSL certificate/key pair, but it does work. After that, patching the system is a simple case of pkg update. Patching is much faster than previous versions of Solaris.
I haven’t had much experience with IPS yet, and couldn’t find many good resources out there for sysadmins (as opposed to packagers). There are some Google references to Sun wikis, but they seem to have been broken by Oracle and/or require a login. I did find a blog post referring to a comparison between IPS and apt-get commands, but sadly the table he refers to has vanished along with much of the Opensolaris website. Here’s the IPS to apt-get command comparison table from the Wayback Machine.
No root logins on the console
Personally I prefer sudo. I know that RBAC is very powerful and flexible, but it’s also quite rare to see it used to its full potential. Most of my Solaris boxes are fileservers (or something else very simple) and don’t need all this role malarkey. I also prefer a root account that I can use directly. I know it’s naughty, but I like to be able to login as root on the console, because then I know that I always have a way in if I really need it (obviously remote access to that account is disabled). It’s a bit like the fact that all sysadmins should know vi, because—unless your systems are truly ancient—vi will be present on every system you manage. There’s a nice blog post on how to turn root back into a normal account if you feel the same way.
More to come…
It’s early doors for me and Solaris 11. These are just the things that I fell over in the first few days, but I’m sure there will be more to come. I’ll update this post with my findings as I go along, so keep your eyes peeled.