Patching Servers

**dipaklinx** · 06-06-2010

Hello all,

We have 2 servers in our organization and it need to be patched. I need to patch the servers this week and I am not familiar with it(new to Linux). Whether any kind of setup needs to be done for patching the servers. Any help is much appreciated.

Thanks in advance,
Dipak

**Irithori** · 06-06-2010

It depends.

First, how you define "patch".
It could mean "make the kernel/an application behave different than before".
But my guess is, you mean "update"?
I will go on with the assumption "update".

Second: I also assume, that the machines are reboot safe.
After a reboot, all needed services are automatically back and useable?

Third: Which distribution are you using?
Fedora, CentOS or RedHat?

RedHat: You need a valid subscription (ie "licence") for each of the servers to
update.
Other than that, RedHat Enterprise -as a server distribution- has fairly stable update paths.
But note the other points below
CentOS: Same as above, but you do not need subscriptions.
Fedora: Some call it the development tree of RedHat, so a update may have one or the other surprise.
But nothing, that couldnt be handled.
Also: no subscriptions needed.

Fourth, is this a update of a major or minor version?
In other words: Are you updating from (for example) CentOS 4 to CentOS 5
or
from (for example) CentOS 5.4 to CentOS 5.5?

Minor version update can and shall be done regularly.
Please read the Technical Notes in the link below, especially the *known issues* section to be prepared
RedHat Enterprise Manuals

Major updates need more attention.
Imho: save all the data and configuration and perform a clean install.

Fifth: Can you verify, that new software was *only* installed via RPM packages,
and to be more precise:
Only from standard repositories, or well defined extra repositories.

In contrast:
Bad: some RPM packages from *whereever* were installed.
This would place you into the windows world, so to say: Go to the homepage of each package and look for updates
Even worse: Software has been installed via source: This is outside of the package manager.
So the admin is the package manager.
Effectivley putting additional effort, time contraints and testing on you.

<RANT>
That last point I have to discuss and clarify again and again with developers and program managers.
"No, I will not compile and install the latest alpha application from code.google.com on production machines, just because you think it´s cool.
I will create a package for it, and add it to our repository. We test it on qa machines. If that proves succesfull and fairly secure, *then* we roll out production.
And yes, this takes additional time."
</RANT>

Sixth: Time for a maintenance window.
You need it

Usually, one would drain (for example) webservers on the loadbalancers or take database servers out of synchronisation and then update one group after the other.

Depending on your answers to these points, an update can be as simple as

Code:

yum update

and -if the kernel was updated- a reboot.
Which takes 15-20min maximum.
This is the case with a well maintained server and a minor version update.

The other extreme is, you spend the next days reinstalling the machines, compiling sources and re-importing data and configuration.

**Rubberman** · 06-06-2010

Well stated, Irithori. A question for dipaklinx: is the system vanilla-standard (other than components added with the system package manager), or have there been any kernel mods or non-vanilla kernel configuration changes (such as adding support for non-mainstream file systems such as jfs, xfs, etc) or such stuff as proprietary hardware drivers installed (as mentioned by Irithori)? Also, which distribution+version of Linux are your servers running?

**dipaklinx** · 06-07-2010

The kernel is default kernel(installed from CD during OS installation) and this is the first time its going for kernel recompilation. CentOS 5 version kernel version is 2.6.18-128.el5.i686. I am familiar in windows like we set up WSUS and download the patches and update it to servers and client. Linux is a new setup in our organization(done to reduce cost).

**Irithori** · 06-07-2010

As mentioned, updating CentOS is usually just a

Code:

yum update

on the machine as root user, with the points above in mind.

If the number of machine grows beyond 10 (ymmv), I would use a multiplexer such as SourceForge.net: clusterssh to do the updates.

For numbers greater 30 (again ymmv), a look at Spacewalk: Free & Open Source Linux Systems Management cant hurt.
Also, central config management like Puppet Labs: The Leading Open Source Data Center Automation Solution becomes more and more mandatory.

For your two machines, both puppet and spacewalk are overkill, imho.

So what is the actual problem ?
a) update CentOS
b) patch a vanilla kernel
c) both a) and b)

**dipaklinx** · 06-07-2010

On the outset I thank you for the valuable inputs. As you said I need to do both options A & B(recompile the kernel and update the server). This is the server which is going to host websites and we need to keep it up to date before proceeding it. It will be loaded with control panels, web and mail servers.

**Rubberman** · 06-07-2010

As said before, unless you have kernel configuration changes or modifications, you don't need to build a kernel to update the system. The yum update will download and install prebuilt kernels for you.

**dipaklinx** · 06-08-2010

I need a clarification if a kernel is re-compiled already; will the yum update can patch it or we need to manually update the kernel. I just need to know whether I have got it correctly or wrongly.

**Irithori** · 06-08-2010

Perhaps a quick overview might clarify this
All files of a distribution are organized in packages.
On CentOS (and several others) RPM is used as a package format.

A RPM contains:
some meta information

Code:

rpm -qi hal

files

Code:

rpm -qvl hal

maybe scripts (executed at install, uninstall,etc)

Code:

rpm -q --scripts hal

has dependencies

Code:

rpm -q --requires hal

is maybe required by other packages

Code:

rpm -q --whatrequires hal

A typical CentOS installation contains several hundred packages.

Code:

rpm -qa | wc -l

It would be a pain to update all RPMs individually.
That´s where "yum" helps
yum can (among other things) resolve dependencies, download RPMS from defined repositorys and install/update them.

Now, the kernel is no exception.
It is handled by the "kernel" RPM.

So the mentioned

Code:

yum update

will bring the whole system -including the kernel- up to date.
To use that new kernel, a reboot is required.
If just daemons like apache, sendmail etc have been updated, restarting them is enough. No reboot is required.

So. Question

Did you do any manual steps like patching or compiling to the kernel as you installed the machines the first time?
If not: no further action is needed.
yum update + reboot will provide you the latest kernel
if yes: repeat the steps for the new kernel

Maybe it´s just a name space conflict :P
Patch in windows world = package update in linux world

Patch in linux would be to modify an existing file with a patch file
Package Update is: remove the files of the old package and install the ones from the new package. (plus script logic)

Thread Tools

Display

Patching Servers

Posting Permissions