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).
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
