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)
