Resource Configuration Scripts


After init has been started, the remaining startup tasks in the systemthe ones that start all the services and operating system processesare handled by the resource configuration scripts. These scripts are compartmentalized based on their functions, and are all kept inside the /etc/rc.d directory.

The /etc/rc.d Directory

The resource configuration scripts in the modern versions of FreeBSD are all kept inside /etc/rc.d. Each shell program in this directory is a resource configuration script, a program that starts up a specific component of FreeBSD according to the system's configuration. Some of these scripts are called recursively from other programs; some do nothing in the out-of-the-box configuration; and some, written to address certain unusual configurations and deployments, will probably never even be run on your system. All executable files in the directory are run automatically by init, harnessed through the master /etc/rc script.

You'll probably never need to edit any of the scripts in /etc/rc.dthey're all designed to handle the dirty work of launching certain infrastructural services or daemons, and they take their configuration information from other sources, such as the /etc/rc.conf file. All you should ever need to modify are the configuration files, never the scripts themselves.

Tip

You can write your own resource configuration scripts to handle services or components that aren't part of the standard FreeBSD system, and if you put them in /etc/rc.d, they'll runbut a much better place to put them is in /usr/local/etc/rc.d, the "local" equivalent of /etc/rc.d (in other words, the directory that's set aside for resource configuration scripts that you install yourself). Scripts in /usr/local/etc/rc.d, such as the startup scripts installed along with many third-party software packages, are executed automatically after all the /etc/rc.d scripts have been run. Keeping them separate from the /etc/rc.d scripts makes it much easier to restore your system from a backup, or cleanly migrate your system's configuration to a new machine, if such needs should arise.


A utility called rcorder is used by /etc/rc to define the specific execution order for the resource configuration scripts. To see the order in which they're executed, type rcorder /etc/rc.d/* (this lists the files in the execution order defined by the keywords and prerequisite scripts listed in the headers of each of the files). Scripts with no prerequisites are executed first; then they're followed by the scripts that depend on the earlier scripts having been run already. See the PROVIDE, REQUIRE, and KEYWORD lines in each script; refer to man rcorder to see a fuller discussion of how they work, and man rc for more details on how rcorder is used to sort FreeBSD's resource configuration files.

Table 14.1 lists many of the more important resource configuration files in a stock FreeBSD 6.x system.

Table 14.1. Resource Configuration Scripts

Script Name

Description

/etc/rc

The master resource config script, which reads the configuration settings from /etc/rc.conf and then executes the scripts in /etc/rc.d.

/etc/rc.subr

An included script that defines subroutines used in the many scripts that reside in /etc/rc.d.

/etc/defaults/rc.conf

init reads in this file early in its execution to fill in its laundry list of tasks to do.

/etc/rc.conf

This is the file you edit to override the defaults set in /etc/defaults/rc.conf. This should be the only resource config file in /etc that you edit!

/etc/rc.d/

Resource Configuration for Daemons. Several dozen launch scripts in this directory are executed in the order defined by the rcorder utility. Most of these scripts' functions can be easily determined from their names; fsck runs the disk checks, named starts the name server, usbd activates the USB subsystem, and so on.

/usr/local/etc/rc.d/

Directory trees /usr/local/X11R6/etc/rc.d/ containing any new startup scripts you write (or are installed automatically when you add third-party software).


Note

FreeBSD versions prior to 5.0 kept their resource configuration files in the /etc directory, each one with an rc. prefix. If you're working with a FreeBSD version early in the 5.x series, where the files might not be completely migrated to the new structure from an earlier 4.x installation, you have the option to use the old-style structure. In your /etc/rc.conf file, turn off the rc_ng (RC Next-Generation) option, and FreeBSD will use the /etc/rc.* files rather than the /etc/rc.d/* files to control its startup procedure. Here's how:

rc_ng="NO"             # Set to YES to enable new-style rc. Experimental.


This technique can ease the transition to FreeBSD 5.x or 6.x if you don't want to risk destabilization from the new startup script structure. However, there is no reason to turn off the rc_ng option on a new installation, and indeed in FreeBSD 5.2 and later the option does not exist.


The /etc/defaults/rc.conf File

The resource configuration scripts are controlled by global system settings that are specified in either of two places: /etc/defaults/rc.conf and /etc/rc.conf. The former of these files is a part of the system and shouldn't be modified; the latter is the global configuration file that's yours to edit, and whose settings control all variations in system behavior from how it runs in its default configuration.

Take a look through some of the resource configuration scripts (such as /etc/rc.d/named) using your favorite text editor. You'll see that each one is completely automated; it works by checking whether certain variables are defined that control system configuration or whether certain files exist. If those variables or files are present, it executes a predefined, abstracted launch loop, which takes its parameters from those variables and files. Nothing in /etc/rc itself, or any of the standard scripts, should be edited. In other operating systems, the system startup process is altered and extended by making changes to the resource configuration scripts themselves; in FreeBSD, though, the model is to automate and abstract as much as possible of the process and centralize the control files that specify the parameters.

In earlier versions of FreeBSD, the only configuration file was /etc/rc.conf. It contained all the variables that /etc/rc and related scripts would need in their default states, and any modifications to the system would be made to the global config file. This arrangement quickly became unmanageable, however, as the list of available variables grew and the role of the file expanded. An administrator upgrading the system would painstakingly have to merge the old rc.conf with the new onehardly an improvement over just editing /etc/rc in the first place.

Therefore, the solution was to create a directory called /etc/defaults and put a copy of rc.conf, with all the default settings filled in, into it. Now, /etc/rc.conf still exists, but as an overlay whose contentsif presenttake precedence over the settings in /etc/defaults/rc.conf. For example, if the setting named_enable="NO" appears in /etc/defaults/rc.conf, you would turn on the named server not by changing that file, but by adding named_enable="YES" to /etc/rc.conf. This latter setting overrides the default setting in the previous file. FreeBSD will run even with an empty /etc/rc.conf file, but typical overrides that you'll be using are for the networking configuration (IP address, hostname, gateway address, and so on) and for running daemons such as Sendmail and sshd.

Let's look at a typical block in /etc/defaults/rc.conf, as shown in Listing 14.1.

Listing 14.1. Excerpt from /etc/defaults/rc.conf

# named. It may be possible to run named in a sandbox, man security for # details. # named_enable="NO"               # Run named, the DNS server (or NO). named_program="/usr/sbin/named" # path to named, if you want a different one. named_flags="-u bind"           # Flags for named named_pidfile="/var/run/named/pid" # Must set this in named.conf as well named_chrootdir="/var/named"    # Chroot directory (or "" not to auto-chroot it) named_chroot_autoupdate="YES"   # Automatically install/update chrooted                                 # components of named. See /etc/rc.d/named. named_symlink_enable="YES"      # Symlink the chrooted pid file

Using /etc/defaults/rc.conf, you can find what /etc/rc will do by default when it comes to each service with a launch script in /etc/rc.d. In the case of named, the default behavior is to not run it at all.

Typically, variables in /etc/defaults/rc.conf are grouped into blocks like in this example, with similar prefixes keeping them related and with a single "YES"/"NO" variable serving as a "master switch" at the top of the block. If the variable is set to "NO", generally none of the rest of the variables will matter; if it is set to "YES", all variables apply unless commented out. Commented lines are usually provided as examples to demonstrate a possible alternative usage, as with these lines in the syslog block:

syslogd_flags="-s"           # Flags to syslogd (if enabled). #syslogd_flags="-ss"         # Syslogd flags to not bind an inet socket


The /etc/rc.conf File

Let's say you do want to run named. In the simplest case, all you have to do is edit /etc/rc.conf (the "overrides" file) and add the following line anywhere in the file:

named_enable="YES"


The rest of the named_* variables in /etc/defaults/rc.conf do not need to be copied into the overrides file. Remember, every variable in the "defaults" file is loaded into memory by init, and they only matter if the "master switch" for that block has been turned to "YES". In that case, the default variables will be used in the execution loop in the appropriate script in /etc/rc.d to launch whatever process is controlled by the block you're working on (in this case, named).

Caution

As you tinker with /etc/rc.conf, it's a very good idea to keep a backup copy on hand so that you can easily back out to a known working system configuration. Create a backup file by simply copying your existing file before you begin working on it (this sample filename incorporates the current date so you can accurately retrace your steps):

# cp /etc/rc.conf /etc/rc.conf.backup.20060127


To switch back to the backup version, copy or move (rename) it back to its original name:

# mv /etc/rc.conf.backup.20060127 /etc/rc.conf


Alternatively, whenever you change a line in /etc/rc.conf, duplicate the line and comment out the old one, unaltered. That way you can always go back to the original settings if your new ones don't work.


You can use these other variables for fine-tuning, though, and override them just as easily. Let's say your name server program is a customized version called mynamed. Let's also say that you've created a bind user and group, intending that the name server should run as this user and group so it won't be susceptible to as many permissions-related vulnerabilities. To handle that, all you need to do (assuming that mynamed has the same behavior and command-line options as named) is add these two lines to /etc/rc.conf:

named_program="mynamed" named_flags="-u bind -g bind"


Just for curiosity's sake, you can examine the appropriate launch script to find out what init is doing with these variables. A script isn't executed unless the corresponding _enable variable is set to "YES"; assuming you've enabled the service by turning on this variable, you can look through the launch script (in this case, /etc/rc.d/named) to read what's involved in the startup process for that service.

The end of that script has these lines of code:

load_rc_config $name # The following variable requires that rc.conf be loaded first # required_dirs="$named_chrootdir"        # if it is set, it must exist pidfile="${named_pidfile:-/var/run/${name}/pid}" run_rc_command "$1"


The commands in these lines are subroutines that are defined in /etc/rc.subr, which also sets up the architecture by which the name of the service is mapped to the name of the appropriate launch script. For example, the rc.subr script already ensured that the value named has been assigned to the variable $name, so the first line of this code means that the command load_rc_config named is being run. This routine simply loads in the settings from /etc/rc.conf. Next, a variable called required_dirs is set to whatever value was defined in the named_chrootdir variable, whether you set it explicitly in /etc/rc.conf or let it use the default setting in /etc/defaults/rc.conf. Then another variable, pidfile (a file keeps track of the process ID for the service while it's running), is set either to the value of the named_pidfile variable if you defined it, or to /var/run/named/pid. Finally, the subroutine run_rc_command is called, with a standardized argumentreplacing the $1 variableof start. If you examine the /etc/rc.subr file and look at the definition of the run_rc_command subroutine, you'll find that it uses the standardized variables required_dirs and pidfile in its loop that finally launches the named daemon.

All this convoluted abstraction is difficult to follow unless you're skilled at tracing nested shell programs; but once you understand how certain standardized variables are passed back and forth and harnessed to launch each configured daemon, you can see that the benefits for FreeBSDallowing it to add new services and configure them in a single neat locationare readily apparent.

Note

See Chapter 10, "Shell Programming," for a tutorial on shell scripting, which will help you in reading the resource configuration scripts.


The most typical variables that appear in /etc/rc.conf are the TCP/IP configuration parameters. Because these are different for every system, FreeBSD can't very well specify them in the defaults. Listing 14.2 shows a typical /etc/rc.conf just after a new FreeBSD installation (your installation will vary, perhaps significantly).

Listing 14.2. A Newly Installed /etc/rc.conf

# -- sysinstall generated deltas -- # Sat Oct 23 02:17:22 2004 # Created: Sat Oct 23 02:17:22 2004 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. linux_enable="YES" sendmail_enable="YES" sshd_enable="YES" portmap_enable="NO" nfs_server_enable="NO" inetd_enable="NO" ifconfig_fxp0="inet 64.41.131.10 netmask 255.255.255.0" defaultrouter="64.41.131.1" hostname="simba.somewhere.com" usbd_enable="YES"

These variables were all written by Sysinstall during your initial installation of the system, and the "YES" or "NO" settings reflect the answers you gave to the series of questions in the post-installation configuration section covered in Chapter 2, "Installing FreeBSD." Some of these variables are, in fact, redundant with the settings in the defaults file; still, it can be useful to have them in the overrides file as well, because many of these features (such as the NFS server) now have a one-touch toggle control, in case you want to change your mind about them later.

Note

Many third-party applications, particularly network servers and databases, are installed with their own startup scripts (which reside in /usr/local/etc/rc.d) that depend on variables in /etc/rc.conf in order for them to run. For example, if you install the MySQL database server, you have to add mysql_enable="YES" to /etc/rc.conf before MySQL will start properly at boot time. In most cases this change is made automatically during the port or package installation (see Chapter 16, "Installing Additional Software"); but in case it doesn't, that's one possible reason why it might be failing. Check the installed startup script for the application to see if it seems to be looking for an _enable variable that you might need to add yourself.


Many programs, when you install them, will have to install a way for themselves to start up at boot time; /etc/rc.conf is not, however, the place for these programs. This file is supposed to be touched only by you, the administrator, and by the Sysinstall program when it makes changes to the core system. Another structure, the /usr/local/etc hierarchy, is in place for the startup scripts and configuration files of user-installed programs (ports and packages) and for any scripts that /etc/rc and friends do not know about.

The /usr/local/etc and /usr/local/X11R6/etc Directories

As you learned in Chapter 12, anything installed by the administrator goes into /usr/local. This is as true of startup scripts as it is of programs and shared libraries. The /usr/local/etc directory is the "local" equivalent of /etc (local referring to "this specific machine" as opposed to the generic components and settings found on all FreeBSD machines), and into it go all the configuration files installed by programs that you choose to install, rather than the ones controlled by the FreeBSD base system distribution.

Note

It's important to note that the difference between the /etc files and the /usr/local/etc files is not just that the former are "noneditable" and the latter are "editable." Just as most of the files in /etc should not be tampered with, many of the ones in /usr/local/etc also contain no user-serviceable parts or are designed not to need any modification by you in order to function (although the directory also contains customizable configuration files for installed programs). The distinction is that /etc controls the base systemfor example, only those programs that are always part of a FreeBSD installation. The files in /usr/local/etc control programs that you install after the fact, from the ports collection or from packages (which you'll learn about in Chapter 16). /usr/local/etc also doubles as the location for any startup scripts you write and add to the system (in its rc.d subdirectory).


The main local configuration directory, /usr/local/etc, contains configuration files that administrators edit to tune their programs' behaviors. You learn more about configuring ports and packages in Chapter 16. Here, however, we're interested in the rc.d (Resource Configuration for Daemons) subdirectory, which works in much the same way as /etc/rc.d.

init turns its attention to /usr/local/etc/rc.d after it has run through all the /etc/rc.d scripts. Any executable files within the directory that end in .sh are executed in lexicographical order. Examples of files that are installed in here include apache.sh, mysql-server.sh, and samba.sh. These scripts are custom-built as part of their corresponding ports or packages, and each one is tuned to take a start or stop argument, like their counterparts in the tightly controlled /etc/rc.d system. When init runs each script during the boot process, it uses the start argument. Note that you can just as easily run these scripts yourself during runtimefor instance, to start a newly installed service without rebooting:

# /usr/local/etc/rc.d/apache.sh start


Some ports or packages install with a secondary suffix of .sample (for example, samba.sh.sample). This suffix appears (masking the .sh suffix) because the program has to be properly configured before it can run successfully. The Apache web server, for instance, will run immediately after installation without any further modification to its config files (although you will no doubt be modifying them anyway). Apache, therefore, installs an apache.sh file, which could run the program cleanly if you executed it right then. However, the Samba network sharing server must be tuned first before it will run on your machine; if you ran its startup script right after installing it, it would fail to start the daemon. You need to make the necessary configuration changes and rename the script to remove the .sample extension before it will be run on startup by init.

The /usr/local/X11R6/etc directory (which is created if you install any third-party ports or packages for X11) is analogous to /usr/local/etc, except it is specifically tasked to X11-based programs, including GNOME panels, graphical tools, games, window managers, and so on. This directory also has an rc.d subdirectory, and scripts in it are executed immediately after the ones in /usr/local/etc/rc.d.

Note

The local startup-script directories are configurable. You can override this rc.conf line to add more directories if you need to:

local_startup="/usr/local/etc/rc.d /usr/X11R6/etc/rc.d" # startup script dirs.



Creating Scripts to Run Programs on System Boot

It is perhaps a bit optimistic to imagine that you will never need to have the system perform any startup tasks that are not tied to any of the carefully crafted ports/packages or the core system. You may want to run a custom daemon that you wrote yourself, for example, or clear out a common file-sharing directory every time the system boots. To do this, you can write your own shell script and put it into /usr/local/etc/rc.d.

Recall that init expects every script in the rc.d directory to be able to handle the start argument. Also, each script's name has to end in .sh in order to be run automatically. The following is a sample script from the man rc page:

#!/bin/sh # # PROVIDE: foo # REQUIRE: bar_service_required_to_precede_foo # BEFORE:  baz_service_requiring_foo_to_precede_it # KEYWORD: FreeBSD . /etc/rc.subr name="foo" rcvar=`set_rcvar` command="/usr/local/bin/foo" extra_commands="nop hello" hello_cmd="echo Hello World." nop_cmd="do_nop" do_nop() {         echo "I do nothing." } load_rc_config $name run_rc_command "$1"


This sample script (which you can tune to your own needs by filling in the appropriate names and special subroutines suitable to your program) uses the /etc/rc.subr script to handle the start and stop arguments for when the script is invoked by init. You might call this file foo.sh. Make sure it is set executable (chmod +x foo.sh)!

Technically, the program doesn't actually have to be a shell script; you can write it in Perl if you want, or even C or anything else that will run, as long as it has an .sh extension. Writing the program in anything other than a shell script is fairly bad form, though. You shouldn't have to try to fool the system! For more on shell scripting, consult Chapter 10.




FreeBSD 6 Unleashed
FreeBSD 6 Unleashed
ISBN: 0672328755
EAN: 2147483647
Year: 2006
Pages: 355
Authors: Brian Tiemann

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net