Bug 967264

DNF doesn't yet provide a plugin API so that should come first. Leaving this open until then, shouldn't be a problem.

*** Bug 1038936 has been marked as a duplicate of this bug. ***

Fixed by 6e60010 on master, the new API will be included in dnf-0.4.10.

dnf-0.4.10-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-0.4.10-1.fc20

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:
https://admin.fedoraproject.org/updates/FEDORA-2014-0089/dnf-0.4.10-1.fc20
then log in and leave karma (feedback).

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.

Ales,

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.

Typo -- the correct name for the package is yum-plugin-post-transaction-actions (with an "s" at the end)

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.

please re-open and prioritize

Francisco,
could you provide several use cases it should cover?
It would help us to understand which functionality should be covered and how.

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,
 Francisco.

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.

Hi,

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
Markus

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.

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.

Hello,

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

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

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

The only issue I've seen with the implemented plugin is that it does not preserve the order of the actions and results in an unpredictable execution order.  I created a PR to fix that and maintain the order as it was defined and read from the action files: https://github.com/rpm-software-management/dnf-plugins-core/pull/413