rc.firewall stop should be called during shutdown

marav · 12-22-2022, 01:36 AM

Code:

Thu Dec 22 03:40:55 UTC 2022
a/sysvinit-scripts-15.1-noarch-3.txz:  Rebuilt.
  rc.6: support an optional rc.firewall_shutdown script. Most firewall scripts
  don't need a formal shutdown, but in some cases it can be useful. If your
  rc.firewall script supports a stop parameter, the shutdown script should just
  contain "/etc/rc.d/rc.firewall stop", or rc.firewall_shutdown could also be
  a symlink to the rc.firewall script in that case. But how the script works
  is (like the rc.firewall script support) completely up to the admin.
  Thanks to metaed for the suggestion.
  Please note that contrary to the request, I placed this *after* the network
  is shut down to avoid removing firewall protection while the interfaces are
  still active. Whether it'll work in this place for metaed's (or anyone
  else's) needs, I'm not sure. It's a start. Feel free to weigh in on the LQ
  thread if you have any ideas for improvement, but the goal here is to keep
  this support as simple and flexible as possible.

metaed · 12-22-2022, 11:15 AM

Quote:

Originally Posted by marav

a/sysvinit-scripts-15.1-noarch-3.txz: Rebuilt. rc.6: support an optional rc.firewall_shutdown script.

This is a lovely and unexpected holiday gift. It's just what I wanted. Thank you! 💚 💚 💚

Here's the feedback that you asked for.

Running rc.firewall_shutdown so late is not advantageous for my package. I do not drop shields during shutdown. I only do housekeeping.

It has one disadvantage. The housekeeping step writes a file. With the network down, remote filesystems are down. My package will be incompatible with installations that have /var/lib on a remote filesystem.

This is why, for my purpose, the ideal startup order is: up network, read firewall rules, start daemons. The ideal shutdown order is exactly the reverse: stop daemons, write firewall rules, down network.

I will build in support for rc.firewall_shutdown for 15.1, and I'll handle remote /var/lib as a special case. Later, if you rethink the run order, I will remove the special case.

Again, thank you.