[asterisk-biz] 87.230.80.186 - Trying to register

[James Sharp]

Steve Edwards wrote:
> On Tue, 29 Jun 2010, James Sharp wrote:
> 
>> Or make your changes to the iptables config file, then run:
>>
>> /etc/init.d/iptables restart; sleep 15; /etc/init.d/iptables stop
>>
>> The crontab trick is neat, but you can set yourself up with some 
>> possible race conditions.
> 
> Ahh, Unix -- always more than 1 way to skin a cat. Now how to choose?
> 
> What race conditions have you encountered?

Well, maybe not a race condition exactly but..

Imagine that you commit your foot-shooting changes a split second before
your crontab fires off.  Your session will stall for a moment or two
(maybe) before the firewall drops again and you'll never notice.  You
remove the crontab entry thinking you've got good rules, then when your
box gets bounced for whatever reason, you've locked yourself out.

Sure, you can always make sure you commit your rules a fair time away
from */5, but I don't like software messing with what I'm doing.

> 
> I like your trick and I'm sure I'll use it at some point in the future. It 
> does have 2 weaknesses though:
> 
> 1) If you miss-type the "stop" command, you may not find out until it's 
> too late. The "crontab" method has the advantage that you can keep it 
> "commented out" in root's crontab so you never have to type the command 
> again. (I use this so often that my "create crontabs" script puts it in 
> for me.)
> 
> 2) If the new iptables rules cause your ssh session to "die" you're toast. 
> Since the "crontab" method is scheduled as a separate process, it is not 
> dependent on your session.
> 

True.  But you could run everything as "nohup" to eliminate that.

nohup /etc/init.d/iptables restart; nohup sleep 15; nohup
/etc/init.d/iptables stop