Should package management be upgrade first?
I seem to recall at some point in my past reading advice that yum and RPM be upgraded prior to upgrading other software, but I haven't been able to find anything current on the topic. Is this still best practice? If I do upgrade those packages prior to doing a full system upgrade, should one be upgrade prior to the other? I ask because I'm working on an ansible playbook to handle system updates.rhel
Thanks,
Jameson
Responses
Hi Jameson,
Maybe you recall some information you have read about system upgrading, such like upgrading RHEL 7.3 to 7.4 and besides the fact that a clean installation of a new edition of an operating system is always the best and technically recommended option, you should definitely update all packages to the latest stable version to avoid conflicts when you want to upgrade the operating system. So yes, it's still best practice to do this. But if you only want to update packages within a currently installed system, it's not important which packages are getting updated first - what in other words means, you just can run sudo yum update as usual and everything is fine.
Cheers :)
Christian
My view is that if you are managing this level of detail, the package manager has failed its primary purpose.
If packages require updated versions of rpm/yum they will stipulate this as a requirement in their rpm definition (spec) and requirements will be updated/installed in the correct sequence.
If the upgrade of packages breaks because of installation sequencing, there is an issue in the package configuration and it should be raised as a bug.
Joerg,
I am working on this approach too for a customer, and including application and host restarts etc. into the patching process.
Have you posted any of your Ansible playbooks publicly (eg. github)? would be interesting to compare/collaborate.
Hi,
unfortunately it's not on github, yet. Today the description of the role and the process exists only in German language. But I could put an excerpt on github to compare and discuss it.
Give me some time to translate the documentation and I'll put it on github.
Best regards, Joerg
Ok, I brought a first version to github. You could find it in Tronde/ansible-role-rhel-patchmanagement.
I'm looking forward hearing your thoughts on it.
Regards, Joerg
Very impressive Joerg! thanks for sharing this.
It's a really nice approach to organising the patches into patch sets, and then applying them as a collection (to make sure all environments are in step). Are you manually validating the errata and creating the input files by hand or do you have a process to automatically generate the input variable files from the daily Red Hat errata?
Only (very) minor issue I saw was that the role is called 'patch_rhel' in the patch_rhel.yml and 'rhel-patchmanagement' in the test.yml.
Thanks again for sharing this, it looks like you have experienced the same issues as myself when patching, and this is a very clean solution.
Thanks,
I'm happy to give something back to the community. I fixed the minor issue just a minute ago and pushed the commit to github. Thanks for pointing that out.
Today, validating the errata and creating the input file is done manually. That's because I use this role only for some month and want to have a little bit more control over the process. When the file vars/main.yml is created I send a mail to all Sysadmins running RHEL in our organisation to inform them which advisories will be included in the upcoming patch cycle. I'm going to automate these two steps in a feature release.
As a first guess I gather the advisory information with yum updateinfo list all, do some parsing and stuff to create a basline patch set. In the following patch cycles I'm going to run the command again, diff the output to the baseline and use the output of the diff command as input for the varialbe files. If the job is done by some Bash or Python script, I don't know, yet.
It's possible to fully automate the creation of vars/main.yml and the email to be send, but l like to get a solution were I could add some advisories by hand. For example, all RHSA are gatherd and going to be installed automatically but RHBA and RHEA could be added in case they are relevant for all nodes in my inventory. Otherwise the installation of RHBA and RHEA is the job of the Sysadmin owning a certain host. I'm not sure how to do that, yet. But I'll keep you up-to-date.
Cheers, Joerg
Thanks,
If you like to try it out you could find it on Ansible Galaxy, too.
Be careful, please. I've used galaxy for the first time. I'm not entirely sure if I got it all right.
Cheers,
Jörg
Hi,
I've opened a new Thread were we could continue the discussion about the RHEL-Patchmanagement. So we don't have to capture the Thread from Jameson here.
Regards,
Joerg
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
