This is a discussion on Teaching standard init config... within the Linux Operating System forums, part of the Unix Operating Systems category; --> I'm having a problem. I'm planning for a college course in Apache web server, and have opted to teach ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| I'm having a problem. I'm planning for a college course in Apache web server, and have opted to teach the standard way of compiling and installing the software from source. The problem is to configure the machine to start Apache at boot. It seems one of the rules of creating your own Linux dist is to make sure your init config doesn't look like anyone else's. It's not just a matter of a layer of config tools on top of the standard files, etc. The hierarchy of scripts is really different from Red Hat to Slackware to Ubuntu. So I'm at a loss. If I can't teach how to make Apache start at boot, I can't really teach them how to compile and install from source. Since the students choose whatever dist they like, I can't really teach installing Apache at all. To me, that is an essential part of the course. I'm basically just looking for some feedback on this. Have you been taught some standard way of dealing with rc scripts? Any great ideas in general? Thanks! |
| |||
| On Sat, 26 Nov 2005 14:29:25 +0100, Kronocide <henning@kronocide.com> wrote: > It seems one of the rules of creating your own Linux dist is to make > sure your init config doesn't look like anyone else's. It's not just a > matter of a layer of config tools on top of the standard files, etc. > The hierarchy of scripts is really different from Red Hat to Slackware > to Ubuntu. > > So I'm at a loss. If I can't teach how to make Apache start at boot, I > can't really teach them how to compile and install from source. Since > the students choose whatever dist they like, I can't really teach > installing Apache at all. To me, that is an essential part of the > course. I think this is a better approach: Teach them how to start apache using means that comes with apache. Teach them to write a script that does whatever it takes in a chosen arrangement of yours. Then tell them that distributors have made (dis)similar choices, and each student should investigate how it is done in their distribution. Make it a homework assignment to write a short description of their own environment. In other words, your mission is not to teach them a recipe of twenty keypresses and two mouse gestures that installs apache as a service on a computer running no matter what distribution. Your mission is to enable them to figure out how it is done on their particular distro, with the fallback of writing a script they can stick in /etc/inittab. As far as I know, all distros start from init and /etc/inittab. Teach them to start there if everything else fails. -Enrique |
| |||
| On 26 Nov 2005 05:29:25 -0800 "Kronocide" <henning@kronocide.com> wrote: [snipped] > I'm basically just looking for some feedback on this. Have you been > taught some standard way of dealing with rc scripts? Any great ideas in > general? Why not use Webmin: http://www.webmin.com/index.html -- remove MYSHOES to email |
| |||
| "Kronocide" <henning@kronocide.com> wrote in message news:1133011765.417731.186440@g49g2000cwa.googlegr oups.com... > I'm having a problem. I'm planning for a college course in Apache web > server, and have opted to teach the standard way of compiling and > installing the software from source. The problem is to configure the > machine to start Apache at boot. > > It seems one of the rules of creating your own Linux dist is to make > sure your init config doesn't look like anyone else's. It's not just a > matter of a layer of config tools on top of the standard files, etc. > The hierarchy of scripts is really different from Red Hat to Slackware > to Ubuntu. > > So I'm at a loss. If I can't teach how to make Apache start at boot, I > can't really teach them how to compile and install from source. Since > the students choose whatever dist they like, I can't really teach > installing Apache at all. To me, that is an essential part of the > course. Reverse engineer it. Do what the rest of us do when packaging tools, and look how the experts do it. For Apache, I'd take apart an SRPM and build an RPM from it for RedHat or SuSE, look at a deb if we were teaching in Debian or Ubunto, etc. If I didn't have or want an RPM, I'd teach the students to look at the existing examples, such as the network init script, and show how it has start/stop/chkconfig/restart/status options, how it uses chkconfig to manage enabling and restarting it, etc. > I'm basically just looking for some feedback on this. Have you been > taught some standard way of dealing with rc scripts? Any great ideas in > general? I've written plenty: I look at what the locally supported distro does, and teach *that* as a guiding principle, to teach people to avoid setting things up from scratch that may conflict with local setups. You get good results from this: by discussing with them why, say, RedHat puts the actual web pages in /var/www and how /var is set aside for bulky material that changes rapidly, and why /etc/httpd is a good directory to put the dozens of config files of a complex setup and avoid mingling them with other things in /etc., or why if installing from scratch starting out by putting things in /usr/local instead of /usr can help avoid stomping local system files, you can milk the lesson for a lot of very useful programming principles that will save your students pain in future lives. |
| |||
| In comp.os.linux.setup Kronocide <henning@kronocide.com>: > I'm having a problem. I'm planning for a college course in Apache web > server, and have opted to teach the standard way of compiling and > installing the software from source. The problem is to configure the > machine to start Apache at boot. It's not always a very clever way to install from source, perhaps showing how to make a source .rpm or .deb, compile and install it would be another idea. > It seems one of the rules of creating your own Linux dist is to make > sure your init config doesn't look like anyone else's. It's not just a Iirc lsb compatible distro use 'chkconfig'. $ man -k runlevel chkconfig (8) - updates and queries runlevel information for system services ntsysv (8) - simple interface for configuring runlevels [..] > So I'm at a loss. If I can't teach how to make Apache start at boot, I > can't really teach them how to compile and install from source. Since > the students choose whatever dist they like, I can't really teach > installing Apache at all. To me, that is an essential part of the > course. As last resort you can put "/path/to/apachectl start" into rc.local/boot.local/etc startup script. Not that clean but should work anyway. -- Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94) mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/' #bofh excuse 395: Redundant ACLs. |
| |||
| On Sat, 26 Nov 2005 14:57:18 +0100, Enrique Perez-Terron wrote: > On Sat, 26 Nov 2005 14:29:25 +0100, Kronocide <henning@kronocide.com> > wrote: > >> It seems one of the rules of creating your own Linux dist is to make >> sure your init config doesn't look like anyone else's. It's not just a >> matter of a layer of config tools on top of the standard files, etc. The >> hierarchy of scripts is really different from Red Hat to Slackware to >> Ubuntu. >> >> So I'm at a loss. If I can't teach how to make Apache start at boot, I >> can't really teach them how to compile and install from source. Since >> the students choose whatever dist they like, I can't really teach >> installing Apache at all. To me, that is an essential part of the >> course. > > I think this is a better approach: Teach them how to start apache using > means that comes with apache. Teach them to write a script that does > whatever it takes in a chosen arrangement of yours. Then tell them that > distributors have made (dis)similar choices, and each student should > investigate how it is done in their distribution. Make it a homework > assignment to write a short description of their own environment. > > In other words, your mission is not to teach them a recipe of twenty > keypresses and two mouse gestures that installs apache as a service on a > computer running no matter what distribution. Your mission is to enable > them to figure out how it is done on their particular distro, with the > fallback of writing a script they can stick in /etc/inittab. > > As far as I know, all distros start from init and /etc/inittab. Teach > them to start there if everything else fails. > > -Enrique There is much to recommend this approach, but I would expand it. Make it a homework assignment to figure out how their distro is unique (file hierarchy, init and rc.* files, permissions, start/kill/restart scripts, sw install, distro-specific config issues, etc.), and then present a written theoretical discussion of what they learned. When all assignents are all in, grade the work by whatever standard, and hand out copies of info fore each unique distro tot he entire class, thus equipping them with a touch more information than they would otherwise have to hand. |
| |||
| On Sat, 26 Nov 2005, in the Usenet newsgroup comp.os.linux.setup, in article <op.s0uo1si8nxtvbs@apeiron.home.lan>, Enrique Perez-Terron wrote: >In other words, your mission is not to teach them a recipe of twenty >keypresses and two mouse gestures that installs apache as a service on >a computer running no matter what distribution. Your mission is to >enable them to figure out how it is done on their particular distro, >with the fallback of writing a script they can stick in /etc/inittab. [Without inferring disrespect to the O/P] BRAVO!!! Well stated, sir!!! >As far as I know, all distros start from init and /etc/inittab. Teach >them to start there if everything else fails. Actually (quoting from "From-PowerUp-To-Bash-Prompt-HOWTO"): Once the kernel is loaded, the first thing it does is look for an init program to run. The 'init' used in many modern UNIX or UNIX-like systems influenced by SystemV (and that includes Linux) looks for a file named /etc/inittab, and away we go. Yes, /etc/inittab may call a bewildering choice of files, but it's the common starting point. Even common DOS/windoze users _used_ to know that there were two files that started things - config.sys and autoexec.bat. Most never had a clue _what_ those files were doing, but they were used to having to edit them (with help) to add crap. Then microsoft lowered the bar... To the original poster - Reading the "From-PowerUp-To-Bash-Prompt-HOWTO" really would be a good idea, and it might even be a useful document for your class to read as a homework assignment. Old guy |
| |||
| "Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message news:slrndohgst.v45.ibuprofin@compton.phx.az.us... > On Sat, 26 Nov 2005, in the Usenet newsgroup comp.os.linux.setup, in > article > <op.s0uo1si8nxtvbs@apeiron.home.lan>, Enrique Perez-Terron wrote: > >>In other words, your mission is not to teach them a recipe of twenty >>keypresses and two mouse gestures that installs apache as a service on >>a computer running no matter what distribution. Your mission is to >>enable them to figure out how it is done on their particular distro, >>with the fallback of writing a script they can stick in /etc/inittab. > > [Without inferring disrespect to the O/P] > > BRAVO!!! Well stated, sir!!! > >>As far as I know, all distros start from init and /etc/inittab. Teach >>them to start there if everything else fails. > > Actually (quoting from "From-PowerUp-To-Bash-Prompt-HOWTO"): > > Once the kernel is loaded, the first thing it does is look for an init > program to run. > > The 'init' used in many modern UNIX or UNIX-like systems influenced by > SystemV (and that includes Linux) looks for a file named /etc/inittab, > and away we go. Yes, /etc/inittab may call a bewildering choice of > files, but it's the common starting point. Even common DOS/windoze users > _used_ to know that there were two files that started things - config.sys > and autoexec.bat. Most never had a clue _what_ those files were doing, > but they were used to having to edit them (with help) to add crap. Then > microsoft lowered the bar... > > To the original poster - Reading the "From-PowerUp-To-Bash-Prompt-HOWTO" > really would be a good idea, and it might even be a useful document for > your class to read as a homework assignment. Umm, guys? There's only so much time available in any course. As wonderful as it can be to learn the basics, getting deeply into inittab *as well as* the init scripts may cut into time for more Apache specific material this person may need to cover. If you've got the time to cover it, I agree. |
| |||
| As stated above there is of course a time limit, and no limit at all to the amount of stuff I'd like to teach. I have 15x45 minutes to cover installation and configuration of Apache, including virtual hosts, SSL certificates, support for PHP, perl_mod, etc. I wish I could teach them all about init, but that's just not possible. I also do not want to make my instructions so abstract they become meaningless. My lesson on getting Apache to start from boot shouldn't be, "Learn how your distro works. Configure it correctly." They don't need me to tell them that. What I'll do is have them go through the motions of compiling and installing a standard Apache distro, then they can choose if they want to reinstall using their package manager or figure out their init config. I will point them to the KSysV handbook, which contains a short, principal explanation of init, and also to the HOWTO recommended above (thanks!) for more in-depth information. Thanks for the great feedback guys. |
| ||||
| On Sun, 27 Nov 2005, in the Usenet newsgroup comp.os.linux.setup, in article <QoCdnYzoTZizMxTeRVn-sQ@comcast.com>, Nico Kadel-Garcia wrote: >"Moe Trin" wrote: >> Enrique Perez-Terron wrote: >>>In other words, your mission is not to teach them a recipe of twenty >>>keypresses and two mouse gestures that installs apache as a service on >>>a computer running no matter what distribution. which doesn't, in any case. exist. Each has their own way of doing so. >>>Your mission is to enable them to figure out how it is done on their >>>particular distro, with the fallback of writing a script they can >>>stick in /etc/inittab. >> BRAVO!!! Well stated, sir!!! >> The 'init' used in many modern UNIX or UNIX-like systems influenced by >> SystemV (and that includes Linux) looks for a file named /etc/inittab, >> and away we go. Yes, /etc/inittab may call a bewildering choice of >> files, but it's the common starting point. >> To the original poster - Reading the "From-PowerUp-To-Bash-Prompt-HOWTO" >> really would be a good idea, and it might even be a useful document for >> your class to read as a homework assignment. >Umm, guys? There's only so much time available in any course. I understand that, and really don't expect the O/P to try to teach the "From-PowerUp-To-Bash-Prompt-HOWTO". There is no need to even teach shell scripting and how to use a man page, as basic concepts should be a pre-requisite to the course. The world doesn't need another twenty r00ted web sites run by people who don't have the basic knowledge to use a push button telephone but are doing so because they saw someone randomly pressing keys on a TV ad for Wankers'R'us. The man pages for 'init', 'inittab' (and maybe even initscript) are not anywhere near as difficult as trying to read through some of the exotic "show 'em how great a programmer we are" stuff that is in the specific scripts. "When the kernel starts, the first thing it runs is 'init'. Init looks at the file /etc/inittab to find out what runlevel is desired if it was not passed this parameter by the boot loader, and then runs these scripts in this order. rc.sysinit does this, that, and the other. rc runs scripts that do this and that, based on the run level. It runs the K scripts in the run level directory with the parameter 'stop' and then the S scripts in the same directory with the parameter 'start'. Those scripts are normally links to the actual scripts in the init.d directory. Here is how one script works..." yada, yada, yada. Yes, it would take longer than that, but you can pack a hell of a lot of information into an hour. >As wonderful as it can be to learn the basics, getting deeply into >inittab *as well as* the init scripts may cut into time for more Apache >specific material this person may need to cover. You don't need to get that deeply into /etc/inittab, and anyway, they wouldn't need to - other than understanding the sequence that the scripts are run, and why you don't start Apache out of the top of that file (if at all), and that you need networking before networking daemons. As far as the init scripts - I don't know whether to blame Miquel van Smoorenburg, or the herd that followed for the obfuscated material in the average init scripts, but sometimes I do recommend reading those scripts (along with the man page for the shell and the server being started/commands being run, and the abs-guide from The Grendel) to try to learn scripting techniques. >If you've got the time to cover it, I agree. Some things need to be pre-requisites. Configuring a server securely is not a click and move a slider or activate a radio button type of thing. Congratulations. You've just figured out that they lied to you when they told you even an untrained monkey on crack can use a computer. Yes, there's a lot to learn That's not mine, but it does hit the mark pretty accurately. Old guy |