Attention: The patch policy has silently been changed by Oracle quite severely. The new strategy, which is also documented in Software Update Entitlement Policy for Solaris, enforces the requirement of a support contract to download any patch.

Unlike before, even security patches are not available for free anymore.

Until recently, Solaris 10 was free to use and Sun provided security patches for free as well; if you wanted further support you had to pay. It’s a widely used economic model in the open source world and has the great advantage of “hooking” up small companies to your products by still making them usable in a production environment.

At the company I’m working at, that’s exactly what happened with MySQL: we could use it for free to see if it fitted our needs and when the time came for us to need support, we paid for support. Everyone wins.

Now Oracle has pretty much cut every small Solaris user from using it in a production environment, to me it looks like they don’t even want to care about them. Solaris is still used in a lot of big corporations who pay a lot of money for support, but I wonder how long this will last…Just for fun I’m pasting some phrases from Oracle’s documentation:

• A separate Sun support contract is required for every system to which you apply Solaris Software Updates, including test and development systems.
• If your support contract lapses, you loose the right to use most Solaris OS patches and you must remove them from all systems.

Remove patches from a system, is this a joke? Did the guys who decided that already work in IT? Yeah great Oracle, that’s REALLY a good way to treat your future customers. Now you can be sure that I will try to replace every Solaris I see with a Linux box.

It’s sad for Solaris, the technology behind the OS is good but due to bad management decisions it’s getting less and less market-share. I feel sorry for the few passionate people behind Open Solaris.

Some may argue that RHEL is also a paid OS, but at least it’s clear from the beginning and Red Hat donesn’t screw their customers with dodgy moves like that in the middle of a product life-cycle.  And you still have CentOS if you don’t want support. What Oracle just did is a hold-up against the small Solaris users and I’m really angry at them.

Solaris 10 feels particularly old compared to modern Linux distros  like Fedora or enterprise-class Linux distros like CentOS/RHEL, but there are also a couple of very cool technologies included. This blog post is probably the first of a series dedicated to Linux -> Solaris migrations, and how we can learn things from Solaris to improve Linux.

So, the first thing I want to talk about is the updates management.

In Fedora, we have yum/PackageKit to nicely handle the whole process: download the updates and install them. In Solaris 10, there is a jungle of mostly useless applications to download the updates; obtaining them is bit like being in hell, only worse. The most convenient way is to use an application called Patch Check Advanced. But once you have downloaded the updates for your system, you can apply them in a WAY cooler way than in Linux. Let me explain how it works…

First, you have to know that Solaris now comes with a file system called ZFS, which we can’t have in Linux for legal reasons as far as I know. This file system is very similar functionality-wise to Btrfs that we should see in Linux in a couple of months (oddly enough, both “belong” to Oracle now); ZFS supports something called “snapshots”.

Snapshots give you the opportunity to create an exact copy of any file system on the fly in a matter of seconds, without any performance degradation nor disk space use (best case). You can see it as a backup, it’s very similar to Apple’s Time Machine. To handle updates, Solaris 10 uses a set of utilities called “Live Upgrade”, what they do is:

• Create a snapshot (at the file system level, with ZFS) of you whole root partition
• Apply the patches you have downloaded to this snapshot
• Create an entry in GRUB to boot from this “new root” snapshot at the next reboot

The end result is that at the next reboot, you can see if your system still works well with the applied updates.

• It you are happy, you stay with this new root and delete the old one
• If you are unhappy, you reboot to the old root and your system is in its old state

Simply imagine how cool this is for critical servers, or even the end user. You don’t mess at all with the software currently installed, there is no risk as you can roll back and the only downtime you have is the reboot.

With Btrfs coming to Linux, we could absolutely do the same thing, and I’d like to see that. I’m just useless to make that happen in Fedora, but I can at least raise awareness on this with this blog post. I know that this requires a massive paradigm shift for the way we handle updates, we need to move from a “per application update” to a “complete OS state update”. Instead of selecting a specific kernel to boot in GRUB, you would select a system state.

On a side note, OpenSolaris’ package manager (similar to PackageKit) does exactly that.

Here is a complete Live Upgrade sequence I did on a Solaris 10 box

[root@sol10 /]$ lucreate -n s10Aug2209 (We create a / ZFS snapshot called s10Aug2209)
Checking GRUB menu…
Analyzing system configuration.
No name for current boot environment.
INFORMATION: The current boot environment is not named – assigning name <root-dataset>.
Current boot environment is named <root-dataset>.
Creating initial configuration for primary boot environment <root-dataset>.
The device </dev/dsk/c0d0s0> is not a root device for any boot environment; cannot get BE ID.
PBE configuration successful: PBE name <root-dataset> PBE Boot Device </dev/dsk/c0d0s0>.
Comparing source boot environment <root-dataset> file systems with the
file system(s) you specified for the new boot environment. Determining
which file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
Creating configuration for boot environment <s10Aug2209>.
Source boot environment is <root-dataset>.
Creating boot environment <s10Aug2209>.
Cloning file systems from boot environment <root-dataset> to create boot environment <s10Aug2209>.
Creating snapshot for <rpool/ROOT/root-dataset> on <rpool/ROOT/root-dataset@s10Aug2209>.
Creating clone for <rpool/ROOT/root-dataset@s10Aug2209> on <rpool/ROOT/s10Aug2209>.
Setting canmount=noauto for </> in zone <global> on <rpool/ROOT/s10Aug2209>.
Creating snapshot for <rpool/ROOT/root-dataset/var> on <rpool/ROOT/root-dataset/var@s10Aug2209>.
Creating clone for <rpool/ROOT/root-dataset/var@s10Aug2209> on <rpool/ROOT/s10Aug2209/var>.
Setting canmount=noauto for </var> in zone <global> on <rpool/ROOT/s10Aug2209/var>.
Saving existing file </boot/grub/menu.lst> in top level dataset for BE <s10Aug2209> as <mount-point>//boot/grub/menu.lst.prev.
File </boot/grub/menu.lst> propagation successful
Copied GRUB menu from PBE to ABE
No entry for BE <s10Aug2209> in GRUB menu
Population of boot environment <s10Aug2209> successful.
Creation of boot environment <s10Aug2209> successful.

[root@sol10 /]$ zfs list (we look at the ZFS partition list, we can see that we have snapshots)
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
rpool                                   10.4G   446G  38.5K  /rpool
rpool/ROOT                              1020M   446G    18K  legacy
rpool/ROOT/root-dataset                 1020M   446G   804M  /
rpool/ROOT/root-dataset@s10Aug2209      64.5K      -   804M  -
rpool/ROOT/root-dataset/var              216M   446G   216M  /var
rpool/ROOT/root-dataset/var@s10Aug2209    98K      -   216M  -
rpool/ROOT/s10Aug2209                     92K   446G   804M  /
rpool/ROOT/s10Aug2209/var                   0   446G   216M  /var
rpool/dump                              4.88G   446G  4.88G  -
rpool/export                              48K   446G    19K  /export
rpool/export/home                         29K   446G    29K  /export/home
rpool/swap                                 4G   450G    16K  -

Download the patches in /var/tmp/10_Recommended with Patch Check Advanced.

[root@sol10 /]$ luupgrade -n s10Aug2209 -s /var/tmp/10_Recommended -t `cat patch_order` (we apply the patches to the snapshot)

[root@sol10 /]$ luactivate s10Aug2209 (we activate the updated snapshot for the next boot)
Generating boot-sign, partition and slice information for PBE <root-dataset>
Saving existing file </etc/bootsign> in top level dataset for BE <root-dataset> as <mount-point>//etc/bootsign.prev.
A Live Upgrade Sync operation will be performed on startup of boot environment <s10Aug2209>.

Generating boot-sign for ABE <s10Aug2209>
Saving existing file </etc/bootsign> in top level dataset for BE <s10Aug2209> as <mount-point>//etc/bootsign.prev.
Generating partition and slice information for ABE <s10Aug2209>
Copied boot menu from top level dataset.
Generating multiboot menu entries for PBE.
Generating multiboot menu entries for ABE.
Disabling splashimage
Re-enabling splashimage
No more bootadm entries. Deletion of bootadm entries is complete.
GRUB menu default setting is unaffected
Done eliding bootadm entries

Modifying boot archive service
Propagating findroot GRUB for menu conversion.
File </etc/lu/installgrub.findroot> propagation successful
File </etc/lu/stage1.findroot> propagation successful
File </etc/lu/stage2.findroot> propagation successful
File </etc/lu/GRUB_capability> propagation successful
Deleting stale GRUB loader from all BEs.
File </etc/lu/installgrub.latest> deletion successful
File </etc/lu/stage1.latest> deletion successful
File </etc/lu/stage2.latest> deletion successful
Activation of boot environment <s10Aug2209> successful.

[root@sol10 /]$ init 6 (we reboot)
propagating updated GRUB menu
Saving existing file </boot/grub/menu.lst> in top level dataset for BE <s10Aug2209> as <mount-point>//boot/grub/menu.lst.prev.
File </boot/grub/menu.lst> propagation successful
File </etc/lu/GRUB_backup_menu> propagation successful
File </etc/lu/menu.cksum> propagation successful
File </sbin/bootadm> propagation successful

[root@sol10 /]$ lustatus (we check the boot environments we have)
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
————————– ——– —— ——— —— ———-
root-dataset               yes      no     no        yes    -
s10Aug2209                 yes      yes    yes       no     -

[root@sol10 /]$ ludelete root-dataset (we delete the old root)
System has findroot enabled GRUB
Checking if last BE on any disk…
BE <root-dataset> is not the last BE on any disk.
Updating GRUB menu default setting
Changing GRUB menu default setting to <0>
Saving existing file </boot/grub/menu.lst> in top level dataset for BE <s10Aug2209> as <mount-point>//boot/grub/menu.lst.prev.
File </etc/lu/GRUB_backup_menu> propagation successful
Successfully deleted entry from GRUB menu
Determining the devices to be marked free.
Updating boot environment configuration database.
Updating boot environment description database on all BEs.
Updating all boot environment configuration databases.
Boot environment <root-dataset> deleted.