Peter Kjellstr?m wrote:
> It will work but it's not the "right" way and it's not
> pretty. I say go for Brian J Smiths approach in the
> previous e-mail.
Just know I'm not a "my way dammit" type of guy. Whatever
works is whatever works. Although if you work for me, or I'm
a consultant at your firm, you'll get the baseball bat if
your supervisors are paying me to tell you how to do things.
;-> Because in the majority of those cases, they are also
paying for Red Hat support as well (and we want to minimize
any number and/or complications with those).
The reason is that *I* (and I want the companies I consult
for) try to learn the vendor's supported way. That way I
send Red Hat 1 file to Red Hat and they don't have to worry
or second-guess where other rules might be written. I.e., in
a nutshell, I've got "bitten in the @$$" when I've put rules
in rc.sysinit or rc.local or in some odd /usr/local/sbin
script because I missed them.
And if I do end up having to enable/disable things more on a
whim, I _always_ create a proper /etc/init.d
start|stop|status script (and avoid modifying /etc/rc.d/rc.*
scripts in general). That way I can quickly see if anything
else might be modifying something. I do this all-the-time
with iptables/iproute2 rules to enable static routes,
SNAT/DNAT, etc...
Especially with the NetFilter stack (modified by iptables,
iproute2, etc...). Those settings are the most likely to
cause a network service to not work correctly. Anytime those
rules are modified, I want a script that can disable/reverse
anything that might have been done.
Preston Crawford wrote:
> Yeah. Makes sense. That's why I asked for the "canonical"
> way of doing it. I'll take "what works", but I prefer to do
> it the "right" way.
The great thing about the "service iptables save" (or
"/etc/init.d/iptables save") command. If you get something
that works, you can run that command and it'll save it for
the next time. Still inspect the /etc/sysconfig/iptables
script afterwards to make sure the rules are correct (they
will be subsets of the full iptables line). But for the most
part, they work just fine for myself.
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.
-- Bryan
P.S. To give you an idea where I'm coming from on my
viewpoints, at my current employer, we are routing over both
local and satellite links to disaster areas. We have
eliminated a lot of Cisco and other equipment, and replaced
things with a single 7"x7"x2.7" Mini-ITX box (soon to be a
much smaller NEMA4X enclosure with a much smaller SBC -- x86
first, XScale in the near-future), because we're only routing
1.5-6Mbps (easily handled). 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.
If you were glued to the TV during the Katrina hurricanes and
saw the (407) (Orlando) or (813) (Tampa) area code phone
number to call to find out about relatives -- that was my
small company's work. They were IP communications equipment
deployed over a mesh network setup in minutes up to a
satellite uplink -- all controlled by *1* Linux box with my
scripts (and other capabilities). We're normally not into
the business of providing the actual disaster services --
we're more interested in selling our stuff to others to do
such. But since we're the only company with the proven
capabilities (something we proved after Charlie, which hit
even my house last year), we're the ones FEMA and the Coast
Guard look to at a moments notice.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
