Multiuser Startup

When the kernel finishes its core setup and hands control over to userland, init(8) runs the shell script /etc/rc. This script handles all system setup, including mounting filesystems, configuring device nodes, identifying shared libraries, and any other task required to make the system usable. Some tasks are delegated to separate scripts; for example, /etc/netstart is used to configure the network.

In this section, we’ll cover how /etc/rc and other startup scripts function, and the flow of the startup process. Armed with this understanding, you should be able to easily configure your OpenBSD machine to start exactly what you need—no more, no less.

Startup System Scripts

The startup system includes the scripts /etc/rc, /etc/rc.conf, /etc/rc.conf.local, /etc/netstart, /etc/rc.securelevel, /etc/rc.local, /etc/rc.shutdown, /etc/rc.firsttime, /etc/fastboot, and the contents of the /etc/rc.d directory.

The /etc/rc Script

On OpenBSD, everything outside the kernel is configured with a shell command, from setting the hostname to starting server daemons. The master script is /etc/rc, and it runs all of these commands in the correct order, ensuring that the system is configured exactly the same way at every boot. As a final step, /etc/rc runs getty(8) to present login prompts on all the appropriate terminals.

Never edit /etc/rc unless you’re a very experienced systems administrator with truly unique needs. This is one of the several files in /etc that is technically editable, but mere mortals are well advised to treat as binary. Instead, whenever you need to disable functions, deactivate them in /etc/rc.conf.local. To add new functionality to the startup process, use the shell scripts /etc/rc.securelevel and /etc/rc.local, or write a shell script for /etc/rc.d.

The /etc/rc.conf Script

The /etc/rc.conf file contains nothing but the default values for all other startup scripts. Read this file to see the configuration options for different system services. Here’s a small snippet of what you’ll find in rc.conf:

…
bgpd_flags=NO           # for normal use: ""
rarpd_flags=NO          # for normal use: "-a"
bootparamd_flags=NO     # for normal use: ""
rbootd_flags=NO         # for normal use: ""
sshd_flags=""           # for normal use: ""
named_flags=NO          # for normal use: ""
…

If a variable is set to NO, the associated service is disabled by default.

As you can see, OpenBSD turns off almost everything by default, with one exception: the SSH daemon. Setting the variable to a pair of quotes, as shown after each entry in the preceding snippet, is enough to enable most daemons, and most daemons will run just fine without any command-line flags. However, if a daemon requires a command-line argument in order to run, that argument will be shown as it is in the -a attached to rarpd_flags.

Note

At the risk of beating my dead server senseless, never edit /etc/rc.conf (treat as binary—remember?). It will be replaced wholesale during a system upgrade. Instead, place your local values in /etc/rc.conf.local.

The /etc/rc.conf.local Script

I’ve mentioned this before, but I’m going to beat you over the head with it: Place your changes to rc.conf in rc.conf.local. Entries in rc.conf.local override the defaults in rc.conf.

For example, say that on a particular machine, you want to run sshd(8) with extra debugging, and you also want to run named(8). Additionally, you want to run the time server ntpd(8), and have it correct the time at boot by using the -s flag. After consulting the documentation for those programs, you add the following lines to rc.conf.local:

sshd_flags="-D"
ntpd_flags="-s"
named_flags=""

OpenBSD will start the programs with the flags specified here. If you specify invalid, incorrect, or incompatible flags, the daemon will print error messages to the console.

The /etc/netstart Script

While its name differs from the other scripts, /etc/netstart is definitely a system startup script. It reads /etc/mygate, /etc/myname, and all the /etc/hostname.if files, and uses the information in them to configure all network interfaces, bridges, routing, and so forth. The file /etc/rc runs this script before starting any server daemons, network filesystems, and so on. In single-user mode, you’ll run this script by hand to bring up the network.

The /etc/rc.securelevel Script

The /etc/rc.securelevel shell script runs early in the boot process, before /etc/rc raises the system securelevel, but after starting the network. Many programs, particularly those that touch the kernel or intimately affect the filesystem, will not run once the securelevel is raised. If you run such a program, you can add the command to start it to this script. If your local program doesn’t need to run before the system securelevel is raised, you’re better off starting it from rc.local or writing a proper rc.d script for it.

One important entry in rc.securelevel is the definition of the system securelevel. We’ll discuss securelevels in Chapter 10. For now, don’t touch the line that sets the securelevel unless you’re already familiar with BSD-based systems and know exactly which toe you’re shooting off.

The /etc/rc.local Script

After /etc/rc does just about everything else, it runs /etc/rc.local. You can put commands to start local daemons in rc.local, but you’re better off writing an rc.d script to start local daemons so you can easily and consistently restart them later. Of course, if you’re lazy, you can get by with rc.local.

The /etc/rc.shutdown Script

Whenever you use reboot(8) or halt(8), OpenBSD runs the /etc/rc.shutdown script, which you can count on to run extra commands needed to safely shut down your server. Most server software shuts down cleanly without any special intervention, but software that requires data integrity (like databases) may need help shutting down without losing data. Again, if at all possible, write an rc.d script to manage your software.

The /etc/rc.firsttime Script

/etc/rc runs the script /etc/rc.firsttime once, mails the output to root, and deletes rc.firsttime. The installer uses rc.firsttime for tasks such as fetching firmware that can’t be legally redistributed. While you won’t normally use rc.firsttime, you should know that it exists and that you can use it to perform one-time tasks when a machine boots.

The /etc/fastboot Script

If the /etc/fastboot file exists, OpenBSD assumes that all filesystems are clean (see Chapter 8), and the boot process skips checking filesystem integrity.

The /etc/rc.d Directory

The /etc/rc.d directory contains shell scripts for managing software, as discussed in the next section. While the system comes with scripts for software included in OpenBSD, add-on packages can provide their own scripts (see Chapter 13).

Software Startup Scripts

OpenBSD uses shell scripts to start, stop, restart, check, and reconfigure server software. These scripts are found in the directory /etc/rc.d. Every piece of server software that comes with OpenBSD has a script in this directory, as do most ports and packages that need scripts for proper startup and shutdown. Use these scripts to manage integrated software without rebooting the server.

The rc.d scripts read their configuration from rc.conf and rc.conf.local. Most servers run the SSH daemon sshd, which can be enabled by adding the line sshd_enable="" to rc.conf.local. Look in /etc/rc.d, and you’ll find the shell script sshd.

If you change your sshd configuration, you must restart the daemon. Use the shell script to do this consistently.

# cd /etc/rc.d/
# ./sshd restart
sshd(ok)
sshd(ok)

Of course, you could do the same thing without the shell script simply by identifying the currently running sshd(8) process, reading the man page to see how to shut it down properly, and then restarting it with the same command-line flags. In the case of sshd, that’s easy: Running pkill -1 sshd would tell the daemon to reread its configuration file. But restarting a daemon that requires all sorts of flags is a big deal. Automating these system administration tasks ensures that your daemons run consistently.

To see if a daemon is running, use the check command to check your shell for the return value. The script will return a 0 if the daemon is running and a 1 if it isn’t, as shown here:

# ./nfsd check
# echo $?
1

As you can see by the 1, nfsd is not running.

The most common use for check is in shell scripts. You can start the daemon with the argument start and terminate it with stop. Use the restart argument to tell the daemon to reload its configuration.

In OpenBSD, rc.d scripts run when the system boots and again when it shuts down. (Something needs to unmount all those hard drives, shut down daemons, and clean up.) At shutdown, every script in the /etc/rc.d folder is called with the stop argument.

Third-Party rc.d Scripts

OpenBSD packages for third-party software include rc.d scripts as necessary. For example, the popular database server MySQL mysql-server package installs the script /etc/rc.d/mysqld. To use the package, you must enable it in rc.conf.local:

mysqld_flags=""

Once the package is enabled, you can manage your MySQL server just like any other OpenBSD daemon. However, packaged software will still not start automatically at boot, so you must tell OpenBSD to run this particular rc.d script at boot and shut down with the pkg_scripts variable in rc.conf.local:

pkg_scripts="mysqld"

The startup process runs the scripts in this variable, in the order given, at boot. The order is important for certain daemons. For example, if you have a database-driven website, you should start the database before the web server. At shutdown, it runs these scripts in reverse order.

Force-Starting Software

Sometimes you don’t want to enable software globally; you just want to run a certain daemon for a short time or to address a specific situation. You can use rc.d scripts to manage this software using the -f flag to force the software to run.

Now for a real-life example. I previously ran PostgreSQL on my server, but someone kidnapped my pet rats and blackmailed me into using MySQL in exchange for their safe return. I needed to check some data in the old database, however, so I force-started the disabled PostgreSQL server:

# ./postgresql -f start
postgresql(ok)

If you package or install your own software, I strongly recommend writing your own rc.d script. A few minutes spent reading the existing scripts will tell you most of what you need to know. For the rest, read the rc.d(8) and rc.subr(8) man pages.

Now that you can start OpenBSD, let’s set up some user accounts.



[11] On i386 and amd64 systems, this is where the MBR comes in.

[12] Granted, a remote keyboard-video-mouse (KVM) system can give you all of this, but very few KVM applications let you copy and paste text from the remote console. That means you’ll need to copy error messages by hand.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.181.47