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]



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).
>
>
>  
>


[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