Is Oracle killing Sun Solaris support?

Recently, Oracle has made several changes in Solaris support that have people wondering if Solaris just got too expensive to run.

The first change was to move to a pay-for-security model which some have already compared to extortion. Patches for Solaris would only be available to paying support customers, leaving others to be insecure and without recourse.

The other change that Oracle has made is to force its paying support customers into an “all or nothing” support model: either all Solaris systems are under a support contract or Oracle will not enter into a support agreement. This means that in any environment that all Solaris systems must be accounted for and under Oracle support.

With this latter change, it may be that this pay-for-security model, while still unseemly, will have less of an effect than previously suggested. It may also convince many smaller businesses to scale back their Solaris installations and to get rid of older machines instead of holding on to them.

At its worst, it may mean that support for software on older Sun machines may wither faster, and that older machines will become obsolete – and useless – faster, increasing “churn” in the data center and (perhaps) making the data center more energy-efficient, while costing companies more and making Oracle more money.

However, one thing Oracle has not done is to clarify the future of OpenSolaris. The community is waiting for a definitive statement from Oracle; even former Sun employees working with OpenSolaris have no signs from Oracle in any direction.

UPDATE: Ben Rockwood over at the Cuddletech blog has excellent coverage, with detailed analysis of the relevant licenses and what it means for Solaris end-users. On the 26th he discusses the “all-or-nothing” support model, and on the 28th he writes about Oracle’s choice to remove the ability to use Solaris for free.

Using the HP-UX Software Assistant (swa)

The HP-UX Software Assistant (or swa) is a tool that makes it much easier to keep your HP-UX systems up-to-date. The tool is included for free with HP-UX (or can be downloaded for free) and is very useful; it beats having to go to the ITRC every time you want updates. There is also a very nice manual available online.

There are basically two steps: creating the report (which details what is needed) with the command swa report, and getting the patches to install with the command swa get.

I’ve found that this command is the most useful form to get the report done:

swa report -x crl_check=false -r html > somepath.html

This creates a report and saves it to the path you name (instead of somepath.html of course). The crl_check option turns off the Certification Revocation List (CRL) checking done by swa.

Then, once this is done, you can get the patches with this command:

swa get -x crl_check=false -t /var/tmp/depot

This will put a copy of the patches into a depot at the directory you name. Probably best that that directory be empty to start with. In this case, the depot is to be created in /var/tmp/depot; you could create it somewhere else. However, don’t use a networked drive: that is asking for trouble.

When the patches are downloaded and the depot created, use something like this to install the patches:

swinstall -i -s /var/tmp/depot @ /

This will start an interactive swinstall session with the depot as the source and the local machine as the target. The program swinstall is the standard method of installing depots onto an HP-UX system.

More information can be had from the main swa man page, or from swa-get and swa-report man pages. There is also a command to clean out the caches used by swa (swa clean), as well as a command (swa step) that allows you to perform any solitary step by itself (rather than doing it all at once with get and report). More about these commands are available from the man pages for swa-step and swa-clean.

System Patching

Every year, SANS puts keeping your system up-to-date with current patches the most important thing you can do for system security. Why?

Security vulnerabilities are continually being found by security analysts and system crackers. As fast as they can, programmers and companies fix these problems in the code and release patches to fix them. Thus, the programs become more and more secure (as long as the program isn’t rewritten), and the vulnerabilities (hopefully) then will decrease. Old programs will thus have many vulnerabilities which are widely known – and thus systems running old versions will be much more susceptible to attack.

However, this also has to be balanced against the other risk factor: instability. Introducing new code and patches into an environment can result in more system crashes – a system that never changes (or changes very slowly) will be less likely to have crashes and will be more stable.

If not keeping a system up-to-date goes against your grain (and it should!) consider all of the risk factors: a system that is inside the firewall (and not in the DMZ) and has no extremely valuable data can be patched at a slower rate than a system which is exposed directly to the Internet. Also, if downtime is not a big concern (an hour or two, a day…) then it may be worth patching as soon as possible.

This suggests one thing: keep your home systems current with patches! If it is Internet connected in any way: patch it! Home devices are less likely to be secure and are more likely to be attacked than well-maintained corporate environments.