safe rpm repository for DMZ

Latest response

Hello, I am thinking to create separate rpm repository for DMZ servers that will server proven packages that are not brand new but released for 2 weeks - 1 month. In my opinion that will prevent any undiscovered security problems in rpm packages to be pushed to internet facing servers.
What do you think, it is good idea and how to do it? For example have repo that is not synced for some time and go through list and check if any of included packages does have reported security problem?

Thank you for your reply.
Lubomir

Responses

This sounds like an ideal use-case for Red Hat Satellite + a Red Hat Satellite Capsule.

Hello Lubomir,

IMHO the delay of the package installation won't do the trick here. Think about it this way. When you install a package version that is already two weeks old it will have the same bugs and vulnerabilities as it had two weeks ago. If you install a more current version the bugs from two weeks ago may be fixed but the package may contain new bugs. Do you understand what I mean?

If you wanna have minimum change on your hosts you might want to install only security related updates. You could do this via sudo yum update-minimal --security for example.

Another approach could be to install the patches in different phases, so you decrease the risk of breaking all servers at the same time. If you are interested in that you could find additional information provided under the following link: A Patchmanagement for RHEL with Ansible

Best regards,
Joerg

Hi Lubomir,

You already got some good pointers.

May I change your approach around, to be in line with modern DevOps designs?

There are basically two ways to handle Linux server patch management:

In-place update, or

In-place swap. 

The in-place update takes an existing Linux server and updates the patch level of the Linux operating system. You can have a replicated environment for testing the patches before deploying them. The test environment should be an exact duplicate of your production environment.

The in-swap approach rebuilds all Linux servers with the updated patch level, then re-deploys the applications to those updated Linux servers and cuts the traffic over from the old (non-patched) machines to the new (fully patched) machines. The in-place swap allows you to keep the old environment around for a while in case you find a bug or some type of error in the patching process. At the same, time, in-swap approach ensures that you always have latest patches, without bloated servers with some older patches and libraries...

Regards,

Dusan Baljevic (amateur radio VK2COT)

Hello everyone, thank you for replies. I think we will choose updates based on security flag and as web admins will require new versions of PHP for example.