Is yum-cron auto-update mechanism safe for production systems?

Latest response

Everyone understands what risks exist with a "normal" package's updates on production systems. Update may change the functional of application, data format, compatibility with other applications, e.g which may result in business-application failure.

1)Is yum-cron with "update_cmd = minimal-security-severity:Important" safe for production enviroment use?
2)What type of changes can update with this severity do to application?
3)Does this security fixes change package version?
4)Does RH responsible for possible problems that this mechanism can cause?

Perhaps there is documentation which provides answers to my questions?

Responses

1)Is yum-cron with "update_cmd = minimal-security-severity:Important" safe for production enviroment use?

Absolutely safe. And it's really recommended to apply the security updates even on Production Setups. It's always preferred to keep systems safe from Vulnerabilities from Internet.

2)What type of changes can update with this severity do to application?

Varies from Configurations to code. Library changes/Behavioural changes. Red Hat tries not to change the applications and there behaviour at all. But if situation needs that, we have to do it.

3)Does this security fixes change package version?

Yes. It changes.

4)Does RH responsible for possible problems that this mechanism can cause?

Depends on what kind of problems. But in case of any regressions, Red Hat resolves it quickly

Applying only security erratas doesn't mean applying ONLY the security related fixes. It applies the RHSA's only. But the RHSA's are the updated packages which might have outdated the RHBAs and RHEAs too.

Let's take an example for that: If you have a package version x-1.0.0 , now an RHBA comes up, version changes to x-1.0.1, you don't want to apply it. Now, another RHEA comes up, version changes x-1.0.2, again you don't want to apply it.

Now finally, we discovered a severe security related bug with critical situation, and released a RHSA which will change the package version to x-1.0.3 and the security plugin will apply that patch, changing the package from x-1.0.0 to x-1.0.3 applying that RHBA, RHEA and RHSA which x-1.0.3 code covers, So bugfixes prior to the Security fix also gets applied as well as those Enhancements too.

The main concern for you should be focused for third party packages. If your third party packages depend on certain specific package versions, then you should not apply errata. Specially for Red Hat packages, Red Hat maintains the backward compatibility, so Red Hat functionalities won't get broken after updates, the possibility is very very very less.

Hello,

RHEL-6

  • I have installed the yum-cron and it doesn't have the "update_cmd " option.
    config file /etc/sysconfig/yum-cron
    Option available YUM_PARAMETER=

RHEL-7

-It has the option mentioned in the document, ie "update_cmd"
But it doesnt have the command "minimal-security-severity:Important" in /etc/yum/yum-cron.conf

[root@rhel7 ~]# cat /etc/yum/yum-cron.conf
[commands]
What kind of update to use:
default = yum upgrade
security = yum --security upgrade
security-severity:Critical = yum --sec-severity=Critical upgrade
minimal = yum --bugfix upgrade-minimal
minimal-security = yum --security upgrade-minimal
minimal-security-severity:Critical = --sec-severity=Critical upgrade-minimal
update_cmd = default

RHEL-6 doesn't have the option as per the document, and RHEL-7 doesnt have the command "minimal-security-severity:Important" !!!!

Please clarify the option which we have to use in both the cases for important update only.

-- Jobin

Hello,

even if the method is considered "safe", you should have a process to check what the updated packages affect, like potential configuration file changes (use rpmconf -a to detect and merge them) or a restart required by low-level package (use yum ps to detect them)

//Zdenek

I don't think it is a great idea to use yum-cron to update production machines blindly.

It's always good to test an update first, hopefully you have like builds and like apps where you can test an update for a like build and a like app and then feel safe apply the update.

With that said on RHEL7 you could keep your repo cache updated.

i.e. set your yum-cron default command to yum makecache fast

Then when you get ready to update your production systems it should be quicker as the cache is already updated.

I agree with Dave here (and thus disagree with Pushpendra's advice). Blindly updating packages is never a good idea.

Furthermore, in many situations, security updates won't actually take affect until processes are restarted (e.g., when libraries are updated). That means you can update all you want, but until you reboot or go through a manual process of identifying and restarting the relevant processes, you're still vulnerable.

On the other side of the coin, some packages that provide services (like Apache httpd) actually restart their service as part of the rpm scripts which could obviously be a BAAAAD thing on a production box -- e.g., for httpd: a full restart means completely cutting the connections of all existing clients which would be a huge outage in the case of a production proxy/webhost serving thousands of clients.

Does yum --bugfix update-minimal also apply security fixes (e.g., if only security fixes are available in updates)? I'm looking for a combination for yum-cron that would apply both security fixes and bugfixes but not enhancements.

How, please, do I set yum-cron default command to yum makecache fast ? Is it as simple as update_cmd = yum makecache fast ?