On my (OpenWRT) router, I have an "/etc/init.d/shorewall-lite restart" (which effectively is shorewall-lite restore) executed during an "interface transition" (i.e. up/down) event. This is to allow shorewall to adjust the rules and/or routing when an interface changes state. TBH, I don''t so much care about the interface down event as much as I care about an interface coming up when shorewall was restarted with an interface being down. But I digress. The ugly side effect of this is that when the router initially boots, lots of "interface up" events are triggered and thus many "overlapping"/parallel shorewall-lite restore commands are run. This is silly of course[1]. My knee-jerk reaction is to simply have shorewall-lite exit if there is an instance running already, but given more thought, that seems backwards. The earlier instance might have already assessed the interface for which the new instance is being called and thus, the earlier instance has a stale view of the interface status. So it seems the right thing to do is for the new instance to kill the earlier instance before it (the new instance) starts doing it''s thing. This would continue to happen until the last of the initial boot "interface up" events runs to completion. Thots? b. [1] It might seem pretty harmless to have a number of parallel executing shorewall-lite restore processes running given that I recall seeing some locking/timeout code in there to prevent more than one from actually going through their processing in parallel but on a limited memory machine, it would seem that the effect of this is ooms. :-( ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
On Wed, 30 Dec 2009 22:21:25 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> wrote:> On my (OpenWRT) router, I have an "/etc/init.d/shorewall-lite > restart" (which effectively is shorewall-lite restore) executed during > an "interface transition" (i.e. up/down) event. This is to allow > shorewall to adjust the rules and/or routing when an interface changes > state. TBH, I don''t so much care about the interface down event as > much as I care about an interface coming up when shorewall was > restarted with an interface being down. But I digress. > > The ugly side effect of this is that when the router initially boots, > lots of "interface up" events are triggered and thus many > "overlapping"/parallel shorewall-lite restore commands are run. This > is silly of course[1]. > > My knee-jerk reaction is to simply have shorewall-lite exit if there > is an instance running already, but given more thought, that seems > backwards. The earlier instance might have already assessed the > interface for which the new instance is being called and thus, the > earlier instance has a stale view of the interface status. So it > seems the right thing to do is for the new instance to kill the > earlier instance before it (the new instance) starts doing it''s > thing. This would continue to happen until the last of the initial > boot "interface up" events runs to completion. > > Thots?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. b) Hopefully, you have defined the volatile interfaces as ''optional'' so a simple ''shorewall restart'' is all that is needed. c) It is most common to: 1) Start Networking 2) Start Shorewall 3) Start a link monitor like LSM assuming that all interfaces are up. Since interfaces most commonly come up at boot, the link monitor finds all interfaces up and running and there is no storm of activity required. If one of the interfaces is down, LSM soon discovers it and restarts Shorewall. Note -- at least one user with whom I am familier, uses LSM to start Shorewall. That handles the situation where a link comes up between steps 2) and 3). d) I think that it is the Link Monitor''s responsibility to avoid this chaos and not Shorewall''s. My $.02. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
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 NetworkingDoes 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. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
On Thu, 31 Dec 2009 15:25:14 -0500 "Brian J. Murrell" <brian@interlinx.bc.ca> wrote:> 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?Sure.> > > 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.In Ubuntu, ''/etc/init.d/networking'' still ends up running ''ifup -a''. So it means that ifup -a has completed. In the Debian/Ubuntu/... shorewall init script, there is the capability to wait for a list of interfaces to be ready (with timeout). That can take care of stragglers that are slow in starting (usually ppp devices).> > > 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.LSM monitors interfaces by actually using them (ping or arping) and calls a script when the state of an interface changes. At startup, it assumes all monitored interfaces are up.> > > 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.I think there is a need for a ''network startup complete'' event which signals that an attempt has been made to start all interfaces. This appears to still be available in Ubuntu by making $network a startup prerequisite of shorewall.> > > 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.The mechanism in the Debian/Ubuntu Shorewall startup scripts might fit your need. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon''s best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev