Re: [Shorewall-users] preventing a shorewall restore storm

[Brian J. M. <br...@in...>]

On Thu, 2009-12-31 at 07:53 -0800, Tom Eastep wrote: 
> 
> In no particular order:
> 
> a) Yes -- Shorewall uses a lock file to serialize operations that
>    change the firewall state. Unless the 'lockfile' utility is
>    installed, however, the algorithm used is race-prone.

And still results is the possibility of more than one shorewall process
being in memory, although perhaps waiting for other shorewall processes
to complete?

> b) Hopefully, you have defined the volatile interfaces as 'optional' so
>    a simple 'shorewall restart' is all that is needed.

Indeed.

> c) It is most common to:
> 
> 	1) Start Networking

Does this imply all network interfaces are up when this step is done?  I
only ask because distributions (OpenWRT, Ubuntu -- or anything with
upstart) seem to be moving away from the serialized initscript model
where one can assume interfaces are up after the "start networking"
script is complete.

More and more, it seems, distributions are moving to a parallelized
initscript model where each interface coming up is handled in it's own
context and there is no "all interfaces are now up" signal.  This is
where it gets ugly to try to restart shorewall for each interface that
has come up.

> 	2) Start Shorewall 
> 	3) Start a link monitor like LSM assuming that all interfaces
> 	   are up.

From what I could tell at http://www.shorewall.net/MultiISP.html LSM is
basically an "add-on" tool to do much of what OpenWRT's "hotplug" does
where an interface going up or down triggers a script to be run.

>     Since interfaces most commonly come up at boot,

Right, and you model assumes that all of the interfaces are up at the
exit of the "start networking" step.  That's where more modern
distributions are going to fall down.

> the link monitor
>     finds all interfaces up and running and there is no storm of
>     activity required.

Indeed.  I had envisioned something like this for OpenWRT in fact,
where, somehow, that first "down->up" transition does not trigger a
shorewall restart (reload in fact) and, again, somehow, shorewall would
be started after all interfaces have been brought up by the boot.

But as I say, there is no "all interfaces are up" signal provided by
these more modern, event driven, startup systems, so that last part is a
bit of a mystery yet.

> d)  I think that it is the Link Monitor's responsibility to avoid this
>     chaos and not Shorewall's.

Perhaps.  I'm not entirely convinced yet, but I have not gotten to
implementation yet to see how it could be handled more gracefully yet.

b.