The /etc/adduser.conf file contains the persistent configuration for adduser(8), which Chapter 6 covers in detail. To change adduser’s settings, edit this file. This file is self-documenting, and if you’ve read Chapter 6, you shouldn’t have any trouble with it.

The automounter daemon automatically loads NFS filesystems upon request. If you’re interested in this function, read the amd(8) man page.

The automounter daemon isn’t as useful as you might think. As the documentation says, “A weird imagination is most useful to gain full advantage of all the features.”

The /etc/authpf directory contains the authenticating packet filter configuration. If you’re interested in having user authentication for firewall access, I recommend The Book of PF, 2nd Edition, by Peter Hansteen (No Starch Press, 2010).

OpenBSD includes a BGP daemon, bgpd(8). Most sysadmins will never go near BGP, but if you need it, see the bgpd.conf(5) man page.

The /etc/boot.conf file controls the system’s booting process, as discussed in Chapter 5.

/etc/changelist is a text file that contains the list of files to be checked by the daily security check script, /etc/security. We cover these tasks in detail in Chapter 15.

The chio(1) medium changer lets you manage jukebox-style media arrays, such as CD and tape changers. If you have a tape backup unit that can swap between multiple tapes all on its own, chio is your friend. Configure chio in /etc/chio.conf. Most OpenBSD users don’t have media changers, but if you’re interested, see the man page for chio(1).

The /etc/csh.* files contain system-wide defaults for csh(1) and tcsh(1). When a user logs in with either of these shells, the shell executes any commands listed in /etc/csh.login. Similarly, when the user logs out, the shell executes any commands in /etc/csh.logout. Put general shell configuration in /etc/csh.cshrc.

The /etc/daily.local script is run every day to maintain the system. See Chapter 15 for details.

You can configure OpenBSD’s DHCP client by using dhclient(8), as discussed in Chapter 12.

OpenBSD includes a secure DHCP server. It started life as an Internet Systems Consortium (ISC) DHCP server, but has been repeatedly rewritten and simplified by the OpenBSD team. See Chapter 16 for details.

The /etc/disklabels/ directory traditionally contains backup copies of disklabels, as discussed in Chapter 8. Very few system administrators actually use it, because very few system administrators know it’s there. OpenBSD copies the disklabels for all system disks as part of the daily backup of critical files (see Chapter 15).

A couple of decades ago, hard drives were expensive and precious devices that came in only a few varieties. While modern disks can tell the computer about their geometry, older disks need manual configuration, as do older removable media such as 1.44MB floppy disks and Zip disks. If you want to access one of these ancient disks, you’ll need the information in /etc/disktab. (But if you need to use one of these old disks, you’re almost certainly solving the wrong problem.)

The /etc/dumpdates file records the dates of the last successful dump(8) backup. The dump tool backs up a filesystem, rather than just the files on a filesystem, as tar(1) does. A dump includes file flags and other special characteristics of the filesystem.

OpenBSD implements the Distance Vector Multicast Routing Protocol (DVMRP) with dvmrpd(8), configured in dvmrpd.conf. This is another edge case where OpenBSD performs well, but is of interest only to a few users. If you’re interested in DVMRP, see the dvmrpd(8) man pages.

NFS servers list the filesystems they export, and who may access them, in /etc/exports. See Chapter 9 for information about using NFS as both a client and a server.

OpenBSD can change the ownership of system files and devices based on how a user has logged in. When a user logs in via the text console, login(1) changes the ownership of the console, as well as the keyboard and the mouse, to that user. This way, users can then configure the keyboard or mouse to suit their preferences. A user who logs in via an X session needs similar changes.

You could use /etc/fbtab to change permissions on other devices or files for other special needs, but this is really tricky to get right, and usually means you’re making something much more complicated than it needs to be. If you’re considering this approach, rethink your problem.

Some hardware needs software to run. In years past, this software would have been loaded onto programmable read-only memory (PROM) chips on the device itself. Network cards often had boot PROMs that let them get configuration information from the network. PROMs are not expensive these days, but making millions of anything adds up quickly. Hardware vendors now often ask the operating system to load this software, called firmware, onto the hardware for them.

Firmware is usually a closed-source binary object, or blob. While the OpenBSD team members would never accept loading a blob into the kernel, they’re willing to hand a file to a piece of hardware. It doesn’t matter if the hardware gets the blob from the operating system or from a PROM chip attached to the hardware—it’s still software that runs only on the device, not in the operating system.

For user convenience, OpenBSD distributes firmware that it’s legally permitted to offer. If OpenBSD cannot distribute firmware on the installation media, the fw_update script uses the package system to fetch it over the Internet. Wherever the firmware comes from, it’s stored in /etc/firmware.

By default, fw_update runs at first boot after an OpenBSD install or upgrade, but you can run it any time you want (it’s stored in /usr/sbin).

The /etc/fonts/ directory contains the Xenocara X11 fonts. We’ll discuss Xenocara and X11 in Chapter 17.

The filesystem table lists all filesystems that the system knows about, whether they’re automatically mounted at boot or kept in reserve. See Chapter 8 for details.

Users listed in /etc/ftpchroot are automatically chrooted into their home directory when they log in via FTP. See ftpd(8) for full details.

Try to avoid FTP, as it transmits usernames and passwords in cleartext. Use scp(1) or sftp(1) instead.

The /etc/ftpusers file does exactly the opposite of what the filename implies, but it has been this way for decades, so don’t worry about it.

Any user listed in /etc/ftpusers cannot log in via FTP. See ftpd(8) for details, but again, use scp(1) or sftp(1) instead—especially for administrative tasks!

The /etc/gettytab file contains the configuration information for login terminals. Unix-like systems have been traditionally accessed by anything and everything, from innumerable slightly different serial consoles to Secure Shell (SSH) sessions over the network. If you ever need to use a nonstandard terminal type, explore /etc/gettytab.

There’s no reason to get rid of this file. After all, someone out there probably still uses a plugboard 1200-baud terminal. But there’s no longer any reason to modify it either. In any case, the man page is worth reading, especially if you read it to the end.

The /etc/group file controls to which groups each user account belongs. User groups are covered in Chapter 6 and Chapter 7.

OpenBSD can act as a wireless access point. The host access point daemon (hostapd(8)) lets OpenBSD perform some complicated access point tasks that are useful in larger environments. OpenBSD’s wireless services are interesting if you use wireless; read hostapd(8) and ifconfig(8) for full details.

The /etc/hostname.* files configure network interfaces, as discussed briefly in Chapter 4 and at length in Chapter 12.

The /etc/hosts file contains a hand-maintained map of IP addresses and hostnames. See Chapter 12 for details.

The /etc/hosts.equiv file is used by the various r-tools, such as rcp(1), rlogin(1), and rsh(1). These tools, and the underlying protocols, are relics of an earlier age, when security on the Internet was not so great a concern. OpenBSD no longer includes an rlogin(1) client. The r-tools are largely replaced by SSH. Today, you should not use the r-protocols under any sensible circumstances.

The /etc/hosts.equiv file should not contain any uncommented entries, unless you specifically put them there. This is the only system file I can reasonably say every sysadmin should verify is empty and marked immutable (see Chapter 10).

What did I mean by “sensible circumstances” and using the r-protocols? A few years ago, I worked on a network with ancient but mission-critical VMS servers manageable only by r-protocols, but those were not reasonable circumstances. If you find yourself similarly trapped, check out hosts.equiv(5), rshd(8), and rsh(1). And do something about your circumstances.

You can configure an OpenBSD system to accept print requests from other machines and feed them to a locally attached printer. This was vital when printers were big, expensive beasts, but it’s less important today. This file lists the hostnames or IP addresses of systems that may use the local system’s line printer daemon, lpd(8).

If you’re really interested in having your OpenBSD system print, check out lpd(8) and /etc/printcap.

OpenBSD can automatically take action when a device is plugged into the system through hotplugd(8). For example, if you attach your digital camera to a USB port, hotplugd can run a script that will attach the device node to a directory and make it readable by your user account.

hotplugd runs the script /etc/hotplug/attach when a device is attached, and /etc/hotplug/detach when a device is removed. These scripts must be carefully written to match the devices being attached and detached. For details on how this works, see hotplugd(8).

The interface state daemon ifstated(8) monitors network conditions and takes action when specified events occur. For example, you can configure ifstated to watch for another server to go down, and when that server fails, start up the local web server. For more information about using ifstated, see Hansteen’s The Book of PF.

The /etc/iked/, /etc/iked.conf, /etc/ipsec.conf, and /etc/isakmpd files manage OpenBSD’s implementation of the IPsec standard for VPNs. OpenBSD has a very robust IPsec implementation, and it is actually used for testing by various interoperability groups.

You can fill entire books with the acronyms used for VPN technologies, let alone instructions for actually configuring them. See the man pages for details.

The Internet small service listener inetd(8) attaches to multiple network ports for programs that don’t need to run constantly. When a request on one of those ports comes in, inetd activates the correct program to handle the request. Chapter 16 discusses inetd(8) in more detail.

The /etc/kbdtype file contains a single line with your preferred terminal keyboard mapping. Test your keyboard mapping with kdb(1), and then put that keyboard mapping in /etc/kbdtype.

The /etc/kerberosV/ directory contains configuration for the Kerberos centralized authentication system. I recommend some kind of centralized logon for every network. Configuring Kerberos properly is a large subject. If you’re interested, peruse kerberos(1).

/etc/ksh.kshrc is the global configuration file for the public domain Korn shell included with OpenBSD. Users must include this file in their personal .kshrc for settings here to take effect. See the ksh(1) man page for details.

OpenBSD includes a Lightweight Directory Access Protocol (LDAP) daemon. LDAP is commonly used for centralized authentication, address books, and other database operations that are read more than they write. As of this writing, the features of ldapd(8) are not complete, but it’s good enough to provide a central authentication point.

The /etc/localtime file is a symlink to the actual time zone file. To change the time zone, change the symlink. Chapter 4 covers time zones.

The /etc/locate.rc file controls creation of the locate(1) database. OpenBSD updates the locate database every week, as discussed in Chapter 15.

With /etc/login.conf, you can control user account login behavior, as discussed in Chapter 6.

OpenBSD includes the lynx(1) text-mode web browser. Lynx is endlessly configurable, and settings in /etc/lynx.cfg affect all Lynx users on the system. You can save yourself a lot of trouble by configuring your proxy server settings here.

Many files include a “magic number” and other characteristics specific to their type. file(1) uses these magic numbers to identify the file type, with /etc/magic as an index of magic numbers. Do not manually edit /etc/magic, as it’s automatically generated by compiling file(1).

The /etc/mail/ directory contains the configuration files for OpenBSD’s email software. OpenBSD includes two email packages: the old workhorse Sendmail and the OpenBSD-created smptd(8). smptd isn’t quite ready for production use, but it might be by the time this book hits the shelves.

This directory also contains /etc/mail/aliases, a list of mail redirections. Be sure you set the email alias for your root account to somewhere you’ll actually read your email, as discussed in Chapter 4.

The /etc/mail.rc file has nothing to do with sending or receiving email as a mail server. It’s the global configuration file for the mail(1) email client. While more advanced email clients have almost completely superseded mail, it’s worth exploring because almost any Unix-like system will have it installed.

Traditionally, the only mail server program available for any Unix-like operating system was Sendmail. As such, a huge amount of add-on software expects to find /usr/sbin/sendmail and expects it to behave in a certain manner. It doesn’t matter that, by modern standards, Sendmail and the whole Simple Mail Transfer Protocol (SMTP) are baroque and bizarre; software expects to find it.

Worse, sendmail(8) behaved differently depending on what name it was called with. Programs such as send-mail, mailq, and newaliases are all Sendmail wearing different hats. If you call the Sendmail program by running the mailq command, it runs differently than if you call it by running the newaliases command. They all point to the same binary on disk, however. Third-party software expects to find all these names as well, and that these commands behave as required.

Sendmail is such a standard that writers of newer mail server programs are forced to call them sendmail and to have them behave exactly as Sendmail does, just to maintain compatibility with this vast installed base. This makes using alternate mailers confusing. Also, OpenBSD includes Sendmail as part of the base system. You can’t just remove Sendmail and go on. Upgrades reinstall brand-name Sendmail.

OpenBSD does an end run around all this confusion by eliminating /usr/sbin/sendmail as an actual mail program. Instead, the sendmail program is just a wrapper that calls the real mail-handling software. The entries in /etc/mailer.conf are just a list of classic Sendmail program names, along with the path to the actual program to be run. The mail-handling program sendmail is actually installed as /usr/libexec/sendmail/sendmail, for example.

To run an alternate mail server, give /etc/mailer.conf the expected command name and the full path to all of the appropriate programs. This happens automatically when you install a new mail transfer agent from a package.

The etc/man.conf file tells man(1) how to find and present man pages. If you install software in nonstandard locations, add the information on the software’s man pages to man.conf so that you can call up those man pages transparently. This file has several types of entries, each of which is set off by keywords or section names.

Why would you do this? If you must install software from a source other than ports or packages, you could place it in a directory tree outside those managed by OpenBSD to reduce confusion when upgrading or adding software.

For example, I occasionally install Wireshark on an OpenBSD desktop. The OpenBSD team decided to remove OpenBSD’s Wireshark package because it has such a shaky security history. If I installed Wireshark as /usr/local/bin, it would be mingled with my packaged software. If I install Wireshark as /usr/local/wireshark/bin, however, it’s clearly distinct from packaged software. I can’t access the man pages, however, as man(1) doesn’t know about /usr/local/wireshark/man.^[39] Let’s walk through how we would add man page access for Wireshark.

_whatdb /usr/local/wireshark/man/whatis.db

_default /usr/{share, X11R6,local,ports/infrastructure}/man/

_default /usr/{share, X11R6,local,ports/infrastructure,local/wireshark}/man/

_subdir  man1 man8 man6 man2 man3 man5 man7 man4 man9 man3p man3f mann

1 /usr/{share,X11R6,local}/man/man1

The /etc/master.passwd, /etc/passwd, /etc/spwd.db, and /etc/pwd.db files contain usernames and passwords, along with a few other key items about locally defined users. When you log in, the password you type is compared with the encrypted and salted hash of your password in this file. As such, /etc/master.passwd is vital to system security.

OpenBSD includes solid audio abilities. You can listen to MP3s, mix music, or just about anything else you would like.

Control audio settings with mixectl(8), and set boot-time mixerctl settings in /etc/mixerctl.conf.

Configure make(1) with /etc/mk.conf. The most common use for special make settings is while you are building ports (covered in Chapter 13) or while building your own custom OpenBSD release (Chapter 20).

The /etc/moduli file contains prime numbers, used for Diffie-Hellman cryptography. Never edit this file. Some people may understand cryptography well enough to edit /etc/moduli, but if you’re reading this book, you’re probably not one of them.^[40]

The /etc/monthly.local shell script runs once per month as part of routine system maintenance. Chapter 15 discusses scheduled maintenance jobs.

The MOTD, or message of the day, is displayed to users upon login. In this file, you might put system notices or announcements that you hope users will notice. Many organizations put legal notices or acceptable use policies in /etc/motd.

Note that the first line of /etc/motd is overwritten at every boot. Start your legal warning in line 2 or below.

In addition to dvmrpd(8), OpenBSD supports multicast routing with mrouted(8). The dvmrpd implementation is preferred, but for specific edge cases, you might need mrouted instead.

Configure mrouted in /etc/mrouted.conf. Eventually, mrouted will be removed from OpenBSD.

The /etc/mtree/ directory contains a list of most directories on a stock OpenBSD system, with their ownership and permissions. The system upgrade process uses this. While you don’t really need to edit these files, it’s nice to know what the heck they’re for.

The /etc/mygate script gives the address of the default gateway for both IPv4 and IPv6, as discussed in Chapter 12.

The /etc/myname file contains the hostname of the system, as discussed in Chapter 4.

The /etc/netstart script starts the network, as discussed in Chapter 12.

/etc/networks is a list of subnets and their names. Use of a networks database has fallen out of favor, because it’s not terribly useful.

The newsyslog(8) program rotates log files, as discussed in Chapter 15.

OpenBSD has imported the nginx web server (http://www.nginx.org/) as a replacement for the older Apache 1.3 server, but as of this writing, it’s not quite integrated with the rest of the system. You can find the nginx configuration files in this directory, and the server is quite usable, but it’s not the official OpenBSD web server—yet.

OpenBSD has imported the name server daemon nsd(8) to eventually partially replace the old DNS workhorse server named(8). It’s usable, but as of this writing, it’s not yet integrated with the system.

The NTP daemon keeps the system time synchronized with other machines on your network and the Internet. We discuss ntpd(8) in Chapter 15.

OSPF is a routing protocol used inside autonomous networks. OpenBSD has two OSPF implementations: one for IPv4 and one for IPv6. If you want to know more about OSPF, read ospfd(8) and ospf6d(8).

Configure the OpenBSD pf(4) packet filter in /etc/pf.conf. Packet filtering uses /etc/pf.os to fingerprint other operating systems. Chapter 21 and Chapter 22 cover packet filtering.

You can connect OpenBSD to the Internet via a dial-up modem, which is rarely done these days. If you need to configure a modem on your OpenBSD system, read the ppp(8) man page.

The printer capability file describes all printers that this system can access. Making a Unix-like system work with a random printer was long considered to require some sort of sacrifice, a moon in the correct phase, and a team of chanting acolytes in robes. While complicated software such as CUPS has been written to simplify printing, configuring an OpenBSD machine to print to a print server or a network PostScript printer is pretty simple. See Chapter 16 for details on printing.

The /etc/protocols file contains protocol numbers for TCP/IP network protocols. Chapter 11 covers TCP/IP versions 4 and 6 in detail.

rbootd(8) offers boot services for HP workstations—a very narrow subset of obsolete diskless clients. OpenBSD still supports the HP300 machines that need this service. If you’re interested in diskless operations on modern hardware, read the diskless(8) man page instead, or look at Chapter 23.

The /etc/rc.* files are used for system booting, as discussed in tortuous detail in Chapter 5.

The load balancer daemon relayd(8) works with the OpenBSD Packet Filter (PF) system to act as a network load balancer. The relayd daemon requires a good understanding of PF, however, and a very specific network. If you’re interested in load balancing, read Hansteen’s The Book of PF.

Unix-like systems have extensive support for connecting into the system over serial lines, usually for serial consoles. Many network appliances have management serial ports, and you can use OpenBSD as a client to configure these devices. The /etc/remote file contains serial connection configurations for most common modern serial connections (covered in Chapter 5).

The /etc/resolv.conf and /etc/resolv.conf.tail files configure the resolver (covered in Chapter 12), letting the host map names to IP addresses and vice versa.

RIP is an old way to broadcast routing instructions across a network. OpenBSD has a RIP daemon, ripd(8), configured in /etc/ripd.conf.

RIP is generally considered undesirable, like the r-services. Among other shortcomings, it doesn’t even support netmasks, so it’s restricted to old-style class A, B, and C networks. And as with the r-services, sometimes you’re stuck with RIP because some obsolete device on your network can handle nothing else. Use ripd to scrape by until you can arrange a tragic accident for that device.

The remote magnetic tape command (rmt) lets a host access a tape drive on another machine. It’s most commonly used to restore a system from backup.

RPC is a method for executing commands on a remote server. Much like TCP/IP, RPC has service and port numbers. The file /etc/rpc contains a list of these services and port numbers. The most common RPC consumer in OpenBSD is NFS, as discussed in Chapter 9.

OpenBSD supports failover between IPsec gateways, using the security association synchronization daemon sasyncd(8). This is not a common feature in operating systems, and its presence is a highlight in OpenBSD. To learn about IPsec failover, read sasyncd(8).

Modern hardware has sensors for detecting items like fan speed, circuit voltage, temperature, and so on. OpenBSD’s sensord(8) reads these sensors and presents the information to the user. Configure which sensors you want to pay attention to, as well as what you want to do when the sensors detect something, in /etc/sensorsd.conf. See Chapter 15 for details on sensorsd.

The /etc/services file contains a list of network services and their associated TCP/IP ports. See Chapter 11 for details.

The /etc/shells file contains a list of legitimate user shells, as discussed in Chapter 6.

The /etc/skel/ directory contains standard user environment configuration files. When you create a user account, adduser(8) copies the files in this directory to the new user’s home directory. This directory can be overwritten when you upgrade your system.

If you need to customize these files for your users, create a custom dotfile directory and tell adduser(8) to use it instead.

The Serial Line Internet Protocol (SLIP) predated the Point-to-Point Protocol (PPP) commonly used for dial-up lines. OpenBSD still supports it, as someone might need it and there’s no real reason to get rid of it.

Simple Network Management Protocol (SNMP) is a method for accessing information about a device over the network. Unfortunately, it’s not a terribly secure protocol (one common acronym for SNMP is “Security? Not My Problem!”) The OpenBSD team has written a more secure SNMP daemon, snmpd(8). Configure it in /etc/snmpd.conf, as discussed in Chapter 16.

While OpenBSD’s SNMP daemon might resist intrusions and abuse, it can’t help the fact that SNMP itself, as commonly deployed, isn’t terribly secure.

The SSH daemon sshd(8) offers a secure replacement for telnet(1) and the r-protocols. Chapter 16 includes a brief discussion of SSH.

The /etc/ssl/ directory is for Secure Sockets Layer (SSL) certificates, as well as the OpenSSL configuration file openssl.cnf. Store system SSL certificates here.

The /etc/sudoers file controls sudo(1) configuration. See Chapter 7 for details about sudo.

Set kernel runtime tunable options in /etc/sysctl.conf. Sysctls are covered in Chapter 18.

The logging daemon syslogd(8) reads messages from programs and hosts, and then separates those messages into records based on the configuration in /etc/syslog.conf. See Chapter 15 for details on syslogd.

The systrace(4) system call wrapper provides access controls to system calls. You could run a binary “under” systrace(1), and if the program attempted to access any system call beyond those permitted in the application’s systrace policy, systrace would block the access.

Flaws were found in systrace, however, that make it less than effective, and it’s now considered only a partial solution. It still ships with OpenBSD, but its use is discouraged. Today, systrace is mostly used for package-building clusters to make sure that software built doesn’t phone home or write outside the fake installation root.

If you need to use systrace, store policies in /etc/systrace.

The /etc/termcap file describes all the different terminals that OpenBSD supports. Pretty much every console device now supports the standard VT220 terminal, however.

Configure system terminals in /etc/ttys. You can enable, disable, and change terminals here. A “terminal” could be the keyboard and monitor attached to the computer, a login over a serial line as with a serial console, or a virtual terminal as used by telnet or SSH.

A classic UNIX terminal device resembled a teletype; that’s where the tty label comes from. All sorts of UNIX architectural details descend from this historical accident, and Unix-like systems inherited them.

ttyC0 /usr/libexec/getty std.9600 vt220 on secure

tty0e   "/usr/local/sbin/faxgetty"      dialup  on

# kill -HUP 1

The /etc/weekly.local script runs once a week to perform weekly maintenance, as discussed in Chapter 15.

OpenBSD includes hardware-independent access to the physical console through the wscons(4) driver. Configure this console via wsconsctl(8). The boot-time wsconsctl settings are read from /etc/wsconsctl.conf. See Chapter 17 for details on console configuration.

The /etc/X11 directory contains configuration for the X Window System. OpenBSD’s Xenocara integrates X with the base system. Chapter 17 discusses desktop OpenBSD, including some X features.

In addition to the LDAP daemon ldapd(8), OpenBSD supports the YP database for centralizing passwords, groups, and host filesystems. YP is compatible with Sun’s original Network Information System (NIS). OpenBSD uses YP as a gateway to LDAP authentication. If you’re interested in this feature, see yp(8) and ypldap(8).

This takes you through everything in /etc not covered elsewhere. In the next chapter, we’ll discuss how OpenBSD maintains itself, and how you can meddle with the maintenance processes.