Firewalling 90% complete & tested, questions about writing tone

Dagmar d'Surreal evildagmar at comcast.net
Wed May 5 13:23:06 PDT 2004


On Wed, 2004-05-05 at 13:03, Kelly Anderson wrote:
> > start)
> >   if [ -z "$FIREWALL_SCRIPT" ]; then
> >     permit_inbound from ANYWHERE to DMZNET for http
> >   fi
> >   apachectl start
> 
> Hmmm, it looks to me like the permit_inbound (and any other like 
> functions) could write out the parameters that are passed to a state 
> file which could be used in the event of address change.  That would 
> certainly keep the main control localized and require no changes to 
> package init scripts.

Frankly I'd thought of that, and then decided it would be easier by far
to make a whole lotta custom chains and jump to those, and then delete
the chains, although that's going to slow things down.  It would also
dramatically increase the size and _complexity_ of the support script.  
It can be a v2 change, but I'm simply not messing with that right now. 
v1 is to _just get the API working_ because changes from that point
forward will be transparent to the rest of the system, and only be a
single change-management item to deal with.  I'm trying to be absolutely
certain that future changes will impact as little of the system as
possible.

In any case, there is still the problem of whether or not people are
doing themselves a disservice by attempting to run any kind of daemon on
a dynamically assigned interface.  When an interface changes, all
current connections are broken, and any daemons that actually bind to
that particular IP address (which is the more explicit and for the
common case, the safer way to do it) will cease to function anyway.  The
quick fix for this event would be to start and stop the affected daemons
on an interface change, in which case the obsolete rules would simply
become a bunch of do-nothings, but the bigger problem of using a dynamic
interface in the first place still remains.




More information about the hlfs-dev mailing list