Peter Farrow peter@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
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).