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