On 7/22/10 10:33 AM, Tom Eastep wrote:
> On 7/22/10 10:03 AM, Brad Clarke wrote:
> 
>>
>> The "bad" log is the one you asked for. For comparison, the "good" is
>> what I see when I set REQUIRE_INTERFACE=Yes to make it work.
>>
> 
> With the 'bad' configuration, please:
> 
> a) shorewall compile foo
> b) Send me foo (privately)
> 

We have determined that the failure is do to upstart (the init daemon on
recent Ubuntu releases).

Upstart is an event-driven system initialization daemon that, as far as
I can tell, only supports 1-way dependencies (startup of objects is
triggered by events). Bringing up hardware-based NICs is triggered by
udevd. This makes it impossible to insure that the firewall is placed in
a safe state before network interfaces are started.

Here is a log produced during startup of an SMP Lucid system having a
single NIC (eth1):

  eth1 came up first and caused Shorewall to start.

  Jul 23 07:00:23 Shorewall up triggered by eth1
  Jul 23 07:00:23 Shorewall attempting start
  Jul 23 07:00:23 Initializing...
  Jul 23 07:00:23 Loading Modules...
  Jul 23 07:00:24 Setting up Route Filtering...
  Jul 23 07:00:24 Setting up Martian Logging...
  Jul 23 07:00:24 Setting up Traffic Control...
  Jul 23 07:00:24    TC Device eth1 defined.
  Jul 23 07:00:24 Preparing iptables-restore input...
  Jul 23 07:00:24 Running /usr/local/sbin/iptables-restore...
  Jul 23 07:00:24 IPv4 Forwarding Disabled!

  Then lo came up; since lo is not hardware-based, it is brought up
  in the usual way ('ifup -a') triggered by the networking
  initialization 'job' (That's upstart-speak for 'init script').

  Jul 23 00:07:18 Shorewall up triggered by lo
  Jul 23 00:07:18 up on interface lo ignored

  Finally, the shorewall-init script was executed and stopped Shorewall.

  Jul 23 00:07:20 Stopping Shorewall....
  Jul 23 00:07:20 Running /usr/local/sbin/iptables-restore...
  Jul 23 00:07:21 IPv4 Forwarding Disabled!
  Jul 23 00:07:21 done.

The bottom line here is that system boot with upstart and shorewall-init
is as likely to leave your firewall in the stopped state as it is in the
started state.

The above testing was done with Shorewall 4.4.12 Beta 1 (not yet
released) which ensures that only one event is processed at a time; with
earlier releases, the situation is more chaotic as events are handled in
parallel.

As a workaround, I'm recommending that you use 'startup=1' in
/etc/default/shorewall* to ensure that the firewall is finally placed in
a 'started' state (assuming that required interfaces are available).

-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 \________________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to