Putting nat routing into place permanently? -- [OT] and so it begins (the debate)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



And so it continues ...  

"William L. Maltby" <BillsCentOS@xxxxxxxxxxxx> 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/tocsysinit.html

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.


-- 
Bryan J. Smith                | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx     |  (please excuse any
http://thebs413.blogspot.com/ |   missing headers)

[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