Create roles/copyfail/tasks/main.yml with the above content and run the role in check mode to see if anything needs doing and then run not in check mode if needed to update and reboot servers.
I’ve always wanted to ask. When one should use handlers? My opition - not in the roles.
This is my line of thinking - it is not good to put flush_handlers inside role because you do not know what handlers you are flushing - there might be some existing before the role. So it is better to avoid them in the roles, otherwise you in a way forcing users of the role add flush_handlers after the role execution - adn this breaks assumption that roles are “self sufficient”.
Pattern used in this example (with skip if not changed) is much more robust and clear, from my point of view, - you only force changes you know you caused. Here with reboot this might be a bit more on the edge because this is a reboot, but CVE is forcing (I suppose).
My conclusion is that handlers should not be used in the roles, but only in playbooks. This is of course if you do not want users of your role to manually flush_handlers (which might be good in some cases, like if reboot is handled this way).
What are schools thoughts are there on this topic?
you don’t NEED to use flush_handlers it is there for when you want an ‘early’ trigger. I use roles that only have handlers, to provide them to other roles/plays, sometimes a role has it’s own handlers. For rebooting i have a ‘needs_reboot’ handler, which lives in a role that also has a couple of tasks that check if a system needs a reboot (kernel change, ubuntu flag file, etc), but i also call from my ‘update packages’ plays.
I pointed at handlers as an option, but I’ll try to be perfectly clear, the when: x is changed approach is also fine, use the one that makes more sense in your context.
… and let the ansible-lint complain about it later )).
This is why I have this question in the first place, this ansible-lint rules looks to me as too restrictive. There are certainly use cases when it does not make sense.
As far as I understand, you’re just making sure that algif_aead isn’t loaded automatically. But you would have to ensure that it’s not loaded at all. The website mentions something like:
This should(?) prevent that the module can be loaded, either by a user or a software having the permissions to do it. If this is done, you’re vulnerable.
Additionally, depending on your distro it might not be a loadable module but built into the kernel. I’ve read somewhere that RHEL did this. In that case, adding initcall_blacklist=algif_aead_init or similar to your boot loader should help. Not sure about this, just copy&paste.
Don’t take my word for it, I’ve just had a cursory look at this bug. Please investigate yourself.
I tend to use bash instead of native Ansible approach (modules) to speed things a little bit because we are always dealing with thousands of machines. Also, no restart because we have to do it manually in planned maintenance windows.