My shorewall init script has a conditional block on $COMMAND = start and
it wipes out all my existing ipsets (flushes them first) with 'ipset -F'
and 'ipset -X' and then reloads them from a predefined script.
That's all well and good, but when I do 'service shorewall reload' it
does not pass 'r
Hi,
I read the shorewall man page regarding the "reload" and "restart" commands.
From a practical point of view and with default shorewall.conf settings in 5.1,
if I change/add/delete entries in the "rules" file, and issue the "reload"
command then I should expect the following:
- existing con
On 9/29/10 4:07 PM, Mr Dash Four wrote:
> My shorewall init script has a conditional block on $COMMAND = start and
> it wipes out all my existing ipsets (flushes them first) with 'ipset -F'
> and 'ipset -X' and then reloads them from a predefined script.
>
> That's all well and good, but when I
> What do you mean by 'init script'? Do you mean /etc/init.d/shorewall or
> do you mean /etc/shorewall/init?
>
/etc/shorewall/init (it relies on "$COMMAND" = start to do its job)
--
Start uncovering the many advantages
On 9/29/10 4:29 PM, Mr Dash Four wrote:
>
>> What do you mean by 'init script'? Do you mean /etc/init.d/shorewall or
>> do you mean /etc/shorewall/init?
>>
> /etc/shorewall/init (it relies on "$COMMAND" = start to do its job)
Then is sounds like /etc/init.d/shorewall is generating '/sbin/shore
> Then is sounds like /etc/init.d/shorewall is generating '/sbin/shorewall
> stop; /sbin/shorewall start' for the 'reload' command. So
> /etc/shorewall/init will be invoked twice; once with $COMMAND=stop and
> once with $COMMAND=start. That's the way it works and there is nothing
> to 'fix'.
>
On 9/29/10 4:52 PM, Mr Dash Four wrote:
>
>> Then is sounds like /etc/init.d/shorewall is generating '/sbin/shorewall
>> stop; /sbin/shorewall start' for the 'reload' command. So
>> /etc/shorewall/init will be invoked twice; once with $COMMAND=stop and
>> once with $COMMAND=start. That's the way i
On 9/29/10 5:09 PM, Tom Eastep wrote:
> I have no idea what's going on on your system.
>
> gateway:~# cat /etc/shorewall/init
> #
> # Shorewall version 4 - Init File
> #
> # /etc/shorewall/init
> #
> # Add commands below that you want to be executed at the beginning of
> # a "shorewall st
> I have no idea what's going on on your system.
>
This is all very strange. After being able to reload shorewall a couple
of times (with NO errors, i.e. shorewall executing as it should), I
changed my rules file a couple of times, then loaded a few ipsets I
needed to test (see below) and am
On 9/29/10 5:52 PM, Mr Dash Four wrote:
>
>> I have no idea what's going on on your system.
>>
> This is all very strange. After being able to reload shorewall a couple
> of times (with NO errors, i.e. shorewall executing as it should), I
> changed my rules file a couple of times, then loaded
>> Shorewall stopped. <===
>>
>
> At this point, Shorewall was stopped! That causes init to be invoked
> with $COMMAND=stop
>
Ah, I see! So, if there is any error in my config files (rules, secmarks
etc) running Shorewall gives up and stops and when I then execute
'service shorewall
On 9/30/10 10:44 AM, Mr Dash Four wrote:
>
>>> Shorewall stopped. <===
>>>
>>
>> At this point, Shorewall was stopped! That causes init to be invoked
>> with $COMMAND=stop
>>
> Ah, I see! So, if there is any error in my config files (rules, secmarks
> etc) running Shorewall gives up a
> man shorewall and look for 'safe-restart'.
>
shorewall safe-restart it is then, except, is there a way I could get
away with the prompt and let shorewall decide if there were no errors to
assume the new configuration, but if there were to automatically restore
the old one (i.e. bypass the
On 9/30/10 11:50 AM, Mr Dash Four wrote:
>
>> man shorewall and look for 'safe-restart'.
>>
> shorewall safe-restart it is then, except, is there a way I could get
> away with the prompt and let shorewall decide if there were no
> errors to assume the new configuration, but if there were to
> au
> shorewall save
> shorewall restart
>
That, to me, seems the best alternative and I amended my init.d script
to replace the existing reload with the above two statements. It works
and I like it.
--
Start uncovering
On 08/09/2017 12:56 AM, Vieri Di Paola via Shorewall-users wrote:
> Hi,
>
> I read the shorewall man page regarding the "reload" and "restart" commands.
> From a practical point of view and with default shorewall.conf settings in
> 5.1, if I change/add/delete entries in the "rules" file, and iss
I'm asking because I'm seeing two issues with the restart command when trying
to move from shorewall 5.0.14.1 to a more recent version (eg. 5.1.5.1).
According to
http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.14/releasenotes.txt,
the "restart" option should behave the same way. So, i
On 08/10/2017 01:07 AM, Vieri Di Paola via Shorewall-users wrote:
> I'm asking because I'm seeing two issues with the restart command when trying
> to move from shorewall 5.0.14.1 to a more recent version (eg. 5.1.5.1).
>
> According to
> http://www.shorewall.net/pub/shorewall/5.0/shorewall-5.0.
From: Tom Eastep
> In both 'restart' and 'reload', the provider routing tables and rules> are
> purged then reloaded. But they were purged and reloaded on 5.0 as well.
OK, but since 5.0 had OPTIMIZE=0 the "cut" was almost gone unnoticed.
I'd like to keep OPTIM
On 08/10/2017 09:21 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> From: Tom Eastep
>
>> In both 'restart' and 'reload', the provider routing tables and rules> are
>> purged then reloaded. But they were purged and reloaded on 5.0 as well.
>
>
> OK, but si
From: Tom Eastep
>
> The stopped state is NOT longer in 5.1. The compilation step is longer,
> but the time to run the script once it is compiled should be very close
> to the same.
OK, I don't know why I was previously getting such a long connection outage
whil
On 08/11/2017 01:13 AM, Vieri Di Paola via Shorewall-users wrote:
>
> From: Tom Eastep
>>
>> The stopped state is NOT longer in 5.1. The compilation step is longer,
>
>> but the time to run the script once it is compiled should be very close
>> to the same.
>
> O
From: Tom Eastep
>
> So why don't you simply leave that route in place all of the time? Just
> define it in your distribution's networking config.
I'm used to using rtrules, routes, and providers with shorewall. I share those
files with other members of the IT
On 08/11/2017 10:31 AM, Vieri Di Paola via Shorewall-users wrote:
>
>
> From: Tom Eastep
>>
>> So why don't you simply leave that route in place all of the time? Just
>
>> define it in your distribution's networking config.
>
> I'm used to using rtrules, routes,
24 matches
Mail list logo