Description of problem: Ansible DNF module fails to warn about RPM scriptlet failures. RPM command line tools and DNF in the CLI mode do warn when e.g. RPM package's %post section fails. Ansible DNF module silently ignores such failures. This is a potential source for lots of confusion, and in the worst case even security related problems. Version-Release number of selected component (if applicable): Ansible 2.6.2 How reproducible: Always Steps to Reproduce: 1. Create an RPM package with %post section that does "exit 1" 2. Upload RPM file to target machines /tmp 3. Use Ansible DNF module to install RPM from /tmp Actual results: Ansible DNF module shows no warnings, it just installs the RPM and shows success Expected results: I know that %post scripts should NOT exit other values but 0, but would it be possible for Ansible to emit a warning? See additional info below for rationale. Additional info: I have created an RPM package, let's call it foo. In the same foo.spec file I have a subpackage foo-selinux. They depend on each other and foo-selinux must be installed after foo. I had a typo in foo-selinux %post section, something like: %{_sbin}/semodule -i [path/to/foo.pp] || : (It should have been %{_sbindir}) Even after replacing the end with "|| exit 1", I could not find the error, because I have automated installing with QEMU virtual machines and Ansible. So it looked like %post was actually never executed at all. It is VERY important that the foo-selinux security module gets loaded after being installed, otherwise foo is without SELinux protection. Judging from the Ansible output, everything went fine, but: semodule -l | grep foo showed that foo.pp module was not loaded in the kernel. I know the typo was my fault, but in my opinion Ansible could at least report warnings instead of silently ignoring scriplet errors. I found out that foo.pp was not loaded because foo app did not work properly without it, but others might not be so lucky. Someone might install a SELinux protected daemon and THINK it is confined when in reality it is not. This is the potential security issue we have here. I will report this to Ansible upstream, too.
I am not sure, but I fear this failure to warn about scriptlet errors is not limited to installing from target machine's filesystem. It could exist when installing from repos, too. Maybe someone could confirm this?
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.