Furhtermore, some of my firewall scripts have conditions in them, which
change the behaviour of the firewall when it runs depending on certain
external criteria, can't see that happening in "service iptables save"
Peter Farrow wrote:
> Rc.local is used explicitly for the running of scripts after the
> system has booted.
>
> Putting your own firewall scripts in here is a good place to put them
> rather than relying on "service iptables save", this is because the
> visibility of changes is poor when using the "service iptables save"
> some one either inadvertantly or otherwise may modify the iptables and
> re-issue a "service iptables save" and have it reloaded at boot quite
> transparently.
>
> Having it visible in rc.local makes it easily viewable to see if its
> been changed.
>
> I would not trust any system hosted on the net with the rather open
> ended "service iptables save". The only benefit that this offers is
> that it brings the filewall up early on in the boot process, meaning
> at boot time the machine is protected sooner.
>
> To say that putting in rc.local is "not right" is really a bit
> misguided...
>
> :-)
>
>
>
> Bryan J. Smith wrote:
>
>> Preston Crawford <me@xxxxxxxxxxxxxxxxxxx> wrote:
>>
>>
>>> Okay, here you lost me. Are you saying we run
>>> /etc/sysconfig/iptables at boot for the various runlevels?
>>>
>>
>>
>> Er, /etc/init.d/iptables (which will use
>> /etc/sysconfig/iptables) at the various boot-levels, yes.
>> E.g.,
>> # chkconfig --level 2345 iptables on
>>
>> /etc/sysconfig/iptables is not a directly executable script,
>> it's a config file with pseudo (and quite incomplete)
>> iptables lines and other info.
>>
>> It is written (from the rules in memory) when you run:
>> # sysconfig iptables save
>>
>>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
