Handle third-party patches with care, otherwise you could run into "dependency hell" warns, IT professional Michael Jang, who specializes in networks and operating systems. Jang, author of Prentice Hall's Linux Patch Management: Keeping Linux Systems Up to Date, suggests staying your course when it comes to commercial Linux distros in order to take advantage of support.
In this interview, Jang debunks the myth that configuration mistakes are the source of many problems in patch management, recommends how to get the most out of your Red Hat support and gives tips on how to keep your Linux distro current.
How does the Linux distribution patch delivery/source model differ from that of proprietary operating systems? What alternatives exist in the Linux world that don't exist in proprietary circles?
Michael Jang: The differences mirror (no pun intended) those of the operating systems themselves. In other words, Linux uses open source delivery software; most Linux patch delivery systems are publicly available.
Should IT managers stick with commercial Linux vendors as the source of all distro patches?
Jang: Most who select a commercial Linux distribution do so to take advantage of the support. The use of other sources for distribution patches can invalidate support contracts, at least for the package in question.
How do third-party patch packages work? What are the best ways for IT shops to take advantage of them?
Jang: Third-party packages are sometimes integrated directly into distribution repositories. Some, such as the OpenOffice.org suite, are key parts of the latest distributions. Others are available in allied repositories such as Fedora Extras. Still more are available in true third-party repositories, and should be handled with care, as mixed repositories have in the past led to the conflicts known as "dependency hell."
Why should patches be tested before being implemented? Isn't it more important to patch a vulnerability quickly?
Jang: Few patches have to be implemented quickly. Many are feature improvements. Many security fixes address unused features. Sometimes it's better to temporarily deactivate a service, rather than patching too quickly.
Could you offer some tips on updating Red Hat Enterprise Linux?
Jang: If you have an official subscription to Red Hat Enterprise, use the support.
It is excellent. Use the Red Hat Network Proxy Server or Satellite Server if your subscriptions allow it. If you're using a rebuild of Red Hat Enterprise Linux, use the community associated with that rebuild.
What's are the core differences between Red Hat, SuSE (YaST) and ZENworks update systems? Are they all server-centric? Are there advantages to either one, or is each one only appropriate when working with a particular distribution?
Jang: The Red Hat update system is designed for the Red Hat Network and Red Hat Enterprise Linux. The Fedora Core update system uses open source tools. While YaST is now open source, it is most suitable for SuSE systems. While ZENworks can be used to update a variety of distributions, (including authorized Red Hat Enterprise Linux systems) it is not open source.
Are configuration mistakes the source of many problems in patch management? If so, why?
Jang: Not really. If a mistake is made on selecting a patch management repository, then updates aren't made. Except for a delay in patch delivery, no harm is done.
Why do some people think that apt is the best tool for keeping Linux up to date? When is it appropriate to use apt...only for desktops?
Jang: I find that apt is faster, because more content is cached locally. It's fine to use apt for desktops. It's still the preferred tool for Debian-based distributions (including Ubuntu). However, RPM-based distributions seem to be moving towards yum and the Smart Package Manager.
Does an IT person have to be a Linux development expert to configure apt for RPM distributions like Fedora Linux and SuSE Linux Pro?
Jang: In my opinion, it is easier to configure apt for RPM as it is to configure most Linux services. All you need to do is organize the RPMs, process the packages into apt-friendly headers, point clients to the repositories, and you're good to go! However, Fedora Core and Red Hat Enterprise Linux can't handle apt on their 64-bit systems.
What are some key differences between patch management practices and tools for server distributions as opposed to desktop/client distributions?
Jang: Patch management techniques do not change for servers or desktops. Sure, the key packages depend on the functionality of the system, but that doesn't affect how you create a repository or update any system.
What did I miss? Are there other Linux patch management tips you'd like to offer business IT managers?
Jang: While the developers of every major Linux distribution do an excellent job testing their patches, they can't cover every configuration. Your situation may be unique. And as an IT manager, you don't want to be left "holding the bag" due to unexpected problems.
