Linux Patch Management

Ravi writes "Any system or network administrator will know the importance of applying patches to the various softwares running on their servers be it the numerous bug fixes or vulnerability checks. Now when you are maintaining just a single machine, this is really a simple affair of downloading the patches and applying them on your machine. But what happens when you are managing multiple servers and hundreds of client machines? How do you keep all these machines under your control up to date with the latest bug fixes? Obviously, it is a waste of time and bandwidth to individually download all the patches and security fixes for each machine. This is where this book named "Linux Patch Management - Keeping Linux systems up to date" authored by Michael Jang gains significance. This book released under the Bruce Perens' open source series aims to address the topic of patch management in detail." Read the rest of Ravi's review Linux Patch Management - Keeping Linux Systems Up To Date author Michael Jang pages 270 publisher Prentice Hall rating 8 reviewer Ravi ISBN 0-13-236675-4 summary This book offers Linux professionals start-to-finish solutions, and examples for every environment, from single computers to enterprise-class networks.

The book is divided into seven detailed chapters, each covering a specific topic related to patch management. In the first chapter, the author starts the narration by giving an introduction to the basic patch concepts, the various distribution specific tools available for the user including Red Hat up2date agent, SUSE YaST online update, Debian apt-get and also community based sources like those in Fedora. What I found interesting was instead of just listing the various avenues that the user has regarding patching his system, the author goes the extra mile to stress the need for maintaining a local patch management server and also the need to support multiple repositories on it.

The second chapter deals exclusively with patch management on Red Hat and Fedora based Linux machines. Here the author walks the readers through creating a local Fedora repository. Maintaining a repository locally is not about just downloading all the packages to a directory on your local machine and hosting that directory on the network. You have to deal with a lot of issues here, like the hardware requirements, the kind of partition arrangement to make, what space to allocate to each partition, whether you need a proxy server and more. In this chapter, the author throws light on all these aspects in the process of creating the repositories. I really liked the section where the author describes in detail the steps needed to configure a Red Hat network proxy server.

The third chapter of this book namely SUSE's Update Systems and rsync mirrors describes in detail how one can manage patches with YaST. What is up2date for Red Hat is YaST for SuSE. And around 34 pages have been exclusively allocated for explaining each and every aspect of updating SuSE Linux using various methods like YaST Online Update and using rsync to configure a YaST patch management mirror for your LAN. But the highlight of this chapter is the explanation of Novell's unique way of managing the life cycle of Linux systems which goes by the name ZENworks Linux Management (ZLM). Even though the author does not go into the details of ZLM, he gives a fair idea about this new topic including accomplishing such basic tasks as installing the ZLM server, configuring the web interface, adding clients ... so on and so forth.

Ask any Debian user what he feels is the most important and useful feature of this OS, then in 90 percent of the cases, you will get the answer that it is Debian's contribution to a superior package management. The fourth chapter takes an in depth look into the working of apt. Usually a Debian user is exposed to just a few of the apt tools. In this chapter though, the author explains all the tools bundled with apt which makes this chapter a ready reference for any person managing Debian based system(s).

If the fourth chapter concentrated on apt for Debian systems, the next chapter explores how the same apt package management utility could be used to maintain Red Hat based Linux distributions.

One of the biggest complaints of users of Red Hat based Linux distributions a few years back was a lack of a robust package management tool in the same league as apt. To address this need, a group of developers created an alternative called YUM. The last two chapters of this book explores how one can use YUM to keep the system upto date as well as hosting ones own YUM repository on the LAN.

Each chapter of the book explores a particular tool to achieve patch management in Linux and the author gives in depth explanation of the usage of the tool. All Linux users irrespective of which Linux distribution they use will find this book very useful to host their own local repositories because the author covers all distribution specific tools in this book. The book is peppered with lots of examples and walk throughs which makes this book an all in one reference on the subject of Linux patch management."

Michael Jang has specialized in networks and operating systems. He has written books on four Linux certifications and one of them on RHCE is very popular among students attempting to get Red Hat certified. He also holds a number of certifications such as RHCE, SAIR Linux Certified Professional, CompTIA Linux+ Professional and MCP.

You can purchase Linux Patch Management - Keeping Linux Systems Up To Date from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Update: 02/07 14:52 GMT by J : Book rating changed from an intended 4 (of 5) stars to Slashdot-normalized 8 (of 10), by Ravi's request.

Comments

4 stars?

[Anonymous Coward]

4 stars? Don't book reviews get rated 1 to 10? And 4 stars? Is that out of 4 or 5? Or maybe 3? Some ratings only go up to 3 stars. I mean is the book pretty good (4 out of 5), excellent (4 out of 4), or so amazinly kick ass that everyone needs to read it (4 out of 3.) I'm confused as to the quality of this book.

Patches using RPM

[IMightB]

What I want to know is how to issue patches via RPM rather than distributing the whole app again. Wether using some sort of binary diff, or just packaging the changed files. And how to manage things like this with the RPM database. I know that SuSE has got "patch" rpm's but I can't find any info as to how these are created, or how they are viewed/managed by the rpm DB.

Anyone?

Re:Patches using RPM

[lixee]

My Ubuntu tells me when a new update is available; Patches are then one click away.

Re:Patches using RPM

[mslinux]

At last... the blackmagic and ignorance that abounds in Windows has found its way into Linux :)

Just click here and you'll be OK... trust us :(

Re:Patches using RPM

[Anonymous Coward]

RPM allows scripts to run, so you could patch a file by creating an appropriate diff then adding it to the RPM script section.

Re:Patches using RPM

[MBGMorden]

While nice, that doesn't seem to be what the original poster was getting at. He was wanting a package manager that is able to distribute only what has changed in the binary, rather than downloading the whole new file. Essentially, the question was about size/bandwidth concerns, not ease of use.

Re:Patches using RPM

[jacksonj04]

And yet people like you complain about those who don't keep their PC patched?

You have two choices:

Make things easy for some who can't remember some cryptic command to download source, compile, install, patch, re-patch, re-re-patch, change the config, find it was the wrong config, hunt for the config, change the config, find they have to re-compile, re-compile, re-install, re-re-re-patch and finally use.

Stop whining.

Re:Patches using RPM

[Subrafta]

I've used RPM to patch and update / change configurations on a number of in-house applications. We've got several hundred Red Hat systems of various vintages installed on customer networks. Basically I make the "patch" RPM dependant on the original RPM, then use the %pre and %post areas of the spec file to ID the target system, update configurations, start / stop services, and move updated files into place. It's not a perfect system and I only use it to do automated, broad-based configuration changes, not to scrimp on bandwidth. You have to track just about everything yourself and deal with regression testing. An RPM to update named.conf, originally installed by the bind-9.3.1-14_FC4 RPM, might be named MyUpdate-bind-1.0-0. AutoRPM (some of these systems pre-date up2date, yum, etc. and I don't want two software management systems) handles noticing that new or updated RPMs are available.

Re:Patches using RPM

[Peter H.S.]

What I want to know is how to issue patches via RPM rather than distributing the whole app again.

I will try to answer why this probably won't happen for at foreseeable future, and why it probably not is a good idea.

The only advantage that a binary patch system have over distributing the whole rpm package is that it saves bandwith.
A major disadvantage of such a system is that it creates twice the overhead, since most of the work that a Linux distributer have with patching its software, is the (regression) testing. So now the Linux distributer has to track _and_ test two kinds of updates; binary diff packages, and whole packages. They can't skimp testing one of the two types, since that would almost certainly mean, that a trivial error borks the untested package, that then would hose thousends of machines. And if the distro skimps distributing the whole packages, well, then types like me would start to whine about how much is sucks to keep track of "package" +"hotfix_1" +"hotfix_2" +"hotfix_3" instead of just getting "updatedpackage".
The package management systems would also have to be reworked, since they now have to keep detailed track of packages and updates, and the exact order of which to apply these updates. (when I was working with MS Windows servers years ago it was not uncommon that Windosupdate would loose track of updates and installed software, so that old software would overwrite new security patches)

In short, a binary diff patch system would mean a lot of work, for a negliable gain

Way back when I started with Linux, I also thought that it was a good idea just to distribute binary diff updates, since that was what I was used to, and because it somehow seems wastefull distribute a whole package.
I changed my mind when I actually started to manage some Linux servers.

--
Regards
Peter H.S.

Re:Patches using RPM

[IMightB]

I can see your point, however, my situation doesn't involve general distribution to the public. It's more like releasing to our Operations Department, who doesn't want to install a 80+ MB rpm for a PHP script patch. In this situation they actually want RPM + Hotfix 1 + Hotfix 2.... Or Patchrollup.rpm

Right now historically, these have been provided in a tar.gz file that installed OVER the rpm files. Which makes it almost impossible to go through and see what patch level something is at.

With RPM I can do things like this patch depends on this previous patch, etc etc... For our needs this is a much more convienient solution.

I agree with you that for the vast majority of applications, this doesn't make sense.

Re:Patches using RPM

[Guido von Guido]

Have you looked at the --justdb flag? It makes changes to the RPM database without installing files. You could script your upgrades so that the updated files are installed with tar and then the rpm database is updated with rpm --justdb. I've done something similar with an internal package which was initially released as a tarball so it was easier to keep track of.

The downside to this is that it's prone to errors (e.g., you make a mistake and the rpm database could think that package owns files that don't exist), so you'd want to make sure to test it.

Re:Patches using RPM

[Anonymous Coward]

cryptic commands...

glsa-check -f all

Damn that's hard to remember. Even harder if you drop it in a crontab(hourly/daily/whatever).

Next...

Re:Patches using RPM

[Anonymous Coward]

Surely testing the binary packages consists solely of ensuring that oldrpm+patch is identical to newrpm? This is a bash script with diff, and can be automated away.

Handling the binary updates in the right order is a job for apt/whatever. Write it once and you're done, end users will barely notice. I agree it's a pain for the apt guys.

Negligible gain? Try keeping a system up to date on a modem, that'll change your mind right back.
I suspect the bandwidth savings at the package repositories would be pretty useful for those guys too.

Re:Patches using RPM

[mslinux]

I meant that as a joke. I like quick and easy too :)

Re:Patches using RPM

[buchanmilne]

Mandriva also uses the patch, and provides the tools to generate the delta rpms (in the "deltarpm" package), so here are some extracts from the man page:

NAME
              makedeltarpm - create a deltarpm from two rpms

SYNOPSIS
              makedeltarpm [-v] [-V version] [-z compression] [-s seqfile] [-r] [-u]
              oldrpm newrpm deltarpm
              makedeltarpm [-v] [-V version] [-z compression] [-s seqfile] [-u] -p
              oldrpmprint oldpatchrpm oldrpm newrpm deltarpm

DESCRIPTION
              makedeltarpm creates a deltarpm from two rpms. The deltarpm can later
              be used to recreate the new rpm from either filesystem data or the old
              rpm. Use the -v option to make makedeltarpm more verbose about its work
              (use it twice to make it even more verbose).

              If you want to create a smaller and faster to combine "rpm-only"
              deltarpm which does not work with filesystem data, specify the -r
              option.
[...]

urpmi is supposed to support the deltas, and they were being tested on cooker at some stage, but it doesn't seem that deltas are being used for the current update media.

ZENworks Linux Management

[ezs]

This is a nice review of 'patching Linux' - and it's a subject close to my heart. Usual disclaimer - ZLM is partly my product and baby. One thing that the review clearly describes - there's a lot of choice out there. From Red Hat Network; to Novell update; to YaST Online Update - and there there is yum, apt etc etc etc. One of the cool things that ZENworks Linux Management brings to the table is the ability to integrate multiple sources of patches - RHN, YOU, Novell, roll-your-own, apt - and bring them into a central release server and control what goes where. For those that are too small or don't want to shell out for ZENworks - remember there is also the fully open source Open Carpet product - http://opencarpet.org/

Re:ZENworks Linux Management

[Anonymous Coward]

ZLM is partly my product and baby

Well I hope you are ashamed - Novell purchased a great product in Redcarpet and have completely ruined it - that you can no longer download patches for RHEL, the fact that you can only install the patch server on SLES, the fact that you've tacked all sorts of shitty novellisms around it. We were very happy RedCarpet customers, we invited Novell in to demo ZLM with the expectation that we'd be very happy ZLM users and were so disappointed that we've not renewed and are looking at other products.

Regards

Alex

Re:ZENworks Linux Management

[G Money]

We actually use ZLM at my workplace and maintain and patch numerous RHEL systems. While ZLM7 does require SLES, it would probably be pretty difficult for them to support installing it on anything else as there is so much involved with the product (eDirectory, Extend, etc...). It's really only one server you're talking about anyway and a single SLES license doesn't cost much at all. The new version also offers so many more features such as imaging, policy distribution, arbitrary remote execution, replication, and more that it doesn't even compare to the old version. I'm not sure why you couldn't get the agent to work under RHEL but if you need any help feel free to send a message.

Re:ZENworks Linux Management

[ezs]

Alex There are several inaccuracies in your post. 1 - yes you can still patch Red Hat. You need to keep legal with Red Hat Licensing - which means you mirror content from Red Hat Network and then deliver that out to your machines. 2 - the current version of ZLM does only run on SLES 9; however ZLM 6.x runs on RHEL and SLES; in the future you may see Novell re-add support for RHEL as a hosting server. 3 - Shitty Novellisms.. such as? 4 - if you've not had a good experience with moving from Red Carpet to ZLM ping me offline and I'll see what we can set up.

Re:ZENworks Linux Management

[Alex]

1 - yes you can still patch Red Hat. You need to keep legal with Red Hat Licensing - which means you mirror content from Red Hat Network and then deliver that out to your machines.

Ximan used to provide this for you.

2 - the current version of ZLM does only run on SLES 9; however ZLM 6.x runs on RHEL and SLES; in the future you may see Novell re-add support for RHEL as a hosting server.

ZLM 7 is required if you run RHEL4 clients.

3 - Shitty Novellisms.. such as?

All of the stuff I'm sure you'd describe as "value add" - summarised in a post above as "eDirectory, Extend, etc...". Our primary objection is that Novell have taken a really great simple product and made it massively more complex. We aren't interested in NDS / all of the Novell stuff that you try to sell us - we are an AD / OpenLDAP shop - I think once it became clear that there wasn't an opportunity for any upsell the sales staff lost all interest.

4 - if you've not had a good experience with moving from Red Carpet to ZLM ping me offline and I'll see what we can set up.

Thanks for the offer - but we've made our minds up on this (you are by far the most useful person from Novell we've spoken to - to describe your UK sales staff as utterly useless doesn't really do them justice).

Alex

Patch Management

[Da Stylin' Rastan]

At least in the RPM world, one would be neglect to not mention red-carpet and smart, IMHO the two best package managers out there. Although red-carpet has morphed into Novell's ZLM package, it is still the best system for enterprise Linux patch management, even if you use RedHat or some other non-Novell distribution. Smart is still in beta, but it is currently quite stable and functional even in its development state. Smart is definitely the next gen package manager, taking all the great features of apt-get, red carpet (short of the server daemon), and others. It's dynamic mirror management and repository agnositicism (you can use Fedora, Yum, apt-rpm, YaST, red-carpet repositories, and even mix and match as necessary, provided they are all for the same distribution) make it extremely compelling. I highly recommend you check it out. http://labix.org/smart

Re:Patch Management

[thx1138_az]

Clipped from the Smart homepage...

The Smart Package Manager project has the ambitious objective of creating smart and portable algorithms for solving adequately the problem of managing software upgrading and installation. This tool works in all major distributions, and will bring notable advantages over native tools currently in use (APT, APT-RPM, YUM, URPMI, etc).

Does this sound eerily similar to an academic publication to you? Regardless, it does seem to be something aspiring to be useful in the enterprise setting.

Re:Patch Management

[Da Stylin' Rastan]

LOL, I certainly agree with your claim on their mission statement. However, they have the product to back it up. The features I was talking about aren't *promised* features. They are there NOW. I use Smart on all my OpenSuSE and Fedora Core desktops in replacement of Yum and YaST, and it works fabulously. -DSR

yawn: in linux, it's called a package, not a patch

[totro2]

Old school commercial Unices like Solaris, HPUX, and AIX have "patches". Modern linux systems have "packages". Anyone who doesn't deal with a modern, automagical package management system like apt or yum is usually slogging through the mud unnecessarily. By updating a package, you get your patches. Most Linux users should never have to patch source code from tarballs, like the kernel or other software. This book may be useful for those few exceptions, however.

Red Hat Enterprise - chkconfig --level 35 rhnsd on

[seifried]

This only leaves running the updater manually to install updated kernels (by default it doesn't upgrade the kernel automatically, you can of course change this) and the occasional reboot once you update a kernel (network services are restarted as needed). You just set it and forget it like the Ronco showtime rottisiere (sp?) BBQ.

I wrote a book on Linux Patch Management

[wawannem]

Chapter 1:
apt-get update ; apt-get upgrade

Re:I wrote a book on Linux Patch Management

[Dogers]

For one machine, yeah, no problem.

For 10 machines? 50? 100? 500? No thanks.

Re:I wrote a book on Linux Patch Management

[El_Muerte_TDS]

apt-cron

although that only works when the patch doesn't need human attention

Re:I wrote a book on Linux Patch Management

[thx1138_az]

Then you'd have to trust that the distro doesn't self destruct by patches breaking your vital (read mission critical here) services.

Re:I wrote a book on Linux Patch Management

[sholden]

Obviously you do testing on the test machines and only push the updates to your apt repository after they have been tested, at which point the production machines auto update with them.

You don't point the production machines at the distro's repository, but non-retardation is an assumed and hence these bits aren't usually made explicit.

Re:I wrote a book on Linux Patch Management

[thx1138_az]

Say I have 50 production Linux servers (go on... say it) running various vital services and I have the budget for the required multiple duplicate "test" servers (and the trained staff) and the time to test every patch that is released deemed necessary by our security team. Lets say that one slips by the "exhaustive" tests. I'd still want a better solution than plain ole apt to undo the patches across the enterprise quickly despite my vast and obvious retardation.

Re:I wrote a book on Linux Patch Management

[RazzleDazzle]

chapter 2:
emerge sync; emerge -uD world

Re:I wrote a book on Linux Patch Management

[sholden]

for i in list-of-machines
do
ssh $i command-to-roll-back-a-patch
done

Re:I wrote a book on Linux Patch Management

[tlianza]

If that's chapter 2, I know as a diehard Gentoo user that Chapter 3 is: Pray.

Re:I wrote a book on Linux Patch Management

[Anonymous Coward]

Why is it that every time I see someone in the linux world try to do multiple things on one line it's as if they only halfway skimmed the man pages?

What I mean is this:

If you do "foo ; bar", and foo fails, but bar relies on foo.. Do you really want bar to run? You sure? It won't attempt to install any half-downloaded packages, or clobber system things because foo only half setup things before it borked out, and now bar just goes wild and tosses everything in?

A really good example is this: "make ; make vmlinuz ; make modules ; make install"

So, what if the first two succeed, the modules building fails, but then it goes off and 'installs' everything it's got? What if your exceedingly important network card driver module didn't get compiled, so didn't get installed, and so upon next reboot, you're SOL and have to physically get to it and fix it?

How 'bout people start doing this:

"foo && bar"

Then, if foo fails, bar doesn't run. Doesn't try to run bar. Can even do this: "foo ; bar && fubar". Maybe foo does something, like fetches the new f'honkytonks. And maybe bar attempts to extract them and verify the contents. And if it fails, you really don't want fubar to attempt to install stuff.

I really wish people would make an effort to think about what they're feeding the command line. It also makes it much easier to figure out what went wrong, and it doesn't automatically run the next command, which could push the error message way past the terminal buffer.

Re:I wrote a book on Linux Patch Management

[Anonymous Coward]

Now are you patching bugs, or are you upgrading your systems?

For patching flaws: glsa-check -l
                                    glsa-check -f #

For updating systems: emerge sync && emerge -uDv world && dispatch-conf

Re:I wrote a book on Linux Patch Management

[RazzleDazzle]

Bummer. I do that regularly without issue except I usually add some more switches like "emerge -vtDua world" but that is not good for automating because it prompts you to start the update but also gives you a chance to see what is going to be updated first.

If you have a really old install and have not done a 'emerge -Du world' then I could see you running into problems. I had problems because I had installed Gentoo about 4 or 5 years ago and was not using the "-D" option for a while which updates libraries and dependencies of the installed programs and the first time I did that I had tons of problems. Now I am comfortable and familiar and have no issues and it is still the same installation from 4 or 5 years ago.

Re:I wrote a book on Linux Patch Management

[wawannem]

You make a valid point, but at the same time, here is how I look at it... You have to pick one of the following:

1. Use APT (or insert any other similar tool [YUM, Portage, etc.]) which is heavily tested by thousands or even millions of developers and allows you to make all packages uniform as far as installation and packaging whether it is a homebrew package or a distro package.

or

2. Homebrew package management. Don't get me wrong, I'm not saying that this isn't a viable option, there are advantages to it. For instance, if you write it, you can make sure it meets all of your site's specific needs. But, you will hit a point where you aren't packaging the core OS components, and each system is actually running two package management systems - 1 the distro package management and 2 your homebrew. This is problematic because any rules in one system aren't honored by rules in the other system. A homebrew system can be architected and things will run smooth, but IMO, 99% of SysAdmins will spend months recreating APT.

Just my .02, you're entitled to your own as well.

Dumb question

[Otter]

Maintaining a repository locally is not about just downloading all the packages to a directory on your local machine and hosting that directory on the network. You have to deal with a lot of issues here, like the hardware requirements, the kind of partition arrangement to make, what space to allocate to each partition, whether you need a proxy server and more.

Umm, why? Does a package repository need to be more super-optimized than any other network resource?

details details

[Clover_Kicker]

> If the fourth chapter concentrated on apt for Debian systems

Maybe you should re-read the book and pay more attention this time?

Re:details details

[greg1104]

> Maybe you should re-read the book and pay more attention this time?

"re-read" implies that the book was read once already; from its depth, I assumed this review was based on a hard look at the table of contents.

How about a useful link?

[Dogers]

Such as to the actual open source series?
http://www.phptr.com/promotions/promotion.asp?prom o=1484&redir=1&rl=1

This book will be there as a PDF in a few months, or you can buy it in dead tree format now.

Other books are also linked there.

Book summary

[MirrororriM]

1. Set up your own package server on the LAN - this means the package server will download from the internet. So you basically have ONE machine downloading from the net - the rest of the machines are done internally.

2. Next, set up your sources.list file to point only to that server.

3. 17 8 * * * root apt-get update; apt-get upgrade

4. ???

5. Profit!!!

Re:Book summary

[un1xl0ser]

Right, because everyone wants every patch on every system that they have as soon as it comes out. I guess that you don't look after a lot of systems, or a lot of important systems. This does not cut it an an enterprise environment.

You need to QA your packages that you push out to all systems. You need to make sure that the patches you install keep the system as stable as it was before. A sysadmin where I work once imaged two systems about two weeks apart. He patched one system (without testing) and it took 2 weeks of time to troubleshoot the problem. Finally, when we determined the problem, we decided to downgrade the system to the stable one's rev in most of the packages.

Patching systems willy-nilly with no QA is a great way to have patched and potentiall unstable systems.

Re:Book summary

[MirrororriM]

No, apt-get update and apt-get upgrade, without using an internal repository and grabbing from a public system, would force untested patches. With an internal machine as a repository, you test the patches on a test machine before you put them on your internal production machine repository. The scheduled cron was for the internal machines to grab from the internal repository - since it would be the only resource in sources.list.

Common sense applies...then again, this is Slashdot.

Re:yawn: in linux, it's called a package, not a pa

[Anonymous Coward]

By updating a package, you get your patches. Most Linux users should never have to patch source code from tarballs, like the kernel or other software. This book may be useful for those few exceptions, however.

While you're downloading your 50 meg package *I'll* be smugly compiling the 300 megs worth of source code to to patch the 3 changed lines of code.

I'd patch your book on Linux Patch Management

[marcello_dl]

I am taking you too seriously maybe ;)
Anyway, first of all i'd use aptitude instead of apt-get. It has similar command line options (aptitude update, aptitude [dist-]upgrade), it has nice ways to resolve dependency problems, and it keeps a log of the upgrades (more precisely of the upgrade requests, IIRC).

Then, having each box doing an update on its own is an unnecessary waste of band. There is stuff like apt-proxy.
Another trick is to copy the .deb packages (ONLY the .deb packages) from the /var/cache/apt/archive of an updated machine to the one to be updated. Apt recognizes it already have a local copy of the packages and refrains from obtaining it again from the network. Handy when installing a slightly old debian version on a new partition.

Re:I'd patch your book on Linux Patch Management

[drinkypoo]

Another trick is to copy the .deb packages (ONLY the .deb packages) from the /var/cache/apt/archive of an updated machine to the one to be updated. Apt recognizes it already have a local copy of the packages and refrains from obtaining it again from the network. Handy when installing a slightly old debian version on a new partition.

Can you also just put them in a nfs share and mount that on your remote hosts? It works for gentoo... But I try to avoid debian because every time I mess with it, I get pissed off at something. Usually it's apt :)

Re:I'd patch your book on Linux Patch Management

[wawannem]

Really, you are taking me too seriously.

My post was simply meant to make light of someone's attempt to write a book on a topic that seems trivial to me. Although my original comment was quite simple in nature, I was meaning to point to a versatile set of tools. IIRC, debian and the APT tools were developed because of Ian Murdoch's need to keep the Pixar render cluster up to date. Any 'debian in the datacenter' SysAdmin can tell you that the entire suite of APT tools is very handy. RedHat's recent attempt with RHN is nice as well, but from an evolution standpoint is still a bit behind APT, and Gentoo's Portage is nice as well, but, APT still has a bit of a head start on many of these tools.

One thing you do not mention is simply setting up your own repository. Depending on the size of your installation, this could be quite beneficial. I worked one job that required a 25ish-node datacenter with consistent installations of Linux. We set up our own repository using the packages we needed, and then left it up to the QE dep't to test new packages as they were released and they gave us the word when packages were ready to be pushed to our repository. Worked out quite nice and only required that we have a custom sources.list file. It was quite easy to maintain a uniform installation of Apache, and when I left, revisions of our application were being pushed with our APT repository.

Re:I'd patch your book on Linux Patch Management

[Saxophonist]

Then, having each box doing an update on its own is an unnecessary waste of band. There is stuff like apt-proxy.

I find that apt-cacher is much simpler and nicer. It doesn't support every possible method of fetching packages like apt-proxy purports to, but how many do you really need? HTTP seems plenty good enough.

Another trick is to copy the .deb packages (ONLY the .deb packages) from the /var/cache/apt/archive of an updated machine to the one to be updated. Apt recognizes it already have a local copy of the packages and refrains from obtaining it again from the network. Handy when installing a slightly old debian version on a new partition.

Or, you could use the tool that comes with apt-cacher to import them into the apt-cacher archive, then just distribute them over the network quite simply using normal apt-cacher methods. This is what actually drove me to abandon apt-proxy in favor of apt-cacher; the apt-cacher import actually works. I could not get apt-proxy's import to work correctly, and I was unable to find useful help online at the time. I did modify the source of the import code to allow import of .udeb's also because I was doing an entire system install of sarge on another machine from my laptop, but other than that, it worked perfectly.

Re:I'd patch your book on Linux Patch Management

[Stickney]

As a Fedora user I am consistently wondering why no one mentions yum (YellowDog Update Manager) when they talk about apt-get, rhn, etc. yum is a command-line package management tool that can be configured to use multiple internet repositories, and individual repositories are easy enough to build, at least for small (I don't have any experience with more than about 6 computers) networks. A GUI client, yumex, is available as well. Is there some reason no one mentions this?

Re:I'd patch your book on Linux Patch Management

[marcello_dl]

Can you also just put them in a nfs share and mount that on your remote hosts?

There might be problems when two machines mess with the "partial" subdirectory, which containes unfinished downloads. Of course that can be solved (remounting something over partial is the first thing that comes to mind) but then i'd choose some apt tools instead.

Re:Save $6.30 by buying the book here!

[Anonymous Coward]

Haha the guy's right though. Just saved me six bucks. +1 insightful if i had mod points :P

four stars out of how many?

[Bobzibub]

Just asking....

-b

Re:four stars out of how many?

[pembo13]

Stars are usually out of five (5).

You know...

[Anonymous Coward]

For a group of people that prides themselves on being so smart, the average Slashdot Submission (and subsequently, the posting of said submission to the front page) is rife with grammar errors.

to individually download - split infinitive

Proofreading is so simple, yet none of you ever do it.

Re:You know...

[pembo13]

I dare say that spelling is a very poor metric of overall intelligence, esp. considering that correct spelling is not essential for useful communication.

Re:You know...

[prockcore]

I dare say that spelling is a very poor metric of overall intelligence, esp. considering that correct spelling is not essential for useful communication.

It is essential for programming however. Which, considering how many programmers are purportedly on slashdot, I find ironic.

apt-proxy

[Douglas Simmons]

For those of you running Debian networks with a lot of boxes, you can use apt-proxy to apt-update/upgrade and patch all the machines through one download.

Gentoo Linux anyone?

[wolverine1999]

What about Gentoo's system where you use emerge and emerge sync...
Did it get a mention, or not?

Re:Gentoo Linux anyone?

[Anonymous Coward]

No, because no one uses Gentoo for anything serious.

Re:Gentoo Linux anyone?

[YouCanCallMeAl]

The author was testing emerge, but as it's still compiling, he had no results by the publication deadline.

Re:Gentoo Linux anyone?

[Ziviyr]

I'd give him ten bucks for a 300MHz machine if he needed a faster system...

Re:Gentoo Linux anyone?

[Anonymous Coward]

That's not true (you're just a troll, no?)....

Package management includes testing.

[khasim]

Then you'd have to trust that the distro doesn't self destruct by patches breaking your vital (read mission critical here) services.

No trust allowed.

Before anything goes into production, it goes into test.

YOU are the one responsible if a package breaks a production server.

You can still set a cron job to auto-magically download and install the apps, but you'd point it to your own repository where you put only the packages that have passed your testing.

The more "mission critical" something is, the less you want to automate ANY process that changes ANYTHING on the OS or apps.

For our critical database server, I come in on the weekend and hand apply every patch. And that is AFTER those same patches have been applied to the test server.

packages are for people who like windows

[v3xt0r]

Shell Scripting is for people who like (and know how to use) *NIX.

Who needs packages and 'patches' when you can automate the installation/update across 12931293789321728 machines from the execution of 1 simple (hand-coded) shell script, using NFS and rsh.

Authors Wanted

[Bruce Perens]

We're looking for more authors. All books in the series are placed under the Open Publication License (commercial use permitted, it's a real Open Source license) and made available in source and unencrypted PDF three months after they get to bookstores. Paper copies sell through about as much as other books outside of the series. We get good placement in brick-and-mortar bookstores like Borders and Barnes and Noble. But IMO the biggest benefit to authors is that once sales die down your book won't be locked away while you don't have any rights - a common headache that technical book authors have. Open Source books are living books.

Interested? Write to Mark_Taub at Prenhall.com and say you're interested in being in the Perens series.

Bruce

Bah humbug

[Anonymous Coward]

patch management? Don't make me laugh:

sudo apt-get update && sudo apt-get upgrade

Two to three steps needed.

[jd]

Step 1 is only required if some patches are optional AND either have to be applied in a certain order or can't be applied together at all. This step involved using the %pre phase of the RPM to roll back any changes that will clash with the patch that you want to install.

Step 2 has two parts. Files that simply overwrite existing files can be installed with no further change. There probably wouldn't be too many examples of those. The other step is to install patch files into a patch archive directory.

Step 3 has one mandatory part and one of two optional parts. The first part is to apply the binary patch(es). You're always going to need that. The second part is to re-insert patches rolled out by the %pre phase that can be rolled back in again at this point. This is only meaningful if there is a %pre phase. Finally, if there isn't a %pre phase, you want to clean up the patch archive directory.

You now have a binary patch RPM.

Could Xen help?

[jd]

If you had two Linux virtual systems, you could update the one not in use, then fail-over all of the running applications to it. You then update the one that was in use. The kernel is then updated, but the user doesn't have to wait for a reboot, as a virtual system is always running.

Linux patching Software

[Anonymous Coward]

I think they folks at Matrix42 (www.matrix42.com) have a product that can patch Linux as well as Windows from the same server. not sure how that's possible.

Re:yawn: in linux, it's called a package, not a pa

[ahodgson]

You could run Gentoo, and get to do both ...

What's in a name?

[51mon]

Great review, interesting book, I'll consider buying a copy.

But the name "Patch Management" sorry that really grates on me. Almost universally GNU/Linux systems have abandoned patches, and perform upgrades to whole components at a logical level. Its the best way to do it found so far, but I don't think of those as "patches".

Or is that just me?

It's a good read

[TarrySingh]

I have it and I liked it. Its time we started treating this OS as a proper productino ready OS.

Excellent book and a very good review

[Anonymous Coward]

This is a book I would recommend to any body interested in keeping their Linux machines upto date. Very well written book with scores of examples. And the reviewer has done justice to the book by writing such a descriptive and well rounded article.

APT makes this a no-brainer. Perfect debian dist..

[CarpetShark]

APT makes this stuff so simple, that the idea of writing a book on it is ridiculous. Just configure machines, using other apt tools for major roll-outs if necessary, and set up a proxy server which caches patches, then serves them to clients. If you want to pre-approve patches, you can do that too by running commands on demand rather than automatically. Simple. Or, as simple as you can expect it to be, at least, given that patches sometimes break stuff on any system. What we really need though, is organization-wide security, like Active Directory (and maybe eDirectory) provides. Right now, you can lock desktops down via KDE's kiosk tools, and secure directories and devices etc., but on other systems, you can specify configuration for many programs on a network-wide basis, or group-wide, or whatever. I'd love to see a debian-based distro that takes that seriously, and patches every util/app/desktop to support it fully. There are frameworks to do this, and KDE 4 is going to use one I think, but apart from that, it seems to be about the only interest I've seen for such a huge gap in the Linux market :(

Save $6.30 by buying the book here!

[Anonymous Coward]

Save yourself $6.30 by buying the book here: Linux Patch Management. And if you use the "secret" A9.com Instant Reward discount, you can save an extra 1.57%! That's a total savings of $6.77, or 19.07%!

An alternative approach: Don't patch, use rsync

[bit01]

I like making all files on all machines on a LAN, excluding network addressing, electronic licensing and logs, bit-for-bit identical. Doing so massively reduces management overhead and improves management control.

I've managed networks of several hundred machines this way and it works well. I checksum all files and directories on all machines on a regular basis and if anything's different in time or space I find out why and make sure it doesn't happen again. I've found dozens of very obscure and troublesome software and hardware bugs this way, have very good uptime and I can concentrate on making sure the master machines are well configured rather than waste time trying to put out fires all over the network all the time. If individual machine classes need to have different configurations I partition those differences out and manage them separately

Distributing patch packages is error prone. By working at the file level it's easy to be confident everything is okay. You can also often distribute and back out "patches" (just a list of files to be rsync'ed) in the background very quickly at short notice with minimal impact on users.

---

Keep your options open!

Michael Yang... clueless

[Anonymous Coward]

This is the same Michael Yang that wrote the RHCE Study Guide..? the same one that is full of mistakes..? read it and try and comprehend LVM using his book.. you cant because he doesn't seem to understand what hes writing and conveys that confusion to the reader brilliantly.

After several of us obtained our RHCE's we coined the book 'The big red book of sh*t'.

I'm quite happy to keep away from anything written by this man.