Shorewall devel - Oct 2003 - shorewall restart failure recovery option?

Hi,

I was thinking about changing the #shorewall restart command a little bit.
Would it be a good idea to make this command restore the previous running
configuration in case of a start-failure? (kind of like the
"try-command")

1. Save the currently running iptables configuration to a /tmp file.
(with iptables-save for example)

2. Run the new configuration. (the one in /etc/shorewall)

3. In case of failure or timeout restore the previous firewall from the
/tmp file. (with iptables-restore for example)

I need this because i''m fiddeling around a lot and i don''t
like to use the
try-method every time i need to make a quick change.

I''m going to implement this, any suggestions or tips?
Will it be included in the main version if send out a nice patch?

Edwin

-- 

  //||\\  Edwin Eefting
 || || || DatuX - Linux solutions and innovations
  \\||//  http://www.datux.nl

> Hi,
>
> I was thinking about changing the #shorewall restart command a little bit.
> Would it be a good idea to make this command restore the previous running
> configuration in case of a start-failure? (kind of like the
"try-command")
>
> 1. Save the currently running iptables configuration to a /tmp file.
> (with iptables-save for example)
Sound nice. However, I''m not sure you can really restore everything
with
iptables-save. Maybe it''s enough to be able to fix the config.
I was also thinking some time ago about some caching method which lets
restart very quickly if nothing has changed in the config. This could help
people with lots of rules.
>
> 2. Run the new configuration. (the one in /etc/shorewall)
>
> 3. In case of failure or timeout restore the previous firewall from the
> /tmp file. (with iptables-restore for example)
>
> I need this because i''m fiddeling around a lot and i
don''t like to use the
> try-method every time i need to make a quick change.
>
> I''m going to implement this, any suggestions or tips?
> Will it be included in the main version if send out a nice patch?
>
> Edwin
>
> --
>
>   //||\\  Edwin Eefting
>  || || || DatuX - Linux solutions and innovations
>   \\||//  http://www.datux.nl
>
> _______________________________________________
> Shorewall-devel mailing list
> Shorewall-devel@lists.shorewall.net
> https://lists.shorewall.net/mailman/listinfo/shorewall-devel
>

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]

On Thu, 2 Oct 2003, Simon Matter wrote:
>
> > Hi,
> >
> > I was thinking about changing the #shorewall restart command a little
bit.
> > Would it be a good idea to make this command restore the previous
running
> > configuration in case of a start-failure? (kind of like the
"try-command")
> >
> > 1. Save the currently running iptables configuration to a /tmp file.
> > (with iptables-save for example)
>
> Sound nice. However, I''m not sure you can really restore
everything with
> iptables-save. Maybe it''s enough to be able to fix the config.
I gave some tought to it and tested some stuff. Altough it is possible to
use iptables-restore/backup to restore the firewall rules (tested this,
and only the order of the flags seems to be different), i will use
another method:

After a successfull start the configdir is copied to a backupdirectory.

In case the computer "crashes" (= restart because you can''t
ssh anymore;),
the system will still come up with the backupped version.  In case a
firewall restart fails, or a normal start fails, it will fallover to the
last succesfull firewall start)
> I was also thinking some time ago about some caching method which lets
> restart very quickly if nothing has changed in the config. This could help
> people with lots of rules.
Maybe, but that''s not interesting for me at this moment.

So the plan is changed to this:

1. (re)start shorewall.

2a FAILURE case: try to start the backup version if it exists.
   If this fails as well we stop the firewall. (like it does now)

2b SUCCESS case: backup the configuration directory, in case the
   next (re)start fails.

3. Happy admin, happy users, drink coffee etc.. :D


What do you think about this? Should i add this to my "coding-queue"?
:)

Edwin
> >
> > --
> >
> >   //||\\  Edwin Eefting
> >  || || || DatuX - Linux solutions and innovations
> >   \\||//  http://www.datux.nl
> >
> > _______________________________________________
> > Shorewall-devel mailing list
> > Shorewall-devel@lists.shorewall.net
> > https://lists.shorewall.net/mailman/listinfo/shorewall-devel
> >
>
>
>
-- 

  //||\\  Edwin Eefting
 || || || DatuX - Linux solutions and innovations
  \\||//  http://www.datux.nl

On Thu, 2003-10-02 at 06:55, Simon Matter wrote:
> > Hi,
> >
> > I was thinking about changing the #shorewall restart command a little
bit.
> > Would it be a good idea to make this command restore the previous
running
> > configuration in case of a start-failure? (kind of like the
"try-command")
> >
> > 1. Save the currently running iptables configuration to a /tmp file.
> > (with iptables-save for example)
> 
> Sound nice. However, I''m not sure you can really restore
everything with
> iptables-save. Maybe it''s enough to be able to fix the config.
> I was also thinking some time ago about some caching method which lets
> restart very quickly if nothing has changed in the config. This could help
> people with lots of rules.
This idea came up recently on this list -- the current Shorewall code
requires considerable reorganization to integrate
iptables-save/iptables-restore. As Simon points out, "shorewall
[re]start" does more than just create an iptables configuration:

a) It can add routes. -- My current belief is that this is an
architectural error and that Shorewall should not be in the business of
altering the routing table. Shorewall 2.0 will correct that error but in
the mean time, compatibility must be maintained.

b) It saves context in /var/lib/shorewall in order to be able to handle
subsequent "shorewall add" and "shorewall delete" commands.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 2 Oct 2003, Tom Eastep wrote:
> On Thu, 2003-10-02 at 06:55, Simon Matter wrote:
> > > Hi,
> > >
> > > I was thinking about changing the #shorewall restart command a
little bit.
> > > Would it be a good idea to make this command restore the previous
running
> > > configuration in case of a start-failure? (kind of like the
"try-command")
> > >
> > > 1. Save the currently running iptables configuration to a /tmp
file.
> > > (with iptables-save for example)
> >
> > Sound nice. However, I''m not sure you can really restore
everything with
> > iptables-save. Maybe it''s enough to be able to fix the
config.
> > I was also thinking some time ago about some caching method which lets
> > restart very quickly if nothing has changed in the config. This could
help
> > people with lots of rules.
>
> This idea came up recently on this list -- the current Shorewall code
> requires considerable reorganization to integrate
> iptables-save/iptables-restore. As Simon points out, "shorewall
> [re]start" does more than just create an iptables configuration:
>
> a) It can add routes. -- My current belief is that this is an
> architectural error and that Shorewall should not be in the business of
> altering the routing table. Shorewall 2.0 will correct that error but in
> the mean time, compatibility must be maintained.
>
> b) It saves context in /var/lib/shorewall in order to be able to handle
> subsequent "shorewall add" and "shorewall delete"
commands.
So we wont have this problem with the other method i proposed?
-(re)start firewall.
-Start backuped configuration in case of failure.
-Backup new configuration in case of success.

The advantage is that 3rd party programs like Webmin can just mess around
with /etc/shorewall, while the firewall will always be able to start.
3rd party programs also don''t need any changes or extra''s.
The only difference is the firewall will never stop in case of an error.
>
> -Tom
>
Edwin

-- 

  //||\\  Edwin Eefting
 || || || DatuX - Linux solutions and innovations
  \\||//  http://www.datux.nl

On Thu, 2003-10-02 at 08:43, Edwin Eefting wrote:
> to handle
> > subsequent "shorewall add" and "shorewall delete"
commands.
> 
> So we wont have this problem with the other method i proposed?
> -(re)start firewall.
> -Start backuped configuration in case of failure.
> -Backup new configuration in case of success.
> 
> The advantage is that 3rd party programs like Webmin can just mess around
> with /etc/shorewall, while the firewall will always be able to start.
> 3rd party programs also don''t need any changes or
extra''s.
> The only difference is the firewall will never stop in case of an error.
> 
I suspect that it totally breaks the ''try'' command.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 2 Oct 2003, Tom Eastep wrote:
> On Thu, 2003-10-02 at 08:43, Edwin Eefting wrote:
> >
> > So we wont have this problem with the other method i proposed?
> > -(re)start firewall.
> > -Start backuped configuration in case of failure.
> > -Backup new configuration in case of success.
> >
> > The advantage is that 3rd party programs like Webmin can just mess
around
> > with /etc/shorewall, while the firewall will always be able to start.
> > 3rd party programs also don''t need any changes or
extra''s.
> > The only difference is the firewall will never stop in case of an
error.
> >
>
> I suspect that it totally breaks the ''try'' command.
do we really still need the try command anyway, once this is implemented?
>
> -Tom
>
-- 

  //||\\  Edwin Eefting
 || || || DatuX - Linux solutions and innovations
  \\||//  http://www.datux.nl

On Thu, 2003-10-02 at 09:28, Edwin Eefting wrote:
> On 2 Oct 2003, Tom Eastep wrote:
> 
> > On Thu, 2003-10-02 at 08:43, Edwin Eefting wrote:
> > >
> > > So we wont have this problem with the other method i proposed?
> > > -(re)start firewall.
> > > -Start backuped configuration in case of failure.
> > > -Backup new configuration in case of success.
> > >
> > > The advantage is that 3rd party programs like Webmin can just
mess around
> > > with /etc/shorewall, while the firewall will always be able to
start.
> > > 3rd party programs also don''t need any changes or
extra''s.
> > > The only difference is the firewall will never stop in case of an
error.
> > >
> >
> > I suspect that it totally breaks the ''try'' command.
> 
> do we really still need the try command anyway, once this is implemented?
- Do we really need this given that we have the ''try'' command?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 2 Oct 2003, Tom Eastep wrote:
> On Thu, 2003-10-02 at 09:28, Edwin Eefting wrote:
> > On 2 Oct 2003, Tom Eastep wrote:
> >
> > > On Thu, 2003-10-02 at 08:43, Edwin Eefting wrote:
> > > >
> > > > So we wont have this problem with the other method i
proposed?
> > > > -(re)start firewall.
> > > > -Start backuped configuration in case of failure.
> > > > -Backup new configuration in case of success.
> > > >
> > > > The advantage is that 3rd party programs like Webmin can
just mess around
> > > > with /etc/shorewall, while the firewall will always be able
to start.
> > > > 3rd party programs also don''t need any changes or
extra''s.
> > > > The only difference is the firewall will never stop in case
of an error.
> > > >
> > >
> > > I suspect that it totally breaks the ''try''
command.
> >
> > do we really still need the try command anyway, once this is
implemented?
>
> - Do we really need this given that we have the ''try''
command?
Yes, because the try command requires too much hassle and is error prone.
(it''s explained in the manual page: copy shorewall to shorewall-backup,
try it, when it works copy it back and delete the backup dir again)

This is why i want to do this in the first place. I just want to be able
to fiddle around in the config files, restart the firewall, correct my
errors (in all ease, without 100 people calling me they can''t internet
:),
and restart it again until everything is fixed.

AND i want to be able to let someone else do it with webmin too.

Offcourse i could write a wrapper script, but it would be much nicer if
shorewall supported this by default. (it would be more robust i think)

>
> -Tom
>
-- 

  //||\\  Edwin Eefting
 || || || DatuX - Linux solutions and innovations
  \\||//  http://www.datux.nl

On Thu, 2003-10-02 at 09:48, Edwin Eefting wrote:
> >
> > - Do we really need this given that we have the
''try'' command?
> 
> Yes, because the try command requires too much hassle and is error prone.
> (it''s explained in the manual page: copy shorewall to
shorewall-backup,
> try it, when it works copy it back and delete the backup dir again)
> 
> This is why i want to do this in the first place. I just want to be able
> to fiddle around in the config files, restart the firewall, correct my
> errors (in all ease, without 100 people calling me they can''t
internet :),
> and restart it again until everything is fixed.
All of which you can do currently. And today, you have explicit control
over when you "commit" a test configuration to production; it
doesn''t
happen automatically just because [re]start didn''t blow up.
> 
> AND i want to be able to let someone else do it with webmin too.
One way to do that would be to provide alternate configuration support
in Webmin (along with support for the Try command).
> 
> Offcourse i could write a wrapper script, but it would be much nicer if
> shorewall supported this by default. (it would be more robust i think)
> 
I''m not so sure. Trying to document this sounds like a nightmare
(remember that we have to retain the current documentation for folks
that aren''t running a version that contains this alternate support).

And I will NOT accept just a patch to the code where I have to do the
documentation update myself.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 2 Oct 2003, Tom Eastep wrote:
> On Thu, 2003-10-02 at 09:48, Edwin Eefting wrote:
>
> > >
> > > - Do we really need this given that we have the
''try'' command?
> >
> > Yes, because the try command requires too much hassle and is error
prone.
> > (it''s explained in the manual page: copy shorewall to
shorewall-backup,
> > try it, when it works copy it back and delete the backup dir again)
> >
> > This is why i want to do this in the first place. I just want to be
able
> > to fiddle around in the config files, restart the firewall, correct my
> > errors (in all ease, without 100 people calling me they can''t
internet :),
> > and restart it again until everything is fixed.
>
> All of which you can do currently. And today, you have explicit control
> over when you "commit" a test configuration to production; it
doesn''t
> happen automatically just because [re]start didn''t blow up.
>
> >
> > AND i want to be able to let someone else do it with webmin too.
>
> One way to do that would be to provide alternate configuration support
> in Webmin (along with support for the Try command).
>
> >
> > Offcourse i could write a wrapper script, but it would be much nicer
if
> > shorewall supported this by default. (it would be more robust i think)
> >
>
> I''m not so sure. Trying to document this sounds like a nightmare
> (remember that we have to retain the current documentation for folks
> that aren''t running a version that contains this alternate
support).
>
> And I will NOT accept just a patch to the code where I have to do the
> documentation update myself.
hmm i will look into it in a few days (when i finally have time again). i
probably will create a wrapper script and if necesary modify shorewall so
taht it returns a exit code on a failure of try or (re)start.

i''m off to bed first :)
>
> -Tom
>
-- 

  //||\\  Edwin Eefting
 || || || DatuX - Linux solutions and innovations
  \\||//  http://www.datux.nl