Check the archives,
a post was mde saying that it was explicitly not the right way to do it
in rc.local...
Hence my comment
P.
Bryan J. Smith wrote:
>Peter Farrow <peter@xxxxxxxxxxx> wrote:
>
>
>>Rc.local is used explicitly for the running of scripts
>>after the system has booted.
>>
>>
>
>And most other Linux/UNIX implementations offer such as well.
> (some use a S99local symlink for the run-level so you can
>turn it off).
>
>However, I still prefer a dedicated script in /etc/init.d/
>instead of /etc/rc.d/rc.local with start|stop|status|etc...
>
>If you want, you can have that replace iptables (disable the
>iptables). In some cases, I do that. In other cases, I have
>my init.d script call the iptables to flush/reload/etc... as
>appropriate. I try to accomodate any set of changes.
>
>
>
>>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.
>>
>>
>
>Unfortunately, that doesn't address this issue if someone
>modifies iptables and your changes in rc.local don't address
>those (i.e., conflict) any better than "save" or an
>additional /etc/init.d/ script.
>
>Additionally, Which I _always_ run this command whenever I
>modify _anything_ in /etc:
> ci -l (file)
>
>E.g.,
> cd /etc/sysconfig/
> [ ! -d RCS ] && mkdir RCS (<-- optional)
> ci -l iptables
>
>Now if anything changes the rules, I can run:
> rcsdiff iptables
>
>And know about it.
>
>This is how I catch 95% of my client's admins who say "oh, I
>didn't modify anything." Sure enough, when I show them the
>_exact_changes_ -- line-by-line -- they instantly confess.
>
>I'd saved my butt countless times. E.g., Windows/Exchange
>admins who complain about DNS NS or MX records in our domain,
>and accuse me of changing things. I can show every single
>modification over months at a client by always remembering to
>RCS check-in my files.
>
>In the end, it's really a matter of discipline, _regardless_
>of how you do it. No way is better than another -- although
>having exact diffs of any changes at least shows you the
>changes.
>
>[ In fact, I sure wish RPM upgrades would run an RCS check-in
>instead of renaming configuration files as .rpmnew and
>.rpmsave. ]
>
>
>
>>Having it visible in rc.local makes it easily viewable to
>>see if its been changed.
>>
>>
>
>And using RCS check-ins gives you much greater detail,
>regardless of what script you pick.
>
>
>
>>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.
>>
>>
>
>And creating your own /etc/init.d/ script would do the same
>as well -- another advantage over /etc/rc.d/rc.local.
>
>If you haven't noticed, I'm not advocating that you "have to
>use" the "save" parameter to the "iptables" script (which
>saves to /etc/sysconfig/iptables/). I'm merely saying it's
>best to use the /etc/init.d/ facilities -- be it the stock
>iptables script, or your own in conjuction or replacement of
>it.
>
>I really try to avoid the "free for all" and "always at the
>end" /etc/rc.d/rc.local -- except for maybe temporary,
>boot-time debugging/resolution.
>
>
>
>>To say that putting in rc.local is "not right" is really a
>>bit misguided... :-)
>>
>>
>
>I do _not_ think I _ever_ said that, nor did anyone else
>(I'll have to go back through the archives to check others).
>
>In fact, until this post, I don't think I said I even avoided
>/etc/rc.d/rc.local. If I'm going to do things more than
>once, I like to create /etc/init.d/ scripts.
>
>Of course, I'm anal on LSB too (I guess that started once I
>got involved with LPI's exam writing events ;-).
>
>
>
>>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"
>>
>>
>
>Not only do I agree with you, but I cited that exact point in
>my post:
>http://lists.centos.org/pipermail/centos/2005-November/014223.html
>
> 'If I have to do more complex things, I then write my own
> init script -- something that typically calls iptables
> after a flush of any tables so I start with "Red Hat's
> settings" before modifying them ...
> ... With some monitoring scripts, I bring up and take
> down all sorts of rules regularly by flushing, reloading
> and then running iptables and iproute2 commands. The
> only 2 scripts -- in addition to the resident Perl
> script -- I use are the Red Hat iptables (initially
> setup and then "saved") and then my own "meshrouter"
> (it is a continually self-healing mesh network, so this
> is run and it modifies all sorts of things when faults
> are detected) scripts.'
>
>Once again, I'll point out that creating a /etc/init.d/
>script is far more flexible. You can put conditional
>parameters, and reload, restart, statuc, etc... -- unlike
>putting something in /etc/rc.d/rc.local.
>
>And, lastly, I cannot emphasize using RCS liberally on
>anything in /etc/. You don't have to setup a repository,
>just run "ci -l filename" and you've got a local ",v"
>(versions) file. Just do it everything you modify something
>-- sometimes before (the check-in will tell you whether or
>not it's been modified since your last check-in).
>
>
>
>
