-
Notifications
You must be signed in to change notification settings - Fork 417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't e-mail when updates cannot be installed #1918
Comments
There is a related Bugzilla ticket: https://bugzilla.redhat.com/show_bug.cgi?id=2170093. |
@jan-kolarik Thanks for the pointer. I went to add this ticket to RHBZ#2170093 as a upstream ticket but that functionality seems to have been removed from RH's BZ. :-( |
I started working on the related BZ and realized this is a different issue. I was looking into the current implementation of |
I guess that's a matter of semantics/perspective. That it fails silently is a bug at some level, whether that is in implementation or design. IMHO. |
The silent fail described in the given Bugzilla is definitely a bug, while I am not sure about the reporting emitters functionality. Looking into the man page though, it is stated there as "reporting the results", so it seems not only the successful cases, but I need to clarify that with the team. |
It seems that sending notifications on failure was not implemented or intended yet. While our current focus is primarily on DNF5 development, adding this feature to the system is not our top priority at the moment. However, we have added it to our backlog and will consider it in the future. |
Really? Even though this is quite arguably a system security/vulnerability issue? Systems that silently fail the automatic DNF update fall further and further into becoming a security nightmare as those systems continue to fail to install potentially very important security updates. |
@brianjmurrell I attempted to work on this on my own time: #2005 |
I'd be happy to do the review. |
Fixed by #2005. |
Are you kidding me? So that a vulnerable system would be sitting there without any reporting, ripe for exploitation? |
If properly configured by "send_error_messages = yes" config option, dnf-automatic emitters can also report errors occured during the dnf-automatic run. Test is for: rpm-software-management/dnf#1918 https://issues.redhat.com/browse/RHEL-61882
If properly configured by "send_error_messages = yes" config option, dnf-automatic emitters can also report errors occured during the dnf-automatic run. Test is for: rpm-software-management/dnf#1918 https://issues.redhat.com/browse/RHEL-61882
If properly configured by "send_error_messages = yes" config option, dnf-automatic emitters can also report errors occured during the dnf-automatic run. Test is for: rpm-software-management/dnf#1918 https://issues.redhat.com/browse/RHEL-61882
I have dnf-automatic configured to send e-mail reports. This works very well when dnf-automatic is able to apply updates.
However when it cannot, due to perhaps package conflict or even just needing to accept a new repository key, dnf-automatic is completely silent. No e-mail, no nothing.
So unless I am auditing each morning all of the systems I do get an e-mail about, it's very easy to miss that a system is not being automatically updated, for days or even weeks.
Clearly this is a security issue as one of the primary pros of automatically updating is keeping one's system up-to-date with security updates.
The text was updated successfully, but these errors were encountered: