Shorewall users - Oct 2005 - restarting shorewall when doing a network restart

Hi,

We have shorewall running on several RHEL4 machines. When we do a
network restart (ie. service network restart) the firewall seems to go
into an undefined state where all packets are being dropped but nothing
is logged to the messages log. Once we do a service shorewall restart it
works perfectly again.

Is there a way to make the service network restart restart shorewall
too? Is this a bug in shorewall?
-- 
Tim Edwards



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl

Tim Edwards escribió:
> Hi,
> 
> We have shorewall running on several RHEL4 machines. When we do a
> network restart (ie. service network restart) the firewall seems to go
> into an undefined state
shorewall doesn''t go to any state, shorewall is not running on the 
background ¡¡¡


  where all packets are being dropped but nothing
> is logged to the messages log.

seems to be the expected behaviour..

Once we do a service shorewall restart it
> works perfectly again.
show me ONE place in the documentation refering to "service shorewall 
restart" gee.. nobody reads the manual ¡¡ :(

> 
> Is there a way to make the service network restart restart shorewall
> too? 
a simple script can do that,figure it yourself.
or you can modify your distribution script to do that.


Is this a bug in shorewall?

No.


-- 
Cristian Rodriguez R.
perl -e
''$_=pack(c5,0105,0107,0123,0132,(1<<3)+2);y[A-Z][N-ZA-M];print;''

Tim Edwards wrote:
> Hi,
> 
> We have shorewall running on several RHEL4 machines. When we do a
> network restart (ie. service network restart) the firewall seems to go
> into an undefined state where all packets are being dropped but nothing
> is logged to the messages log. Once we do a service shorewall restart it
> works perfectly again.
> 
> Is there a way to make the service network restart restart shorewall
> too? Is this a bug in shorewall?
Cristian has reacted strongly to this post and I don''t blame him. Your
post reveals that, for someone who is running "several RHEL4
machines",
you are distressingly uninformed about how things work.

When you ''service network restart'' you are in effect rebooting
the
networking part of the kernel. All network interfaces are downed and
reconfigured from scratch. All routes are removed and reestablished.

When you ''service shorewall start'' (You apparently
don''t know that there
is an /sbin/shorewall program even though it is exhaustively described
in the Shorewall documentation), Shorewall configures Netfilter and,
depending on what your Shorewall configuration includes, it may also
configure the arp cache, routing, add addresses to networking
interfaces, manipulate /proc/sys/net/ipv4/... etc. So it is virtually
certain that ''service network restart'' will undo much of what
''service
shorewall start'' has accomplished. And the result is that "things
don''t
work"

As discussed in the Introduction to Shorewall
(http://www.shorewall.net/Introduction.html), Shorewall is not a daemon
that runs continuously in your system. It is rather a set of Shell
scripts that perform static configuration and that once "shorewall
start" has completed, there is no Shorewall code whatsoever running in
your system. So there is no part of Shorewall running in your system
that can try to repair the carnage inflicted by "service network
restart" -- that is a fact of life resulting from what Shorewall is (and
is not); it is not a "bug in Shorewall".

As to your question "Is there a way to make the service network restart
restart shorewall too?". It is shocking to me that so many Linux system
administrators have absolutely no idea of how SysV Init works. Without
giving a tutorial about SysV Init, suffice it to say that under RedHat,
"service <service> <command>" is the same as
"/etc/init.d/<service>
<command>". So:

	service shorewall restart

and

	/etc/init.d/shorewall restart

do the same thing. And if you take a quick look at
/etc/init.d/shorewall, you will see that what really happens is

	/sbin/shorewall restart

which described in the Shorewall docs.

Similarly,

	service network restart

and

	/etc/init.d/network restart

do exactly the same thing. So if you want "/etc/init.d/network
restart"
to also restart Shorewall then you need to read that shell script and
understand what it does -- you may find that there is a
''local'' file
invoked by "/etc/init.d/network restart" that you can modify to
include
an "/sbin/shorewall restart" command.

Finally -- I think that most experienced Linux administrators would
agree that issuing ''service network restart'' on a production
system
isn''t something that should be done except in the most dire situations
and that trying to automate the command to repair the damage that it
will inevitably cause isn''t worth the bother.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep wrote:
> Tim Edwards wrote:
>
> Cristian has reacted strongly to this post and I don''t blame him.
Your
> post reveals that, for someone who is running "several RHEL4
machines",
> you are distressingly uninformed about how things work.
> 
> When you ''service network restart'' you are in effect
rebooting the
> networking part of the kernel. All network interfaces are downed and
> reconfigured from scratch. All routes are removed and reestablished.
> 
> When you ''service shorewall start'' (You apparently
don''t know that there
> is an /sbin/shorewall program even though it is exhaustively described
> in the Shorewall documentation), 
I''ve know I can do it that way, I''m just in the habit of using
the
''service'' command for everything.

 > Shorewall configures Netfilter and,
> depending on what your Shorewall configuration includes, it may also
> configure the arp cache, routing, add addresses to networking
> interfaces, manipulate /proc/sys/net/ipv4/... etc. So it is virtually
> certain that ''service network restart'' will undo much of
what ''service
> shorewall start'' has accomplished. And the result is that
"things don''t
> work"
Ok so it does more than just configure iptables, that makes sense, I can 
understand why it happens now. I was just a little surprised that 
nothing was logged but maybe the network restart turned of 
ip_forward''ing or something?
> 
> As discussed in the Introduction to Shorewall
> (http://www.shorewall.net/Introduction.html), Shorewall is not a daemon
> that runs continuously in your system. It is rather a set of Shell
> scripts that perform static configuration and that once "shorewall
> start" has completed, there is no Shorewall code whatsoever running in
> your system. So there is no part of Shorewall running in your system
> that can try to repair the carnage inflicted by "service network
> restart" -- that is a fact of life resulting from what Shorewall is
(and
> is not); it is not a "bug in Shorewall".
I was well aware that shorewall was not a daemon already. Maybe I phrased
my question badly but I didn''t expect the system to go into an
undefined
state with a network restart - it doesn''t on my home system. I can see 
why it would now for the reasons you pointed out above.
> 
> As to your question "Is there a way to make the service network
restart
> restart shorewall too?". It is shocking to me that so many Linux
system
> administrators have absolutely no idea of how SysV Init works. Without
> giving a tutorial about SysV Init, suffice it to say that under RedHat,
> "service <service> <command>" is the same as
"/etc/init.d/<service>
Thanks but I know perfectly well how the SysV Init stuff works. I was 
hoping there was a cleaner solution than editing the network Init script 
but I guess not.
> 
> Finally -- I think that most experienced Linux administrators would
> agree that issuing ''service network restart'' on a
production system
> isn''t something that should be done except in the most dire
situations
> and that trying to automate the command to repair the damage that it
> will inevitably cause isn''t worth the bother.
Again thanks for the tip but I already do all this stuff after hours for 
that reason. Its only a minor thing (I know now to restart shorewall 
after a network restart in future) but I thought it''d be good to 
automate it.

-- 
Tim Edwards


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl