A Patchmanagement for RHEL with Ansible
Some time ago I've build a RHEL-Patchmanagement based on an ansible playbook. You could find it on:
- GitHub: Tronde/ansible-role-rhel-patchmanagement
- Ansible Galaxy: Tronde.rhel-patchmanagement
In the GitHub repo I've described the use case I built the role for. If you are inerested in testing and using the role in your enviroment, you are welcome. Your feedback is appreciated.
Once this version is setup it creates all necessary files for a patch cycle automatically and sends an email notification to a given recipient address.
EDIT: Version 3.0 left beta status today (2018-10-09) and is available from Galaxy and GitHub as usual.
Best regards,
Joerg
Responses
Expert
1223 points
Good Morning,
I released a new version a few days ago and edited the post above. I'm still not sure if I use Ansible Galaxy correctly respectively in a best practise way. So in case of doubt, use the role from my github repo instead.
Best regards, Joerg
Guru
9710 points
Hi Jörg,
Thank you very much for sharing your work with the community ... much appreciated. Although I (so far) didn't check out Ansible, simply because I don't have to manage a huge amount of systems - I often use Cockpit to manage my machines - I think that many users may gain a lot of profit from your RHEL patch management Ansible playbook. Well done and thanks for your information. :)
Regards,
Christian
Expert
1223 points
Hello,
Today I published version 2.1. This version creates all necessary files for a patch cycle automatically and sends an email notification to a given recipient address. Please see the details in the corresponding Readme.md or in the Relase information.
Regards, Joerg
Expert
1223 points
I've fixed a bug in create_vars.sh and moved variables to seperate file.
There was a bug in create_vars.sh that prevents the creation of a new baseline file. So the patch_set grows over time. This bug was fixed by correcting the typos.
I decided to move all variables to a seperate file and source them in the script create_vars.sh. You could find all varialbes needed in the file variables.txt.example. To use them just copy the file to variables.txt and adjust the values to meet your needs.
The changes are pushed to master. If you like you could test this version and report any errors you encounter. I'll release a new version after I run some tests.
You found the last changes here on Github.
Expert
1223 points
Hi folks,
The current version 2.2 was released today (2018-08-08).
Changes: * Add path vars/main.yml to gitignore * Fixed bug in create_vars.sh and moved variables to seperate file (click here for details) * Added information to README.md on how to use this role
You could find the current version as usual on GitHub and Galaxy (see initial post).
Regards,
Joerg
Expert
1223 points
Good moring fellows,
The mapping of hosts to groups which are named after stages caused some confusion in my department. For more flexibility it should be possible to choose the due date for a patch set regardless of the stage a host belongs to. For example, if it is a Sysadmins wish, his or her production hosts could be the first which receives updates. So I've indroduced new ansible groups called rhel-patch-phase{1..4} and a small hosts.example to make a point that a patch phase does not have to be related to a stage.
This new release was published as BETA on GitHub, only. Please, see the release information for details.
I'm using this release in my production environment since two weeks without any trouble. If there are no issues being reported during the next weeks I'm going to remove the BETA label on 9 October 2018 and import this role to Galaxy, again.
Best regards, Joerg K.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.