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.