On Thu, 2018-04-12 at 09:10 -0700, Tom Eastep wrote: > > No -- it requires the firewall script to be compiled with the fix, as > well as having the fix installed on the shorewall[6]-lite firewall.
# rpm -q shorewall shorewall-5.2.0-0.01.fc28.noarch # opkg info shorewall-lite Package: shorewall-lite Version: 5.1.12.3-1 So I should have the intended fix, yes? From a reboot of my router this morning: # ps -ef | grep lock root 3166 1 0 06:24 ? 00:00:00 lock /etc/shorewall-lite/state/lock root 7089 1 0 06:26 ? 00:00:00 lock /etc/shorewall-lite/state/lock So the locking appears to be still leaving orphans behind. I have been considering an alternative approach to this locking. When multiple shorewall invocations race, I really only likely care about the last one winning the race cleanly, since they are most likely racing just because of an interface status change and the last to enter the race will configure the firewall with the status of all interfaces (and other state) already known to him. So really, the last shorewall process to enter a race should just kill off it's predecessors and continue on it's way. That requires that the firewall installation script be able to deal with any kind of previous partial state though. Not sure how well shorewall is able to do that. It would require the ultimate of idempotency. Cheers, b.
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
