From rfunk Thu Sep 23 11:10:01 1999 Subject: Re: [COLUG] ssh2 To: colug@bopper.wcbe.org Date: Thu, 23 Sep 1999 11:10:01 -0400 (EDT) ><SNIP> >rc.local is the 'right' place to add programs that need to be started at >boot. RedHat (and some others) put them in /etc/rc.d/init.d. Debian >puts >them in /etc/rc.d ??. This is one of the 'incompatibilities' of the >different distributions. But they all have an rc.local file which >should >be the last thing executed in the bootup sequence. ><SNIP> And today's lecture is on startup scripts.... :-) There are two prototypical approaches to startup scripts -- the BSD way and the System V way. The BSD way has /etc/rc.local for starting up a bunch of daemons; originally it was supposed to be basically empty when the system was installed, and each site would add to it as needed. Eventually vendors started shipping their systems with rc.local full of stuff like sendmail and X. The BSD way was adopted by the Slackware Linux distribution (except I think they might put rc.local in /etc/rc.d/), and it is preferred (major understatement) by a lot of people who like its simplicity when adding new daemons. In my opinion those people don't understand the advantages of the other way.... The System V way, adopted in some form by most of the mainstream Linux distributions (except Slackware), starts with the concept of multiple runlevels, with different daemons running in different runlevels; e.g. runlevel 1 might be non-networked, runlevel 2 might be networked, and runlevel 3 might be networked and serving other machines. Runlevel 0 is shutdown, runlevel 6 is reboot, and runlevel "S" is single-user. When switching runlevels, the system must start or stop daemons as appropriate to the new runlevel; when moving from runlevel 3 to 2, you might want to stop the NFS daemons, and when moving in the opposite direction you want to start them. The System V scheme involves directories init.d and rc[0-6S].d where "[0-6S]" is the letter S or any digit from 0 to 6. Traditionally these directories are in the /etc/ directory, but some Linux distributions put them under /etc/rc.d/, and some Unices put them under /sbin/. The init.d directory (NOT to be confused with inetd) is full of the actual scripts that are used to start and stop the daemons or subsystems. The scripts are called with either "start" or "stop" as arguments, to start or stop the daemon or subsystem associated with that script. Sometimes a script will also allow "restart" or even "status". The rc[0-6S].d directories (rc0.d, rc1.d, rc2.d, rc3.d, and so on) are the ones actually used on bootup. They are full of links to the scripts in init.d. Each "active" link begins with either an S or a K (for start or kill), then a two-digit number (for ordering), then the name of the init.d script it's linked to (or a close variant of it). When going into a runlevel, first the K scripts are run with the "stop" argument, then the S scripts are run with the "start" argument. The best way to disable something in a particular runlevel is to rename its link in that runlevel so that it doesn't start with a capital S. (The various Linux runlevel editors I've seen don't do that, so I don't use them.) The downside of this scheme is complexity when adding a daemon or subsystem. You need to put a new script in init.d that understands both "start" (the easy one) and "stop" (the hard one). Often you can just adapt one of the existing scripts. Then you need to make the right links in the right rc[0-6S].d directories so that it is started and stopped at the appropriate times. For example: cd /etc/rc.d/rc3.d ln -s ../init.d/sshd S75sshd cd ../rc0.d ln -s ../init.d/sshd K25sshd You also need to look at the existing order to see what numbers would be most appropriate to use; you don't want sshd starting before networking is set up, but you probably want it before you start serving disks to other machines. The major advantage of this scheme is that you only need to figure out how to stop something once (when you write the script), maybe less (if someone else wrote the script). After that, if you need to stop the sshd daemon, you just do "/etc/rc.d/init.d/sshd stop" or "/etc/init.d/sshd stop" (depending on where your distribution puts everything). To start it again, you do the same with "start" instead of "stop". This is incredibly useful, especially with more complicated subsystems like databases, or daemons with associated kernel modules. This scheme also makes life easier when dealing with daemons that must be restarted after changing their config files -- sendmail and inetd are biggies. Unfortunately inetd is often put in the same script as other network setup, making the script less useful. Whipple, Joe wrote: >Yes, for boot, but I had a problem earlier where my firewalling/masq >wouldnt work after linuxconf... ie: linuxconfig restarted inetd and so >lost all my rules. I had to run the script from >/etc/rc.d/rc3.d/S10network file, which an init level 3 calls to setup >the networking. My point is, rc.local will not work for some things like >setting up firewall rules if you do anything that HUP's inetd. Restarting inetd should have absolutely no effect on your firewall rules. inetd is just a daemon that happens to watch a lot of ports. linuxconf must have restarted more that that, like the whole network subsystem. Although it has a nice user interface, I don't trust linuxconf to do what I want correctly and securely. (Why does it need to open a network port of its own?!)