Patching Linux - Pain or Gain?

Third Party Tools

Aside from the Linux vendor based utilities like ZenWorks and YaST, there are also third party commercial applications geared to facilitate the patching process. Some of these server based applications will download Linux packages from the vendor, store the updates in a central repository, and provide either automated or manual installation of packages to waiting Linux servers.

These applications, especially for Linux, are few in number—you can spend a considerable amount of time trying to find a straight-forward technology that isn’t just a small piece of a larger entire enterprise level package (like ZenWorks). The apps I found mostly patch the Microsoft Windows OS, while a handful of solutions will patch RedHat Linux. Support for SuSE can also be found, but other Linux distros were pretty much left out, except in a couple of products.

Patchlink Update is one solution that patches Windows and RedHat systems, but will also cover SuSE, Solaris, AIX, NetWare and OSX. Seeing that RedHat and SuSE are two of the dominant Linux distros in enterprise computing, support for these two distributions puts Patchlink in a very advantageous position over its competitors. It’s an agent based architecture that lets you choose how you want to install your patches—either by a scheduled or a manual update.



The great thing about Patchlink is that it touches a lot more operating systems than most update tools.

From a top level perspective, to have one application take care of most of your patching needs across various operating systems and supporting software is a dream come true. You get to avoid running multiple patching systems for each OS, saving time and resources that you can deploy elsewhere.



The great thing about Patchlink is that it touches a lot more operating systems than most update tools.

Optimism aside, Patchlink does have its setbacks. For one, I haven’t seen any great performance from its system discovery tool: it’s slow and takes a while to start up on a two-year old server. In fact, I’ve seen it take up to 10 -15 minutes to get going.

Patchlink, like similar applications, needs a little hand-holding when deploying updates. One thing I’ve learned is that if you are using a scheduling feature that will download, install and reboot your servers, don’t go tell your users that their servers are going to be automatically rebooted at 10 pm, for example. Patching can be slow, and delays on the network can delay the actual system restart, frustrating both the sys admin and his clients. The common practice to avoid delayed downtimes is to just patch the machines ahead of time and then reboot the server.

One other gotcha about Patchlink Update is that its base concept is very security-centric. Patchlink doesn’t take care of the occasional maintenance patches—it only covers security based updates that fix vulnerabilities when the updated software is available.

Finally, Patchlink does not release kernel updates. Seeing that the kernel is the heart of your Linux system, this can be a little bothersome. The only solution is to patch the kernel yourself.

Though not a traditional patch management system, one product line that holds some promise is BlueLane’s set of PatchPoint and Virtual Shield products. These products are appliance-based gateways that sit between your network and your unpatched servers. They protect the servers by cleaning up the network traffic going to the protected servers, and then mitigate any incoming hazardous vulnerabilities.

BlueLane's PatchPoint

BlueLane's PatchPoint

BlueLane’s PatchPoint Gateway appliances sit between your network and the server farm. The gateways are maintained by a PatchPoint manager that receives its updates from BlueLane.

The PatchPoint gateway is a network appliance that works in your physical server farm. The other product, Virtual Shield, is a virtual machine that works with VMWare’s Virtual Infrastructure and sits within an ESX Server. Both PatchPoint and Virtual Shield are maintained by a management application running on a separate server. Aside from protecting Windows, RedHat and Novell SuSE machines, BlueLane also takes care of FreeBSD and Solaris, as well as IIS, Apache and iPlanet web application servers.

For virtual machine environments using VMWare’s ESX Server products, you can use the BlueLane Virtual Shield product. Depending on the complexity of your environment, setup can range from being pretty simple to pretty complex. Instead of using physical hardware, you use a Linux-based virtual appliance to protect your virtual machines. Updates are periodically retrieved via a BlueLane subscription channel, keeping your machines safe, especially if patching servers represents a scheduling problem. The only real drawback I can see from using BlueLane is the risk of disregarding the actual patching of the protected OSes, when you know that BlueLane’s appliances will be there for you.

BlueLane Virtual Shield

BlueLane Virtual Shield

If you have a virtual server farm, BlueLane Virtual Shield, like it’s physical counterpart can help mitigate vulnerabilities, too.

As I mentioned before, there are other products, like Update Manager, PatchEasy, PatchQuest and Prism Patch Manager, which provide patch management for Linux. These products, however, are limited to covering only RedHat, with little or no mention of other distros in their documentation. Still, it’s good news if you use a lot of RedHat in your datacenter. With RedHat’s current position as a leader in mass-market Linux, it’s easy to see why there’s so much more support for it over Turbolinux, Debian and Ubuntu. In the future, though, I would expect to see more support for SuSE Linux because of its acquisition by Novell in the American market. Time will tell.

  • Darkk
    Very nice article. Patching is just a way of life of sys admins everywhere regardless of what flavor of server and desktop OS. Least the article explains in detail what to expect and the gotchas.

    Good job!

  • Patching harder on Linux than Windows?!?
    Maybe I'm biased, but updating Debian or ArchLinux (more of a desktop distro) has been so easy as not to even think about it.
  • You really don't know what you're talking about here..and readers should avoid this article.

    If you buy Red Hat Enterprise Linux with a Satellite subscription Red Hat does the patching.

    If you have Novell - ZenWorks will do the trick.

    If you're running a non-commercial unsupported version than sure some of the options you mention might make sense but a simple cron job with yum/apt will do it all with one command line.

  • Was this article written by Steve Ballmer? And interestingly there is only a single line about the Debian-based distros? Why Mr. Anderson, why didn't you mention the details about APT? Now Steve Ballmer, let me tell you something - my close friend is a sysadmin of my university (University Of Toronto) and he doesnt even bother patching the systems because they are fully automated (over 200 machines). As well he deploys 50 machines with brand new OS installation with no more than 5 lines of commands.

    Sad Tom's.. sad.. you have been an amazing site once upon a time ...
  • hmmm.
    I'm a Windows guy most of the time but I enjoy playing with Linux from time to time.
    Actually as a Linux starter(some time ago) I had no problem patching my Linux.
    It was very easy...
    I do not remember reading or doing something special before patching it at that first time.
  • Correction, Patch Quest by Advent Net was cited as patching only RedHat which is incorrect. It also patches Debian. In my experience finding a patch solution for your particular OS has not be that terribly difficult. Finding one that has robust scheduling, push on demand, and can handle the multitude of necessary evil apps, such as Adobe Reader, Quicktime, Realplayer, Instant Messaging, etc... is the real challenge.
  • GoK
    The author of this article needs to go back through their information, and edit this article. It is highly inaccurate! The fact that he gave Debian-based GNU/Linux flavors (ie., Ubuntu&Gentoo) less time in the article than his praise for Mircosofts upstream ability for patches, seems a bad sign for this article.

    Patching most GNU/Linux installs is a simple task, which is highly scalable, and that can be fully automated through the use of CRON scheduling, etc. NO EXTRA SOFTWARE should be required to update/maintain ANY enterprise level GNU/Linux server distro (also if you server has a GUI on it, its not running in an enterprise level configuration).

    I find the mention of Windows Server strange in the article, since it can't run services like Bind9 (DNS), it only makes up roughly 38% of the current market share of net servers, and since it can't run Bind9, it runs NONE of the internet backbone (DNS routing server).

    I am a huge fan of Tom's, but this article should never have been published.
  • nochternus
    While there are many Linux solutions, everybody will find what works best for them. I myself have become a fan of distributions like ArchLinux. I use it on my 3 servers at work and on my desktop and server at home. the package manager, pacman, is by far the best I've ever used. While it may not categorize some things into software groups, it does have it broken down into core, extra and then everything else. It is also extremely easy to configure and create wrappers or optional interfaces that utilize pacman (just like some of the others mentioned. There is also a package called the "arch build system" that allows you to create your own packages from source with the simple modifications of a PKGBUILD file, making recompiling and rebuilding easy and efficient. My latest server was not fully supported by a vanilla or even a patched kernel so a few quick modifications to the PKGBUILD and the kernel config and one command later, the package was compiled from source and installed without me sweating, swearing or crying.

    I don't want this to come off as a "YAY ARCH - EVERYBODY SWITCH" comment so much as a "do a little more research, or even a community probe could get you better information" comment. The concept of the article wasn't bad just slightly "mis-informative". Especially seeing as how not everything that is open-source and is an OS is linux/unix. Most are linux-like or unix-like (as is the nature of progression.

    As a note for the naysayers, I've used Windows Server, Debian, Gentoo, RedHat, SuSE, ubuntu, FreeBSD, OpenBSD, Solaris and many spin offs of some of those. All of them have their strengths and weaknesses (most notably the flaw of the Windows Server platform would be any machine that loads it - THAT is a biased opinion.)
  • malici0usc0de
    With Ubuntu you can also set it up to silently install them in the background, it just prompts for a password then goes away. I don't know how long Ubuntu has had this but I have been using it as my only OS at home for about 2 years now and have never had a problem with patches. I use XP at work as almost everyone does and I notice it operates almost exactly the same way except it doesn't ask you for a password. So if it works for the less techie MS user base then I don't see why so many problems are occurring with this same basic system running under Linux. sudo apt-get install brain
  • resistance
    The writer of this article has 0% knowledge of _present-day_ GNU/Linux or this article was sponsored by software monopolist.

    in Debian based distros like *ubuntu you can set automatically daily updates without _any_ user intervension and without installing additional software.

    Its a first time I see such badly written article on tomsharware.