Best practices to patch Linux servers

Latest response

I know this is not a first time people asking this question, but yes never i found a satisfied solution that i can implement. See my requirement below.
Out of this discussion I wanted to know one (of course standard way) of the best ways to implement patching in my environment. Currently I follow patching automation using a standard shell script in combination with RHN API. My current systems setup as follows.

I manage 2000+ RHEL server (5,6 and 7)
All servers are connected to RHN satellite
Patching policy is quarterly.

Does anyone has better approach then what i follow, please help me out.

Responses

You seem to have the actual patching pretty well managed. However, the "best" patching policy for you is the one that suits your requirements. So what are those? What kind of SLAs (Service Level Agreements) are you committed to?

Patching is generally motivated by system security. Remember that IT security in general has three aspects:

  • Confidentiality - wrong people must not get access to certain things (at least password files and other authentication infrastructure; possibly entire systems and the information in them)
  • Integrity - the information processed must not be damaged in the process, neither by bugs nor by malice
  • Availability - the systems and the information in them must be available for use by the right people; that's why they exist in the first place.

Are you an ISP/webhosting facility where customers bring all sorts of PHP stuff and WordPress installations of various quality and patch levels, and then expose all of it to the internet? If that is the case, and you patch only quarterly, you are probably hosting some malware at this very moment. In this kind of environment, you'll want the ability to fast-track any relevant security patches, even if it costs you some uptime.

Or are you a compute farm for researchers who run simulations that can take days or weeks? Inbound internet access only with key-authenticated SSH or secure VPN? Then you're pretty well protected from external threats and should think mostly in terms of internal ones. If a possibility of different researchers spying on each other is not a real concern, environment reliability and uptime will be your main concerns. In this situation, your patching decisions can be very different.

In any case, you might want to maintain a smaller group of "testing" servers, which will get the quarterly patch set some time before the rest of the servers, so that if there turns out to be a bad patch, or a bad interaction between new patches and commonly-used applications, you have a chance to know it before it affects all your systems.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.