[CentOS] Putting nat routing into place permanently? --
/etc/rc.d/rc.local v. /etc/init.d/custom scripts
Bryan J. Smith
thebs413 at earthlink.net
Thu Nov 3 15:22:49 UTC 2005
Peter Farrow <peter at farrows.org> 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
> the "service iptables save" some one either inadvertantly
> otherwise may modify the iptables and re-issue a "service
> iptables save" and have it reloaded at boot quite
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)
[ ! -d RCS ] && mkdir RCS (<-- optional)
ci -l iptables
Now if anything changes the rules, I can run:
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
[ In fact, I sure wish RPM upgrades would run an RCS check-in
instead of renaming configuration files as .rpmnew and
> 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
I really try to avoid the "free for all" and "always at the
end" /etc/rc.d/rc.local -- except for maybe temporary,
> 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
'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).
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith at ieee.org | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
More information about the CentOS