A Patchmanagement for RHEL with Ansible

Latest response

Some time ago I've build a RHEL-Patchmanagement based on an ansible playbook. You could find it on:

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.
EDIT 2018-11-09: Release tag was changed to 3.0.0 to fit the semantic version requirements for the galaxy import.

Best regards,
Joerg

Responses

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

ansible-galaxy still installs v2

$ ansible-galaxy install -c tronde.rhel-patchmanagement
- downloading role 'rhel-patchmanagement', owned by tronde
- downloading role from https://github.com/Tronde/ansible-role-rhel-patchmanagement/archive/v2.0.tar.gz
- extracting tronde.rhel-patchmanagement to /root/ansible-solsb/roles/tronde.rhel-patchmanagement
- tronde.rhel-patchmanagement (v2.0) was installed successfully

Hi Volker,

Thanks for letting me know.

I was able to reproduce the problem but I don't have any clue why it downloads only v2.0, yet. I imported the role again an hour ago and still get version two when installing with the ansible installer.

I need to dig somewhat deeper into the galaxy import. When the problem is fixed I'll give you a short update in this thread.

Best regards, Joerg

Problem found and solved.

During this year the semantic versioning scheme has become mandatory for galaxy import. I had to change the release tag on github, remove the role from galaxy and import it again.

The role is now available at tronde.ansible_role_rhel_patchmanagement

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

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

Hi Jörg,

Thanks for the update - now we know what you have been doing during the holidays. :)
I wish you a successful year 2018 and, most important - best possible health condition.

Regards,
Christian

Thank you Christian,

And I wish you a healthy and successful new year, too. :-)

Regards,

Joerg

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.

Hi Jörg,

Thank you for the update and also for continuously sharing the progress of your work ... much appreciated. :)

Regards,
Christian

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

Hi Jörg,

Thanks (again) for your update information ! :)

Regards,
Christian

You are welcome, I'm happy if I could give somthing back and share some stuff with the community.

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.

Well, no further issues occured. So the next release left beta status today and was released on Galaxy and GitHub.

Feel free to give it a try.

Jorg, This looks awesome working on it now. Is there a way to set it to just do critical and security updates?

Thank You David

Hello David,
Just installing security updates is the default. With default settings only updates from Red Hat Security Advisories (RHSA) are getting installed.

However if you like to install RHBA and RHEA as well you need to edit the regexp in line 8 of the file create_vars.sh, because per default it only matches security advisory.

Best regards,
Joerg

Jorg, Got everything working with your role but for whatever reason it is not sending the email out when the create_vars.sh script is run. I ran the bash script with debug and verbose on and this is what I get when it hits mail section.

create_mail + create_mail + cat send_mail + send_mail + /usr/bin/mailx -s 'Announcement of the installation of Red Hat Advisories' david_teage@mydomain.com

If I run the /usr/bin/mailx -s 'Announcement of the installation of Red Hat Advisories' "${MAIL_RCP}" <"${MAIL_TEXT}" part outside of the script (replacing the variables) it seems to work fine. Any suggestions?

Thank you David

Hello David,
Sorry I don't have any idea why that happens. I did not experience this issue, yet.

When some command does not work in a script but does work when running it in an interactive bash there are sometimes differences in the setting of the environment variables. Maybe here is something fishy. But it is only a wild guess.

Best regards,
Joerg

Sorry if this isn't related to email issues -- but did local emails work and remote emails get rejected? Regarding email, I did notice a subtle change in RHEL7. As I have upgraded to or deployed new VMs with different RHEL versions, I noticed I had to uninstall sendmail and add postfix to get the emails to go to EXTERNAL users (i.e., vendors, backup / DR email accounts) from cron jobs that relied on that functionality. Lots of articles on "a conflict with sendmail and postfix mail components in Red Hat 7 which prevented email from being sent by our new ____e servers properly."

Solution basically follows

(1) yum [--noplugins] remove sendmail;   
(2) yum yum [--noplugins] install postfix  
(3) systemctl status postfix 
(4) add "relayhost = ...." value into /etc/postfix/main.cf 
(5) systemctl restart postfix 
(6) use favorite editor to create test bash script (vi testemail.sh) to send email 
mail -s "This is a test of `hostname` at `date`" -r localuser user@external.emailaddr user@localexchangeserver.emailaddr <<DOC
....
..
..
..
DOC
(7) bash testemail.sh
(8) Check email on external phone
(9) Worked?   test your cron jobs

--> more on point --> Jorg. I am going to review your offering -- looks great. My use case is to bring down linux RPMs whether as a result of Insight reports or other threat monitoring tools to local RHEL server, and have Oracle servers on RHEL that have limited access use the local RPM server for controlled updates. As this control server is accessible to my Ansible engine, I may look at how to use script to always pre-stage RPMs .

Thanks for your efforts and commitment to the community. Larry