Bug 967264 - [plugins] Support post-transaction actions
Summary: [plugins] Support post-transaction actions
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jaroslav Rohel
QA Contact: Fedora Extras Quality Assurance
: 1038936 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2013-05-26 05:58 UTC by Heiko Adams
Modified: 2020-03-02 13:53 UTC (History)
15 users (show)

Fixed In Version: dnf-plugins-core-4.0.12-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1220182 (view as bug list)
Last Closed: 2019-12-03 09:37:52 UTC
Type: Bug

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1220182 'unspecified' 'CLOSED' '[plugins] Support post-transaction actions' 2019-12-03 08:46:54 UTC

Internal Links: 1220182 1788574

Description Heiko Adams 2013-05-26 05:58:28 UTC
Description of problem:
yum has a plugin for doing some actions after a transaction is finished which is IMHO very useful. Please add support for those post-transaction actions to dnf.

Comment 1 Ales Kozumplik 2013-05-27 07:28:41 UTC
DNF doesn't yet provide a plugin API so that should come first. Leaving this open until then, shouldn't be a problem.

Comment 2 Ales Kozumplik 2013-12-06 10:00:08 UTC
*** Bug 1038936 has been marked as a duplicate of this bug. ***

Comment 3 Ales Kozumplik 2013-12-06 15:25:46 UTC
Fixed by 6e60010 on master, the new API will be included in dnf-0.4.10.

Comment 4 Fedora Update System 2014-01-02 10:09:29 UTC
dnf-0.4.10-1.fc20 has been submitted as an update for Fedora 20.

Comment 5 Fedora Update System 2014-01-03 08:41:12 UTC
Package dnf-0.4.10-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.4.10-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2014-01-04 19:52:53 UTC
dnf-0.4.10-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Lauren 2015-04-24 01:03:16 UTC

This bug should be re-opened, as the request for a dnf equivalent to yum-plugin-post-transaction-action has not been fulfilled, only the first step towards that goal (support for plugins in dnf) has been addressed thus far.

Comment 8 Lauren 2015-04-24 01:05:16 UTC
Typo -- the correct name for the package is yum-plugin-post-transaction-actions (with an "s" at the end)

Comment 9 Freddy Willemsen 2015-11-16 12:35:25 UTC
Agreed, I would love to see the equivalent of yum-plugin-post-transaction-actions in DNF. I miss it dearly. So why this bug was closed is beyond me.

Comment 10 Francisco Peralta 2019-05-23 08:22:10 UTC
please re-open and prioritize

Comment 11 Daniel Mach 2019-05-27 11:09:05 UTC
could you provide several use cases it should cover?
It would help us to understand which functionality should be covered and how.

Comment 12 Francisco Peralta 2019-05-27 12:12:46 UTC
Hi Daniel,
 yes sure.

 I've recently visited some RH customers that are migrating to DNF/RHEL8 and thus will face now the problem of migrating all functionalities they had in place with YUM into DNF.

 Most of the use cases I've seen there, are related either to:
 - post Linux kernel update, actions to schedule a smart system restart afterwards (incl. jump into the new kernel with KEXEC at the end)
 - post e.g. httpd update, permission fixes/adjustments and/or service restarts
 - post update scripts, that update some centralized database about a newly installed package (configuration management DBs)
 or otherwise there are still some other very specific use case post update scripts that many customers have implemented.
 If it would really help here, I could try to investigate and see if I can get/post samples of those scripts, but I doubt this will be easy TBH...

 In general my impression is that even if you might have other ways to achieve similar results, this would be a meaningful place where to do it.

 Also I would consider it kind of a "regression" to the features of YUM, one might expect to find again in DNF as well.
 For that reason I would also not reimplement the wheel in a different way, but rather see if it could be possible to migrate the functionality from here: https://github.com/rpm-software-management/yum-utils/blob/master/plugins/post-transaction-actions/post-transaction-actions.py

 Of course all this only if it makes sense and if it's technically still possible: what do you think about it?

Kind Regards,

Comment 13 Freddy Willemsen 2019-05-27 12:40:11 UTC
Francisco already stated some valid use cases.
For what it is worth, these are some of the use cases that were relevant for me in the past other that the ones already mentioned by Francisco:
- change some 'default' program setting that would reset upon every update.
- When using the Oracle JRE, update alternatives upon install/update/delete.
- When using Oracle VirtualBox, automatically download and install the correct Extension Pack and download the latest Guest Additions.

Comment 14 Markus Schibli 2019-05-28 08:24:53 UTC

my customer is asking for the post-transaction functionality too. They're migrating to RHEL8 and need it for:

- runing their inventory tools afterwards 
- doing some clean-up tasks afterwards

Would be nice to have the plugin also in dnf as we have it in yum.

Thanks and regards

Comment 16 Jason 2019-09-25 15:19:46 UTC
Also requesting a port of this package.
The httpd package resets the permissions on /var/log/httpd to 0700 each time the package is updated.
We use it to change the permissions on the /var/log/httpd to 0755 so that non root users can access the logs.

Comment 17 Simon Mijolovic 2019-10-05 02:33:03 UTC
Is there a way to elevate this feature enhancement?

yum-post-transactions-actions is one of the MOST efficient ways to keep a system resilient from baseline drift with zero day threat elimination. Upon the completion of an update, a subsequent ansible/salt/puppet/chef call can be executed to make sure the system reapplies security and configuration baselines.

I'm frankly surprised how rare this gem seems to be used...it's a critical part of a zero-day cyber arsenal.

Comment 18 Adrien Mahieux 2019-10-16 08:28:59 UTC

For the migration to RHEL8, this is a show-stopper: we need it to ensure proper drivers are added after kernel updates.

As there is no way for a package to define itself as a dependency for another (eg, when kernel is updated, dnf will pull the related version of the driver too), we need this post-install script to do this work (and no, DKMS cannot be used, nor weak-updates).

If every time we update the kernel we lose the network drivers (among other stuff), there's no need to test further rhel8.
If something as fundamental as the package manager can't do it while all others can (APT::Update::Post-Invoke, /etc/portage/bashrc, /usr/lib/zypp/plugins/system...), as the RHEL8 migration workload is already substantial (re-qualification of all apps, configuration updates, scripts fixes...) we'll rather find another OS.

This case is open for many years, yet it seems to need the RHEL8 enterprise clients to have proper attention (and still, no update since 8 august).
Please prioritize this regression accordingly.

Best regards

Comment 19 Jaroslav Rohel 2019-10-30 11:33:30 UTC
I created post-transaction-actions plugin for DNF.

It's configuration is very similar to the YUM plugin. The main change is states in action file. 
Line format is the same: "action_key:transaction_state:command"
But the old YUM plugin supported stransaction_state:  "update", "install", "remove", "any". It was confusing because "install" meant also update, obsolete, ... The same problem was with "remove". It also meant obsoleted, updated, ...
So, new DNF plugin supports transaction_state: "forward" (packages that appeared on the system, or was reinstalled), "backward" (packages that got removed from the system), and "any" (all packages).

Command can be shell command. ${state} variable can be used to obtain the state of the concrete package in transaction ("downgrade", "downgraded", "install", "obsolete", "obsoleted", "reinstall", "reinstalled", "remove", "upgrade", "upgraded"). It is similar to the old YUM plugin but there is more states now.

PR https://github.com/rpm-software-management/dnf-plugins-core/pull/366

Comment 20 Jaroslav Rohel 2019-11-14 11:27:11 UTC
After discussion I changed the statuses name once again. Finally:
"in" - packages that appeared on the system, or was reinstalled
"out" - packages that got removed from the system,
"any" - all packages

Plugin PR https://github.com/rpm-software-management/dnf-plugins-core/pull/366

CI tests for the plugin PR https://github.com/rpm-software-management/ci-dnf-stack/pull/675

Note You need to log in before you can comment on or make changes to this bug.