I have to start by giving the punch line first: I’m just appalled at Novell’s support story around SLES and SLED 10. In this article, I’ll explain why.
Those of you using Novell’s Enterprise products may have noticed that they quietly stopped issuing patches against SLE 10 GA in June, and that you must upgrade to SLE 10 SP1 in order to get the newest patches. (Nobody will actually tell you this, of course; you must deduce it from the fact that all security advisories since June that apply to SLE 10 only reference SLE 10 SP1.)
Those of us in the know (or those of us unfortunate enough to be running SLE 10 in the field) know that SLE 10 was a terrible product. Among other things, it can’t perform basic functions such as registering a and activating itself against Novell’s update servers in a consistent way. Activation codes don’t work, the update server is frequently down, etc. etc. (not to mention that ZMD is slower than a crippled grandma crossing the street, as I’ve already pointed out in other posts). So why won’t Novell just come out and admit that it made a mistake and that everyone should move to SP1?
My hypothesis is that it’s due to misguided damage control over at Novell. Novell can’t continue to issue patches against GA, because one of the critical bugs in GA is that one can’t update the installation, nor can one even successfully activate the product! So someone’s solution was to pretend that SP1 and GA are completely different products (vis-a-vis the patches by product page, which seems to indicate that they are distinct), and just silently stop supporting GA (by not issuing patches). But wait! Novell has a support lifecycle chart that states SLE 10 (no qualifications on SP-level) will be supported until 31 Jul 2011. How to reconcile the two contradictions? I’ll bet support tells customers who invoke the lifecycle chart that they should move to SP1 in order to meet Novell’s obligations under the chart. I think they probably just assumes everyone else will give up on GA and apply SP1 in frustration.
To add insult to injury, it’s not like one can actually identify whether one is running SLE 10 SP1. The bundled SPident tool claims that a SLES10 GA system that was patched with online updates is not SLE 10 SP1 (I’m actually doing this on SLED, but the same problems hold with SLES):
jdunn@empire:~> SPident CONCLUSION: System is NOT up-to-date! found SLE-10-i386 + "online updates" expected SLE-10-i386-SP1
But then /etc/SuSE-release claims that it is:
jdunn@empire:~> cat /etc/SuSE-release SUSE Linux Enterprise Desktop 10 (i586) VERSION = 10 PATCHLEVEL = 1
So how the heck does one actually get to SP1? Does one try to apply all the patches against GA (assuming one can even get one’s server registered and activated?) Does one insert the SP1 CD on all GA servers and apply patches that way? And at the end of this pain and suffering, how does one even know that one has an SP1 box? rpm -qa | sort | mailx [email protected] and ask them to run a diff against a known server?
My conclusion: Novell just doesn’t have it together. They release an OS that you can’t patch. Then, once you do patch it using some out-of-band means (e.g. downloading patches over HTTP and applying them by hand, or hacking YaST to make it go, etc.) the system still doesn’t identify itself as fully patched. These are basic issues with the operating system that any rudimentary amount of quality control ought to have caught at the factory. Do they really just want everyone who hasn’t already moved to Red Hat Enterprise Linux to go there? I guess now I can understand the feelings of the bitter German ex-SUSE engineers who (rightly) concluded that Novell has swooped in like a bat out of hell and wrecked a perfectly decent Linux distribution.