Slackware Uber Alles!
(I like SuSE too, though.) :)
-Jay
Posted on 02/15/2003 9:33:44 PM PST by Bush2000
New Linux support policies are ominous
By Jon Lasser, Security Focus Online
Posted: 14/02/2003 at 11:33 GMT
Opinion Red Hat and Mandrake are cutting support for older versions of their Linux distributions... The results will be a security nightmare for the Internet, says Jon Lasser.
Open source opponents have for years warned, "You get what you pay for."
Now some Linux distributors are planning to make good on that threat. Red Hat and Mandrake's recently-announced revised support policies might spell the end of the free ride for many companies using Linux.
The policies are straightforward: Red Hat will support their regular distributions for twelve months from initial release. Red Hat's venerable version 6.2 will be retired on March 31st along with version 7.0. Versions 7.1 through 8.0 will expire on December 31st. After the expiration date, security patches will be provided at Red Hat's discretion only.
Mandrake's new policy is similar, though a little more confusing: Mandrake will support "desktop components" of any new distribution for twelve months, and they'll support "base" components, including the kernel and Apache, for eighteen months. Which category the other packages fall into remains to be seen.
Mandrake 7.2 and 8.0's desktop components are immediately unsupported, while their base components will be supported until March 31st. Mandrake will drop support for 8.1, both desktop and base packages, as of March 31st as well. Version 9.0's end-of-life dates are September 30th and March 31st of next year.
How you interpret these announcements depends on what hats you wear: I didn't know whether I should, laugh, cry, or cheer. As a systems administrator, my first reaction was definitely to cry.
Vendor-provided security patches are, unfortunately, the lifeblood of distribution support. Without well-integrated and well-tested patches, maintaining a Unix server takes a lot more work: you have to track every installed package on your system and rebuild necessary subsystems whenever a patch is released.
Though users of commercial Unix distributions have been doing this for years, users attracted to Linux's relative ease of use and maintenance frequently don't have the technical skills to keep up while not falling behind on other important tasks. Without these vendor-provided patches, most Linux users -- and even many professional system administrators -- will have trouble keeping their systems safe.
Twelve or eighteen months is nothing in the life of a production server. In many shops it can take more than six months to certify an application for use. In such an environment the install-test-release cycle would be constant. Furthermore, servers are often hard to update: permissible downtimes may be rare, and co-located servers are even more difficult to handle.
Two Weeks Notice
On the bright side, at least Red Hat and Mandrake have policies that will allow me to plan, or to make other arrangements. I still have a bad taste in my mouth from the Debian 2.1 support debacle. On September 14th, 2000, the Debian project announced that, as of September 30th, support for Debian 2.1 would be dropped entirely.
Two weeks notice is simply not enough time to do even minimal testing before updating a production server doing anything more complicated than serving static Web pages. Furthermore, Debian 2.2 had been released on August 14th -- only one month earlier.
I know that Red Hat and Mandrake have important reasons to limit support for older operating systems: first, open-source software has an unfortunate tendency to live forever -- many users are still relying on versions of Red Hat even older than 6.2, and supporting these primordial distributions is expensive. The QA and build machines need to be supported, and developers must be diverted from more forward-looking tasks. Given that Linux distributors make little money supporting these older releases, dropping patches must seem like a no-brainer from their point of view.
And to their credit, both companies have different rules for "server-class" products: Red Hat will support their Advanced Server for five years, and Mandrake's policy states that server software will be supported for "no less than twenty-four months." Red Hat and Mandrake are clearly banking on support contracts and installations of their advanced server products to generate revenue.
It's not unreasonable to expect people who want commercial quality support to pay for it.
But as an advocate for better computer security, I'm nearly panic-stricken over this move. In the short term, at least, this will be a big negative for practical security on the Internet. Old software doesn't go away just because it's no longer supported, and with network operating systems the consequences could be drastic. Those systems will be sitting ducks for vulnerability scanners, and the size of distributed denial-of-service networks may grow exponentially as a result.
Silver Lining?
After all, many users have come to rely on the auto-update mechanisms provided by vendors, such as Red Hat's up2date tool. When Red Hat's support for 7.3 goes away, tens of thousands of users will have no automated way to apply third-party security patches to the base OS.
As an open-source advocate, I must say this problem is also an opportunity.
We have a large base of commonly used open source applications, and we now have to develop support mechanisms that do not rely on a single commercial vendor. Although up2date is closely tied to Red Hat's proprietary Red Hat Network support offering, an up2date server clone is under development. Its feature set is rather limited at present, but Red Hat's new support policy will undoubtedly drive many users to run their own patch servers.
Another tool that could be used is Connectiva's port of Debian's apt package management front-end to Red Hat's RPM format. Running an apt repository is not difficult and provides an excellent mechanism for continued security updates.
All that is necessary is continued community support for the orphaned distributions, in the form of well-managed projects that follow security updates for core OS components, and then build and extensively test new packages on the target platform.
If you think that this sounds like an opportunity for third-party support vendors, you're right about that, too. I suspect that Tummy.com's KRUD distribution which provides monthly updates to a Red Hat-based system, will gain quite a number of customers. I know of at least one other vendor who is considering a Red Hat support offering including packages for older Red Hat versions.
Open source proponents have long claimed that our community can provide better support than any commercial vendor can. Now we'll have to prove it.
For "free" Linux, switching from Red Hat to SuSE.
(I like SuSE too, though.) :)
-Jay
Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.
Including XFree86 in all future releases of Mac OS X should ensure its place as the preferred Unix desktop system.
Let's all run out and buy Micro$oft products instead. They're supported forever, and have no problems at all!
D@mn man that was over 12 inches ago (height) not 12 months.
Linux is "free" and worth every penny.
After the expiration date, security patches will be provided at Red Hat's discretion only.
Hey, no problemo...since Linux is open source, the users can write their own patches, right???
I don't recall any problems with DOS 2.0 on the machines where I used it, though the first machine I "owned" (actually my Dad's) was MSDOS 2.11; my first personal machine was DOS 3.3 which IMHO was pretty darned good. DOS 5 and DOS 6 were fine as well.
While I'm quite happy with Gentoo on the desktop machines I'm running it on, I'm not quite ready to endorse it for general deployment on servers until Gentoo's distcc integration has matured a bit, and then I'd have to be working in an environment where I could allocate sufficient resources for a strong build farm. Even if I have an excellent build farm that can crank out a new KDE release in one hour, there's the problem with the current staging regime, where packages are either "masked" (not-ready-for-prime-time) or "stable".
If I'm going to use Gentoo on servers, I want a three-level regime, with "testing", "current", and "stable". Too many borked packages have been unmasked in recent weeks for my taste. An intermediate "current" release level would give me a buffer against mistakes like a Perl build with a config.over file that fails to define the MAN*PODS variables so that ExtUtils::MakeMaker fails to generate and install man pages for all Perl modules installed subsequent to the upgrade; or packages that "modulate" between two releases everytime an 'emerge --upgrade' is run. Stuff like that just can't happen on an important system on a regular basis.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.