Putting nat routing into place permanently? -- /etc/rc.d/rc.local v. /etc/init.d/custom scripts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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)

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux