Daniel P. Berrangé wrote: > On Wed, Jul 03, 2024 at 11:14:56AM -0500, Chris Adams wrote: >> I got bit on an EPEL 8 system by upgrading munin-node and losing >> networking to my podman containers. I started digging and found that >> munin uses the %firewalld_reload macro in %post. Then I dug a little >> more and found that there's a number of packages that use that macro. >> >> That's a bad idea IMHO - firewalld explicitly has the idea of transient >> config, and installing/upgrading any RPM that has this macro in %post >> will discard any current transient config with no warning. This could >> be from other services (i.e. podman in my case) but also temporary admin >> config. > > If services are adding non-persistent configs to firewalld, then I > think that they probably need to be monitoring firewalld such that > they can re-create transient config when needed. Aside from live > reloads, the firewalld daemon can also be restarted at any time. > > In libvirt when we detect firewalld, we then put a DBus watch on the > signal org.freedesktop.DBus.NameOwnerChanged, matching on the name > 'org.fedoraproject.FirewallD1' to catch restarts. > > The 'org.fedoraproject.FirewallD1.Reloaded' dbus signal can catch > reloads. > > In both cases, when the signal is seen, libvirt then re-creates its > transient configs Ahh, thanks for the hint Daniel. The Podman Troubleshooting doc appears to cover this, though it's something that users must do manually: https://github.com/containers/podman/blob/main/troubleshooting.md#30-container-related-firewall-rules-are-lost-after-reloading-firewalld Not too surprisingly, it's a bit more of a hassle on EL-8 due to the age of the tooling. It's likely worth moving to EL-9 to implement the simpler solution in the docs (unless the Podman docs are out of date with respect to EL-8). It does still seem less than ideal that package consumers need to manage this themselves. A nicer default would be to do what libvirt does. -- Todd
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
