Three days ago, I finally received another Qube with two shiny new disks and found that at home my 5 year old PC has an ethernet controller old enough to permit the recovery disk to boot. This part of the process is really neat and hard to get wrong. (I have initialised the Qube from the OS recovery disk. This involves booting another computer using the recovery disk which is a Linux disk. This system acts as a boot server and I configured the Qube to boot from the net.) I have just finished running the upgrade process for the Qube. Given the OS was published in 2001, there are 73 upgrades and order is significant.
This is in fact my second attempt at doing this, so I know that my plans to install ssh will at the least generate a warning because the distributed version of zlib is less than current and has known security vulnerabilities, which the ssh configure process identifies. The Sun sites state that a zlib patch should be installed. This was not discovered by my Qube’s web form, but I installed it manually. I couldn’t find a bookmark feature for the patches themselves. The manual install is neat, but the persistent requesting for permission to proceed and the multiple reboots makes the whole task long and tedious, and requires constant intervention. I assume that the failure to improve this is part of Sun’s “management” of the Cobalt product range.
Its possible that automating software updates, with a rigorous dependency management functionality is a difficult problem to solve as my experience with other Linux distro’s software update mechanisms has not been particularly happy. I’d also need to look at Sun’s current Solaris offering and see if we’ve learned anything from the Cobalt experience before I make a final judgement. I’d have thought it was easier with an appliance; the vendor has a right to expect more control; the only build standard is the appliance vendor’s.
Anyway its done now!
Originally posted on my sun/oracle blog, republished here in Feb 2016.