What's the canonical way to do this in CentOS/RHEL? I know how to do it from the command line, but how to do I make a NAT route permanent?
Preston
Preston Crawford wrote:
What's the canonical way to do this in CentOS/RHEL? I know how to do it from the command line, but how to do I make a NAT route permanent?
Tom Brown tom.brown@goodtechnology.com wrote:
rc.local ?
Actually, for newer kernel 2.4+ Fedora-based distros (including CentOS 3+), it's recommended you use the "service iptables save" (or "/etc/init.d/iptables save").
It basically parses the currently configured tables in the kernel and outputs them (in short-hand form) to the configuration file /etc/sysconfig/iptables.
Then configure the iptables script to start at boot for run-levels 2+. FYI, I'm not sure what happens to any "saved changes" if you re-configure /etc/sysconfig/iptables from the "Firewall Setup" though. So do that with care.
On Tue, 2005-11-01 at 08:38 -0800, Bryan J. Smith wrote:
Preston Crawford wrote:
What's the canonical way to do this in CentOS/RHEL? I know how to do it from the command line, but how to do I make a NAT route permanent?
Tom Brown tom.brown@goodtechnology.com wrote:
rc.local ?
Actually, for newer kernel 2.4+ Fedora-based distros (including CentOS 3+), it's recommended you use the "service iptables save" (or "/etc/init.d/iptables save").
Oh, interesting.
It basically parses the currently configured tables in the kernel and outputs them (in short-hand form) to the configuration file /etc/sysconfig/iptables.
Okay.
Then configure the iptables script to start at boot for run-levels 2+. FYI, I'm not sure what happens to any "saved
Okay, here you lost me. Are you saying we run /etc/sysconfig/iptables at boot for the various runlevels?
changes" if you re-configure /etc/sysconfig/iptables from the "Firewall Setup" though. So do that with care.
Okay. Thanks.
Preston
Preston Crawford me@prestoncrawford.com wrote:
Okay, here you lost me. Are you saying we run /etc/sysconfig/iptables at boot for the various runlevels?
Er, /etc/init.d/iptables (which will use /etc/sysconfig/iptables) at the various boot-levels, yes. E.g., # chkconfig --level 2345 iptables on
/etc/sysconfig/iptables is not a directly executable script, it's a config file with pseudo (and quite incomplete) iptables lines and other info.
It is written (from the rules in memory) when you run: # sysconfig iptables save
On Tue, 2005-11-01 at 09:18 -0800, Bryan J. Smith wrote:
Preston Crawford me@prestoncrawford.com wrote:
Okay, here you lost me. Are you saying we run /etc/sysconfig/iptables at boot for the various runlevels?
Er, /etc/init.d/iptables (which will use /etc/sysconfig/iptables) at the various boot-levels, yes. E.g., # chkconfig --level 2345 iptables on
/etc/sysconfig/iptables is not a directly executable script, it's a config file with pseudo (and quite incomplete) iptables lines and other info.
It is written (from the rules in memory) when you run: # sysconfig iptables save
Duh, I didn't read it right (missed the /etc) part. Thanks.
Preston
Preston Crawford me@prestoncrawford.com wrote:
Duh, I didn't read it right (missed the /etc) part. Thanks.
I'm not known for my clarity in explaining things in e-mail, I'll readily admit that.
Rc.local is used explicitly for the running of scripts after the system has booted.
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.
Having it visible in rc.local makes it easily viewable to see if its been changed.
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.
To say that putting in rc.local is "not right" is really a bit misguided...
:-)
Bryan J. Smith wrote:
Preston Crawford me@prestoncrawford.com wrote:
Okay, here you lost me. Are you saying we run /etc/sysconfig/iptables at boot for the various runlevels?
Er, /etc/init.d/iptables (which will use /etc/sysconfig/iptables) at the various boot-levels, yes. E.g., # chkconfig --level 2345 iptables on
/etc/sysconfig/iptables is not a directly executable script, it's a config file with pseudo (and quite incomplete) iptables lines and other info.
It is written (from the rules in memory) when you run: # sysconfig iptables save
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"
Peter Farrow wrote:
Rc.local is used explicitly for the running of scripts after the system has booted.
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.
Having it visible in rc.local makes it easily viewable to see if its been changed.
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.
To say that putting in rc.local is "not right" is really a bit misguided...
:-)
Bryan J. Smith wrote:
Preston Crawford me@prestoncrawford.com wrote:
Okay, here you lost me. Are you saying we run /etc/sysconfig/iptables at boot for the various runlevels?
Er, /etc/init.d/iptables (which will use /etc/sysconfig/iptables) at the various boot-levels, yes. E.g., # chkconfig --level 2345 iptables on
/etc/sysconfig/iptables is not a directly executable script, it's a config file with pseudo (and quite incomplete) iptables lines and other info.
It is written (from the rules in memory) when you run: # sysconfig iptables save
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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).
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@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).
Peter Farrow peter@farrows.org wrote:
Check the archives, a post was mde saying that it was explicitly not the right way to do it in rc.local...
This is why I hate e-mail. There's no tone so the slight difference in phrase makes all the difference, and can be taken entirely the wrong way.
There is a different between someone saying 'not right' and someone saying 'It will work but it's not the "right" way'
I think everyone tipped-toe'd and did their best to avoid saying it was 'not right', because that was not the focus of the discussion.
I merely offered my experience on what Red Hat offers, what I do and, just today, what things an /etc/init.d/ script offers over just putting lines in /etc/rc.d/rc.local.
I also added the fact that using some sort of version control (RCS is simple, requires 0 setup, and it just works) is the only way to guarantee things won't get changed without your knowing.
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.
I'm hoping this doesn't get nit-picky and petty. I asked for the canonical way to do it. Interpret this as you wish. I see that to mean, "how would a Red Hat engineer put that into place". I got my answer, I believe. This debate about alternatives is great, but there's no need for anyone to get snippy.
Preston
I'm Not getting snippy,
Brian denied quite definately that no such comment was posted, I merely point out to him that such a comment was made, as he seemed not to have noticed it while compiling a "war and peace" style reply of epic proportions.... ;-)
P.
Preston Crawford wrote:
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.
I'm hoping this doesn't get nit-picky and petty. I asked for the canonical way to do it. Interpret this as you wish. I see that to mean, "how would a Red Hat engineer put that into place". I got my answer, I believe. This debate about alternatives is great, but there's no need for anyone to get snippy.
Preston
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, 2005-11-07 at 10:33 +0000, Peter Farrow wrote:
Brian denied quite definately that no such comment was posted, I merely point out to him that such a comment was made,
Okay, now I've gotta agree with Preston, you're getting "nit-picky and petty."
Once again, there is a huge difference between the phrases "not right" (what you thought was said) and "right way" (which was the only thing said by someone else very early in the thread). Please recognize that.
as he seemed not to have noticed it while compiling a "war and peace" style reply of epic proportions.... ;-)
Don't bother demonizing what I said. Furthermore, I think you, like some people before, have managed to point this solely on me now. Maybe it's because I've posted the most, and that's fine. But don't single me out like you are.
I think I've been both _neutral_ and _in-depth_ on this thread on the "why's" -- you are free to do what you wish, no one will debate you on that. But some of us do not agree /etc/rc.d/rc.local is the place to put our iptables/iproute2/etc... commands, and we like to use either the /etc/init.d/iptables (with save option) script, and/or another /etc/init.d/ script.
That's all. If you still want to single me out in this thread, fine. But I now think it is as Preston said, "nit-picky and petty."
I'm Not getting snippy,
Brian denied quite definately that no such comment was posted, I merely point out to him that such a comment was made, as he seemed not to have noticed it while compiling a "war and peace" style reply of epic proportions.... ;-)
P.
:-)
Fair enough. I hear you on the "war and peace" reply.
Preston
On Thu, 2005-11-03 at 07:32, Peter Farrow wrote:
Rc.local is used explicitly for the running of scripts after the system has booted.
It is used as a catchall for things that don't have more explicit scripts using the runlevel mechanism.
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.
I don't follow how using the standard mechanism makes something less visible, or why anyone would think to look in rc.local instead of the usual place.
Having it visible in rc.local makes it easily viewable to see if its been changed.
Compared to??
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.
That's a reasonable point, but if you want to address it you might suggest a different init script linked to the right places in the runlevel directories. Someone might find it there...
To say that putting in rc.local is "not right" is really a bit misguided...
It's not the right place for things that need to be adjusted on runlevel changes, although it can be used as a quick fix for not having a proper init script.
On Thu, 2005-11-03 at 13:02 -0600, Les Mikesell wrote:
On Thu, 2005-11-03 at 07:32, Peter Farrow wrote:
Rc.local is used explicitly for the running of scripts after the system has booted.
<snip>
It's not the right place for things that need to be adjusted on runlevel changes, although it can be used as a quick fix for not having a proper init script.
Philosophically, I agree. *However*, we should keep in mind that the original provision of that script was to keep local sysadmins (and others) from having to monkey with the standard "supported" stuff. *If* that purpose is *still* it's primary reason for being, then it is still a *preferred* method if your POV is from a support aspect (that is, e.g. RH supporting site admins).
From rom *that* POV, rc.local is *probably* more visible if changed as the RH (e.g.) engineer will be expecting to find local changes in there and (probably?) object to having local scripts injected into "his" directory (s).
This is probably moot since the community overall disregards these considerations unless they are spending money for support.
"William L. Maltby" BillsCentOS@triad.rr.com wrote:
Philosophically, I agree. *However*, we should keep in mind that the original provision of that script was to keep
local
sysadmins (and others) from having to monkey with the standard "supported" stuff.
Not true.
In fact, it's very supported to drop in scripts into /etc/init.d/, and countless other directories under /etc -- such as the system crontabs, etc... The whole reason for the "directory" design is to make it easy for the packaging system to be add/remove scripts for different pieces of software, instead of modifying pre-existing files.
E.g., a great example of that comes up here regularly is the /etc/yum.repos.d, instead of modifying the stock yum configuration/repo files.
*If* that purpose is *still* it's primary reason for being, then it is still a *preferred* method if your POV is from a support aspect (that is, e.g. RH supporting site admins).
Again, in dealing with Red Hat support myself, I have to disagree.
From rom *that* POV, rc.local is *probably* more visible if changed as the RH (e.g.) engineer will be expecting to find local changes in there and (probably?) object to having local scripts injected into "his" directory(s).
Considering the recommended approach for any 3rd party software package is to leverage such directories where files can be added, instead of modifying existing files, the a site admin who does that "proper" is not doing anything "wrong."
This is probably moot since the community overall disregards these considerations unless they are spending money for support.
Well, I think we've gotten well away from the recommendation that you try to use "service iptables save" to now debating /etc/init.d/(customscript) v. /etc/rc.d/rc.local.
-- Bryan
P.S. Non-Red Hat note -- also remember that /etc/rc.d/rc.local is _not_ LSB last time I checked. Several distros (and even non-Linux releases, such as Solaris) define a /etc/rc#.d/S99local instead, and I think that's what Red Hat now does too (starting with what distro release?), which then points at the "local" for their implementation (/etc/rc.d/rc.local, being the legacy for Red Hat). So one might argue that "/etc/rc#.d/S99local" is the script. But now I'm just being anal. @-ppp
On Thu, 2005-11-03 at 16:08 -0800, Bryan J. Smith wrote:
"William L. Maltby" BillsCentOS@triad.rr.com wrote:
Philosophically, I agree. *However*, we should keep in mind that the original provision of that script was to keep
local
sysadmins (and others) from having to monkey with the standard "supported" stuff.
Not true.
Please note the word "original". If you research back to the epoch or thereabouts, you may find that I spoke the truth. I began working on UNIX PWB Versions 6/7. There was no "local" then. No symlinks, etc. Later, (with SCO?) I saw rc.local appear. And its purpose was as I stated. I can't recall if/when it all appeared in System III/IV/V. There were a couple different versions of directory structures too.
I don't consider myself qualified to *know* the purpose and/or intent of current developers/maintainers. That's why my subsequent statements were qualified with "if".
Anyway, I do appreciate you bringing me "up to snuff" regarding current intent, purpose and attitudes.
Thanks for taking the time.
I do have 1 question regarding your information. You mention that the directories are intended for packages to use.... but you don't mention the sorts of things that started this thread, "local" changes other than packages. If the OP was to use a script to do the mentioned firewall changes, and his script is locally generated (not part of a package), is it still intended that the script be stuck in the directories as if it were just another package? Or would that be better invoked (directly or indirectly) via the rc.local script?
<snip>
-- Bryan
P.S. Non-Red Hat note -- also remember that /etc/rc.d/rc.local is _not_ LSB last time I checked. Several distros (and even non-Linux releases, such as Solaris) define a /etc/rc#.d/S99local instead, and I think that's what Red Hat now does too (starting with what distro release?), which then points at the "local" for their implementation (/etc/rc.d/rc.local, being the legacy for Red Hat). So one might argue that "/etc/rc#.d/S99local" is the script. But now I'm just being anal. @-ppp
And so it continues ...
"William L. Maltby" BillsCentOS@triad.rr.com wrote:
Please note the word "original".
I'm talking System-V systems (post-1986 AT&T standardization efforts), which is what nearly all major distros -- including the LSB -- are today.
If you research back to the epoch or thereabouts, you may find that I spoke the truth.
Of course because that pre-dates the System-V init approach, which was largely the post-1986 change thanx to AT&T's standardization efforts after their lawsuit against Berkeley.
I began working on UNIX PWB Versions 6/7.
And I began on SunOS 3 and most BSD-like flavors in the late '80s. Forgive me for not starting sooner, I was only 15 at the time, and had to sneak out to my local university to get some "play time" as a imposing hostmaster/postermaster -- until I finally got my first "real" UNIX IT position at age 18 (while going to college full-time). My original Internic handled (pre-IEEE alias which I started using in 1994 when I was an upperclassman in an EE program and could be an IEEE member) ended with the numbers "12". ;->
[ I know I'm now going to hear from "select people" that I'm "flaunting my resume" again. Sigh. ]
There was no "local" then.
There was one big rc script, yes. BSD systems are still largely this approach (and any System-V init is typically under /usr/local/etc/init.d/). Some people would call other scripts from that rc script -- rc.local became a common one.
No symlinks, etc.
No SysV init run-levels at all, I know. ;->
You had one big rc script, maybe a few others getting called.
Later, (with SCO?)
SCO was merely one of many vendors that signed up for AT&T System-V standardization after the start of UCB litigation. Digital Ultrix gave way to Digital UNIX(R) (now Tru64), SunOS gave way to Solaris 2 (SunOS 5, with SunOS 4.1 being retroactively called Solaris 1), etc...
I saw rc.local appear. And its purpose was as I stated. I can't recall if/when it all appeared in System III/IV/V. There were a couple different versions of directory structures too.
Yes. First there was the rc, then the rc#.d, while others still put things in the rc, or an rc.local. Others yet had a rc.init, rc.system or rc.sysinit, etc... Several flavors even have a system-level run-level that runs before the actual run-level with a directory called rcS.d. Solaris, SuSE and several other flavors have it, and it's recognized as valid in LSB. Red Hat chooses the rc.sysinit file instead.
I don't consider myself qualified to *know* the purpose and/or intent of current developers/maintainers.
Linux Standard Base (LSB) is always a great start: http://refspecs.freestandards.org/LSB_2.0.1/LSB-generic/LSB-generic/tocsysin...
It should be noted that Red Hat does not have inter-service dependency checking, unlike SuSE and others -- which can be a major issue. Red Hat is actually developing a next-gen service initialization engine, much like Solaris already has, while still being LSB/legacy SysVinit compatible.
That's why my subsequent statements were qualified with "if".
It's all a matter of perspective with "if" let alone "original." Very early on, UNIX wasn't even written in C. ;->
Anyway, I do appreciate you bringing me "up to snuff" regarding current intent, purpose and attitudes. Thanks for taking the time.
I'm sure I'm getting on the nerves of many. That's why it's probably best I discuss these things off-list, even if some value the information I can provide (they are typically the minority).
I do have 1 question regarding your information. You mention that the directories are intended for packages to use.... but you don't mention the sorts of things that started this thread,
This thread has gone off on many tangents -- hence why I added the "[OT]" tag.
"local" changes other than packages.
If you are making a quick change, then rc.local is commonly used. But if you are making a change that is longer-term, it's better to follow the distro practices, including what a package might drop in. Just an observation -- I apologize if my explanation has gone too far off the tangent.
Remeber, I recommend the "service iptables save" (/etc/init.d/iptables save), including the admission that it could be changed by other programs, so be careful. Since then, I've discussed about adding new scripts to /etc/init.d instead of just always modifying /etc/rc.d/rc.local, etc... to avoid common pitfalls. In every case, I've never said it's the "not right" or otherwise.
If the OP was to use a script to do the mentioned firewall changes, and his script is locally generated (not part of a package), is it still intended that the script be stuck in the directories as if it were just another
package?
Yes, the /etc/init.d/ is a LSB standard and makes the commands very easy to port to other instances (let alone other distros), or be setup for only select run-levels.
Or would that be better invoked (directly or indirectly) via the rc.local script?
The rc.local script is always invoked for every run-level, and it is run last. Other than for temporary changes, it is better to create an /etc/init.d/ script, set the LSB comments in the header that define the order (both S[tart] and K[ill]), so it can be enabled/disabled for only select run-levels.
E.g., if iptables/iproute2 commands rely on networking to load, or at least the enabling of the NetFilter stack in the kernel, then it might not in some run-levels.
-- Bryan
P.S. This is definitely something that will be going into my ELManagers FAQ.
[ I know I'm now going to hear from "select people" that I'm "flaunting my resume" again. Sigh. ]
Actually in this context this information is useful. And tone matters too, remember. This has been a good thread, IMHO.
It should be noted that Red Hat does not have inter-service dependency checking, unlike SuSE and others -- which can be a major issue. Red Hat is actually developing a next-gen service initialization engine, much like Solaris already has, while still being LSB/legacy SysVinit compatible.
That's interesting. I used SuSE for like 3 years. It always "felt" well organized with respect to configuration scripts, but I wasn't sure if that was me just being naive or what? I'm not systems guru, so I wasn't sure. It just felt better. The last few RHEL releases, though, have been very good in this respect.
I'm sure I'm getting on the nerves of many. That's why it's probably best I discuss these things off-list, even if some value the information I can provide (they are typically the minority).
Why do you always have to do this? Make it personal. No one is out to get you. There's no witch hunt. I think this thread has been very productive and interesting, personally. You're not getting on my nerves right now. This conversation has been very instructive and interesting to me.
Preston
Preston Crawford me@prestoncrawford.com wrote:
Actually in this context this information is useful. And tone matters too, remember. This has been a good thread, IMHO.
In the past, I've only done it in the context of answering people after they have told me where they are coming from. I appreciate you appreciated it, but others might not.
That's interesting. I used SuSE for like 3 years. It always "felt" well organized with respect to configuration
scripts,
but I wasn't sure if that was me just being naive or what?
SuSE is more LSB compliant in this regard.
Why do you always have to do this? Make it personal.
I'm just being honest. I'm sure I've taken the tangent well of the path from the original. I wanted to admit that. I also figured that the people that wanted to hear this are still in the minority. I'm basically thanking people for putting up with it, as I'm sure the seasoned admins are tired after the 5th or 6th time.
No one is out to get you. There's no witch hunt. I think this thread has been very productive and interesting, personally. You're not getting on my nerves right now.
I know, because you are participating. But for those who are not, I'm sure they tire of the fact that I've covered the same topics in 5 or 6 posts -- things that were not in the original question.
William L. Maltby wrote on Thu, 03 Nov 2005 18:59:33 -0500:
Philosophically, I agree. *However*, we should keep in mind that the original provision of that script was to keep local sysadmins (and others) from having to monkey with the standard "supported" stuff. *If* that purpose is *still* it's primary reason for being, then it is still a *preferred* method if your POV is from a support aspect (that is, e.g. RH supporting site admins).
I think the main point of the discussion got lost in the meantime. It was *not* rc.whatever vs. init.d scripts, but "iptables save" vs. running your own iptables script. There are good reasons to run your own script instead of saving and restarting that saved state and it's quite different in functionality. Whether you then run this script as an init script, from rc.local or yet another startup method is a matter of taste (although init.d clearly has technical/usability advantages).
Kai
Kai Schaetzl wrote:
William L. Maltby wrote on Thu, 03 Nov 2005 18:59:33 -0500:
I think the main point of the discussion got lost in the meantime. It was *not* rc.whatever vs. init.d scripts, but "iptables save" vs. running your own iptables script. There are good reasons to run your own script instead of saving and restarting that saved state and it's quite different in functionality. Whether you then run this script as an init script, from rc.local or yet another startup method is a matter of taste (although init.d clearly has technical/usability advantages).
If you really want a 'neat' way to manage your iptables firewall then just use shorewall.
It's not the right place for things that need to be adjusted on runlevel changes, although it can be used as a quick fix for not having a proper init script.
One final point, why would you want to change a firewall on runlevel changes? On an internet facing machine this would seem an odd and risky thing to do...
Get your firewall right, and you never need to change it unless the function of the box changes, certainly have a firewall change on run levels seems weird to me....
Regards
Pete
Les Mikesell wrote:
On Thu, 2005-11-03 at 07:32, Peter Farrow wrote:
Rc.local is used explicitly for the running of scripts after the system has booted.
It is used as a catchall for things that don't have more explicit scripts using the runlevel mechanism.
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.
I don't follow how using the standard mechanism makes something less visible, or why anyone would think to look in rc.local instead of the usual place.
Having it visible in rc.local makes it easily viewable to see if its been changed.
Compared to??
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.
That's a reasonable point, but if you want to address it you might suggest a different init script linked to the right places in the runlevel directories. Someone might find it there...
To say that putting in rc.local is "not right" is really a bit misguided...
It's not the right place for things that need to be adjusted on runlevel changes, although it can be used as a quick fix for not having a proper init script.
On Mon, 2005-11-07 at 10:38 +0000, Peter Farrow wrote:
One final point, why would you want to change a firewall on runlevel changes?
Oh, I can think of many, many reasons -- from different network services between run-levels to X11 ports. Sometimes you want to block and/or forward based on what is running.
On an internet facing machine this would seem an odd and risky thing to do...
That's why I said _try_ to _always_ leave the "main iptables" script running for _all_ run-levels, then add any supplemental script as necessary. That way ...
1) the "main iptables" script _always_ comes up before any network interfaces
2) is _never_ taken down (except for init 0 or init 6, of course), and
3) any supplemental script can be taking up/down as appropriate for init levels
Furthermore, when Red Hat gets more LSB compliant in Fedora Core 5 (so RHEL5 as well), there will be dependency checking. That will ensure iptables is up before any network interfaces come up, and network interfaces are taken down if the iptables rules go down -- depending on configuration.
Get your firewall right, and you never need to change it unless the function of the box changes, certainly have a firewall change on run levels seems weird to me....
That still ignores the fact that you should let the "main iptables" script run _before_ any network interfaces come up ... not after. Several people pointed that out. ;->
I think you're reaching at this point -- just let it go. Use what you wish, but respect why many may disagree. From what I've seen, you're asserting things that just aren't true with regards to run-levels.
No offense, but if you don't like SysV init, run BSD. @-ppp
On Mon, 2005-11-07 at 04:38, Peter Farrow wrote:
It's not the right place for things that need to be adjusted on runlevel changes, although it can be used as a quick fix for not having a proper init script.
One final point, why would you want to change a firewall on runlevel changes? On an internet facing machine this would seem an odd and risky thing to do...
The main reason would be so that the settings would be found by anyone with a sysV background on any machine with a sysV-like runlevel mechanism. Even if you only have two states, that's where someone would look first to find them. And, it lets you set it up at the right place during startup. rc.local is run much too late to turn on a firewall although if you don't run any other services or proxies on the machine it might not matter.
It's not the right place for things that need to be adjusted on runlevel changes, although it can be used as a quick fix for not having a proper init script.
One final point, why would you want to change a firewall on runlevel changes? On an internet facing machine this would seem an odd and risky thing to do...
Get your firewall right, and you never need to change it unless the function of the box changes, certainly have a firewall change on run levels seems weird to me....
Regards
Pete
That's a question for someone else. I just wanted to know how to do it so I could port-forward 80 to 8080 so Tomcat could be seen on 80, but still run as a non-privelaged user. That's all.
Preston
On Tue, 2005-11-01 at 14:22 +0000, Tom Brown wrote:
What's the canonical way to do this in CentOS/RHEL? I know how to do it from the command line, but how to do I make a NAT route permanent?
rc.local ?
Okay. That's how I used to do it, but I wasn't sure if something changed. Just drop the lines in question in there and it's all good?
Preston
On Tuesday 01 November 2005 17.50, Preston Crawford wrote:
On Tue, 2005-11-01 at 14:22 +0000, Tom Brown wrote:
What's the canonical way to do this in CentOS/RHEL? I know how to do it from the command line, but how to do I make a NAT route permanent?
rc.local ?
Okay. That's how I used to do it, but I wasn't sure if something changed. Just drop the lines in question in there and it's all good?
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.
Preston
On Tue, 2005-11-01 at 18:53 +0200, Peter Kjellström wrote:
On Tuesday 01 November 2005 17.50, Preston Crawford wrote:
On Tue, 2005-11-01 at 14:22 +0000, Tom Brown wrote:
What's the canonical way to do this in CentOS/RHEL? I know how to do it from the command line, but how to do I make a NAT route permanent?
rc.local ?
Okay. That's how I used to do it, but I wasn't sure if something changed. Just drop the lines in question in there and it's all good?
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.
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.
Preston
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" thebs413@earthlink.net wrote:
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.
And yes, to make this a CentOS post, it was (and still is) running CentOS.
We normally ship RHEL 3 ES x86 in our reseller kits -- installed with a Quickstart disk, RHN setup on first-boot so they can get Red Hat updates/support, etc... yada, yada, yada. Standard "we ship a commercially supported distro" to end-users reality.
But for our own purposes -- from development to deployment -- we regularly utilize CentOS 3 x86 -- spinning our own single CD installer with our logos, etc... And that included the stuff we deployed in Louisanna, Mississippi and Texas over the last few months.
And yes, we have stuff in south Florida right now too. I'll shutup now. <marketing=off>
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).
Exactly. I do this even at home. It's almost to the point of absurdity. I'll avoid the quick and dirty so that I learn to do it the right way, precisely so when I'm called on to do it at work I know the right way.
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.
Same here. rc.local was my first thought, but I figured with all the progress made in abstracting (repos.d is a good example) configuration more neatly, that there had to be a better way.
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.
This is what I did. Thanks!!!
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.
Nice. So FEMA got something right. :-)
I mean that as a compliment to you, not a slam on FEMA.
Preston
-
Bryan J. Smith -
Kai Schaetzl -
Les Mikesell -
Peter Farrow -
Peter Kjellström -
Preston Crawford -
Tim Edwards -
Tom Brown -
William L. Maltby