Another milestone has been reached by the OpenIndiana team. Release 151a is now out, bringing several key new changes to the table. The biggest one is that OpenIndiana now integrates Illumos, and also includes the kernel virtual machine (KVM), as recently released by Joyent.
You can grab the downloads from http://openindiana.org/download, with several options to choose from:
- Desktop DVD ISO
- Desktop USB installer image
- Server text-based CD ISO
- Server text-based USB installer image
You can browse the full OpenIndiana 151a release notes at http://wiki.openindiana.org/oi/oi_151a+Release+Notes
I’d previously written up a brief note on how to use pgchk to check which package a file belongs to in Solaris. With IPS replacing SYSV packages in Solaris 11 and OpenIndiana, I thought I’d add an update to that post, showing how to accomplish the same thing in IPS.
IPS makes things a lot simpler for us, using the ‘search’ option to pkg.
Let’s check it out on an OpenIndiana oi_147 machine:
-bash-4.0$ uname -X
System = SunOS
Node = grond
Release = 5.11
KernelID = oi_147
Machine = i86pc
BusType =
Serial =
Users =
OEM# = 0
Origin# = 1
NumCPU = 4
The format of the search option is simple – just give it the full path to the file you’re interested in. In this example, I want to see which IPS package contains /usr/bin/ssh:
-bash-4.0$ pkg search /usr/bin/ssh
INDEX ACTION VALUE PACKAGE
path file usr/bin/ssh pkg:/network/[email protected]
Nice and simple, and certainly a lot easier than the old method of invoking pgchk.
pkg search will take a number of extra options:
-bash-4.0$ pkg search -?
Usage:
pkg search [-HIaflpr] [-o attribute ...] [-s repo_uri] query
pkg search will also allow wildcards, like ? and *, as well as specifying a particular IPS repo, with the -s option – which is very handy when you have a custom repo for your infrastructure.
After the Release Candidate was pushed out before the weekend, some last minute issues have been tidied up, and the OpenIndiana project has now officially release the OI_148 development release.
Existing OpenIndiana users can upgrade using the normal image-update process.
Various format images – GUI install, text mode install, USB and AI images – can be downloaded from http://openindiana.org/download/
Release notes can be found at http://openindiana.org/support/documentation/release-notes/ and the Bug Tracker is at http://bugs.openindiana.org/
As always you can head over to the #openindiana IRC channel on Freenode.
The OpenIndiana project has made Build 148 Release Candidate images available for testing. Albert Lee has posted details out to the oi-dev mailing list last night.
If you want to contribute to the b148 testing, please grab an RC image and throw it into VirtualBox to test. The more people who can thrash on these, the better the final b148 release of OpenIndiana can be.
With these RC images now being pushed out, hopefully we can expect a final OpenIndiana b148 build pretty soon.
You can find the paths to download all the different images, plus a list of resolved issues, in Albert’s post to oi-dev, archived at http://openindiana.org/pipermail/oi-dev/2010-December/000102.html
With the dust settling from the unveiling of Solaris 11 Express, it’s time to do a bit of crystal ball work and see what this means for companies deploying Solaris infrastructure.
There are enough new changes here that a lot of people out there are going to get burnt. If you haven’t been keeping up with the OpenSolaris project, or using OpenIndiana, then IPS, AI, and ZFS root are all going to cause you problems. Not to mention /usr/gnu/bin being first in the PATH.
As I’ve said before, IPS and AI still don’t strike me as mature enough to deploy in an enterprise, and I know a lot of people who have spent many years honing Jumpstart who are going to be more than a little cross that there’s no clear migration path to AI.
“Trash it and start again” isn’t a nice upgrade path – the new way of doing things may be cleaner, easier to learn, and make more sense to Linux admins – but it’s a big, fundamental change for Solaris/SPARC shops, and those are the people that pay the bills.
There’s lots of UltraSPARC III and IV kit out there that’s getting towards the end of it’s service life. People are now looking at upgrade paths, and Solaris 11 – and Oracle’s complete offering of tin+OS+support – is going to be the real make-or-break decision point.
The real kicker will be – how soon until Oracle start shipping systems with Solaris 11 installed by default? That will be the real driver that pushed people to deploy Solaris 11 – with no UFS root, no slices, there’s no real reason not to use the pre-installed OS on the tin. Smaller shops with less existing Solaris infrastructure will deploy and think “Hmm, that wasn’t too bad”. Larger shops will find less and less of a reason to put off the migration, especially as the deployed base builds with new kit shipments.
Personally, I’ve been waiting for ZFS encryption for a long, long time – and I’m more than a little suspicious that it’s been held back (in the source as well) until Oracle are suddenly fielding the next commercial Solaris release. I’m sure the Nexenta guys are having similar thoughts.
On the plus side, Solaris 11 Express using the OpenSolaris code base means it makes a lot of sense to deploy it in test environments, and then use OpenIndiana for production. I can see a lot of smaller shops doing this – either having tried out Solaris 11 and then balking at the support costs, or trying OpenIndiana and then seeing there’s not much difference there (apart from the support costs and a few ZFS features).
The real challenge for Oracle here is how well they can make the entire Solaris 11 package work for customers. Higher support costs are fine if you get increased value, but increasingly even larger companies are finding that the support costs are more of a tax – an entry price for playing at the table – rather than a value-add.
OpenIndiana has the potential to be a very big winner here.
There’s some real value in Solaris 11, and some key new features that continue to make it the best operating environment for the enterprise. Are those features – and the support – enough to justify the higher costs compared to OpenIndiana? Is the vertical integration that Oracle are offering enough to justify the higher costs compared to deploying Red Hat on cheaper hardware?
At this stage I’d say it’s still too close to call.