APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Linux Patch Management

  • Michael Jang
  • Pearson Education
  • 0132366754

Amazon logo Order (or just read more about) Linux Patch Management  from Amazon.com


Index by Subject

More Books

When I first looked at this book, my reaction was more than a little unfavorable. Another rehash of man pages? Why would you need a book about "up2date" and "yum" etc.? Can't you read the man pages?

Well, yes, of course you could. If all you have is one Linux box, and you have read the applicable man pages for updating your system, you probably don't need this book. If you have multiple systems, , perhaps even multiple distros, and would like advice on managing all that, then this would have value for you.

Actually, even if you do have one system, you might still find this useful. I know I've had patch related problems now and then and haven't wanted to struggle through confusing man pages. "Linux Patch Management" is a good overview of what you need to do and why you need to do it, and it does cover RedHat, Fedora, Debian, and SUSE.

I'm apt to run into all sorts of systems in all stages of disrepair - having a "all in one place" reference could be quite handy. While I probably won't need to refer to this very often, when I do I'm sure I'll be glad to have it.

On the other hand, many Linux users avoid updates after the initial install. For my own machines in my own office, I vary wildly. Often I ignore patches and updates unless it's some very serious security issue that I can't ignore. I do this because I don't want to break my systems and often I just don't have time to stage and test things.. but on the other hand sometimes I get religious and keep on top of a box weekly. That stops dead the minute I have some problem; that's unfortunately not unusual with Linux patches - the area of patches that ruin your day isn't ignored in this book, but of course there's not a lot to say: stage on test machines or virtual machines's or take your chances.

For customer systems, it's even harder. If a customer has ignored updates, the last thing I want to do is bring down a critical system by installing patches that end up breaking the whole thing. On the other hand, they may be ancient and in real danger from security problems. Often I'd rather do a new install on a separate box to avoid any danger, but of course that takes resources that may not be available..

I'm looking forward to the day wnen virtual machines are the norm rather then the exception. Clone off a quick copy of the existing system, patch it in a vm, and see if it's OK. If it is, switch to that session and call it a day. If not.. regroup and fight another day.

So.. I remain a little unsure of this book's value to me, but I'll keep it around as insurance.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Linux Patch Management (Book Review)




Increase ad revenue 50-250% with Ezoic


More Articles by

Find me on Google+

© Anthony Lawrence



Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





The successful construction of all machinery depends on the perfection of the tools employed; and whoever is a master in the arts of tool-making possesses the key to the construction of all machines... The contrivance and construction of tools must therefore ever stand at the head of the industrial arts. (Charles Babbage)

One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. (Robert Firth)












This post tagged: