For many of us, Linux has been a welcome presence in data centers large and small. What do you do, though, when you start getting into more than you think you can handle ?
With the advent of ever-evolving technologies like SANs, virtualization and server consolidation, data centers are glowing with even more shimmering lights, and humming from the buzz of smaller form factor stand-alone servers, farms of virtual machine servers and rows of blade centers. The ease of using server templates, cloning and automated installations have definitely had a great impact on the number of servers you end up managing today. What may have been a 10:1 server to technician ratio several years ago has now changed, and enterprise sized server farms of several hundred machines are managed by just a handful of people. Simply put…if you can build it faster, better and cheaper, someone will take notice and expect more.
Along with the growing data center, you also have the rise of Linux as an enterprise level operating system. As more tech houses use this constantly maturing operating system, they run into issues like support, hardware compatibility and finding ways to get more bang for their buck using open source components in their existing infrastructures. Now, aside from finding better ways to manage your hardware, using tools, monitoring processes and other fun IT stuff, one of the biggest headaches IT has to face is keeping your machines up to date. Yes…we’re talking about patching.
When it comes to patching, Microsoft has the edge by far. Regardless of the number of patches Microsoft puts out every year, being the popular operating system that it is, it gets pretty good support from the industry when it comes to facilitating patch management. Aside from using Microsoft Update to patch your machines, there are plenty of third-party tools that support the Windows operating system. For Linux, on the other hand, you’ll only find a few third party tools. You can use the built-in update processes that the OS has to offer, but it can quite clumsy, especially if scheduling is required, or if there are package dependencies to consider. The few third party tools available can be rather limiting as well, since the majority only work with RedHat. You also need to deal with a vast number of machines in your server farm. How can you manage large scale patch deployments across thirty, sixty or even several hundred servers ?
In this article, I try to cover some of the basics of patching Linux using built-in mechanisms, what’s available in the third-party tool market and, some of the obstacles I’ve run into when trying to manage a small to large data center full of Linux servers.
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.
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.
Sad Tom's.. sad.. you have been an amazing site once upon a time ...
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.
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.
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.)
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.