14
EXPLORING /ETC

The /etc directory contains the basic configuration information needed to boot a Unix-like system. Every time I get saddled with an unfamiliar system, one of the first things I do is scope out /etc. The fastest way to go from a junior sysadmin to a midgrade one is to read /etc and the associated man pages. Yes, all of it. Yes, this is a lot of reading. Understanding /etc means that you understand how the system hangs together. As you progress as a sysadmin, you’re going to pick up this information piecemeal anyway, so you might as well take the easier route and master this part of your toolkit at the beginning.

I discuss many /etc files in chapters where they’re most important, such as /etc/services in Chapter 7 and /etc/fstab in Chapter 10. Also, some files are of only historical interest or are gradually being removed. This chapter covers important /etc files that don’t quite fit anywhere else.

/etc Across Unix Species

Different Unix-like systems use different /etc files. In many cases, these files are simply renamed or restructured files from primordial BSD. The first time I encountered an IBM AIX system, for example, I went looking for a BSD-style /etc/fstab. It wasn’t there. A little hunting led me to /etc/filesystems, which is an IBM-specific /etc/fstab. Apparently IBM felt that a file named for an abbreviation of filesystem table was confusing, so they renamed the file. Knowing this information existed somewhere in /etc, and knowing which files it obviously wasn’t in, greatly shortened my search.

Even radically different FreeBSD systems have almost identical /etc directories. While some add-on programs insert their own files here, you can expect certain files to be on every FreeBSD system you encounter.

Remember that /etc is the heart of FreeBSD and that changes to these files can damage or destroy your system. While having to manually recover a scrambled filesystem can turn an adequate sysadmin into a pretty good one, it’s one of the least pleasant ways to get there.

/etc/adduser.conf

This file lets you configure the defaults for new users. See Chapter 9 for details.

/etc/aliases

This file lets you configure system-wide email forwarding. We cover it in Chapter 20.

/etc/amd.map

FreeBSD has the ability to automatically mount and unmount NFS filesystems upon demand through the automounter daemon, amd(8). The automounter daemon is very old, however, and has largely been replaced by autofs(5) and automountd(8). Automounting is mostly useful for workstations, so we won’t go into it.

/etc/auto_master

The auto_master file configures FreeBSD’s modern automounting service. It lets you configure mount options, determine how long an automounted filesystem should remain mounted, and so on. See auto_master(5), autofs(5), and automountd(8) for details.

/etc/blacklistd.conf

FreeBSD includes an automated blacklist daemon, blacklistd(8), that’s comparable to fail2ban and similar programs. Programs that link against libblacklist(3) can direct blacklistd(8) to block intrusive hosts at the firewall. We configure blacklistd(8) in Chapter 19.

/etc/bluetooth, /etc/bluetooth.device.conf, and /etc/defaults/bluetooth.device.conf

FreeBSD supports Bluetooth, a standard for short-range wireless communication. Unlike 802.11, Bluetooth is designed for short-range but high-level services, such as voice communications. This book is about servers, so we won’t cover Bluetooth, but you should know that your FreeBSD laptop can attach to your Bluetooth-equipped cellphone and connect to the internet if you desire.

/etc/casper

The Capsicum security system lets programmers add sandboxing and security capabilities to their software. The /etc/casper directory contains sample capsicum(4) configurations.

/etc/crontab and /etc/cron.d

The cron(8) daemon lets users schedule tasks. See Chapter 20 for examples and details.

/etc/csh.*

The /etc/csh.* files contain system-wide defaults for csh and tcsh. When a user logs in with either of these shells, the shell executes any commands it finds in /etc/csh.login. Similarly, when the user logs out, /etc/csh.logout is executed. You can place general shell configuration information in /etc/csh.cshrc.

Per-shell configuration is prone to errors, and you’ll have to maintain identical settings for any other shells. I recommend putting necessary environment variables in a login class (see “Restricting System Usage” on page 188).

/etc/ddb.conf

The kernel debugger configuration utility ddb(8) reads ddb.conf for instructions. We’ll use this in Chapter 24 to prepare kernel crash dumps on small systems.

/etc/devd.conf

The device daemon devd(8) is best known for managing detachable hardware, such as USB, PCCard, and Cardbus devices. When you insert a USB network card into your laptop, devd(8) notices the arrival and fires up the appropriate system processes to configure the card as per /etc/rc.conf. More generally, it’s a state change daemon and can react on link up/down events, notify you about CPU overheating, process suspend/resume events, and more. We discuss devd(8) briefly in Chapter 13, but if you think you need to edit /etc/devd.conf on a server, you’re probably doing something wrong.

/etc/devfs.conf, /etc/devfs.rules, and /etc/defaults/devfs.rules

FreeBSD manages device nodes through devfs(5), a virtual filesystem that dynamically provides device nodes as hardware boots, appears, and disappears. See Chapter 13 for more information.

/etc/dhclient.conf

Many operating systems give you very basic DHCP client configuration with no way to fine-tune or customize it; you either use it or you don’t. In most cases, an empty /etc/dhclient.conf file gives you full DHCP client functionality, but it won’t work correctly in all situations. Perhaps your network is having trouble or you’re at a conference where some script kiddie thinks it’s fun to set up a second DHCP server and route everyone’s traffic through his machine so he can capture passwords.

Your server better not be configured via DHCP (unless it’s diskless), so we won’t go into any depth on this. You should be aware that you can configure FreeBSD’s DHCP client functionality, however.

/etc/disktab

Once upon a time, hard disks were rare and exotic creatures that came in only a few varieties. In /etc/disktab, you’ll find low-level descriptions of many different kinds of disks, from the 360KB floppy disk to a Panasonic 60MB laptop hard drive. (Yes, laptops came with 60MB hard drives, and we were durned happy to have them.)

Today, this file is mostly used for removable media, such as 1.44MB floppy disks and zip disks. While I described formatting flash drives in Chapter 13, this file contains the descriptions needed to format other removable media. If you want to put a filesystem on your LS 120 disk or zip drive, you’ll find the necessary label here at the beginning of an entry.

Editing /etc/disktab is useful only if you have multiple identical hard drives that you want to partition and format in exactly the same way. If you need to make your own entries, read disktab(5).

/etc/dma/

The Dragonfly Mail Agent (DMA) stores its configuration in /etc/dma/. We discuss DMA in Chapter 20.

/etc/freebsd-update.conf

This file is used by freebsd-update(8) when getting binary updates for your server. See Chapter 18 for details.

/etc/fstab

See Chapter 10 for a discussion on the filesystem table, /etc/fstab.

/etc/ftp.*

The FTP daemon ftpd(8) uses these files to determine who may access the system via FTP and what access they have upon a successful connection. Unless you’re running a large FTP site, you should be using sftp(1) instead.

/etc/group

Assigning users to groups is covered in painful detail in Chapter 9.

/etc/hostid

Certain software expects every host to have a universally unique ID, or UUID. If you’re running on real hardware, this UUID is burned into the mainboard and is accessible via kenv(8). Virtual hosts can generate a UUID from software. The /etc/hostid file contains that UUID.

/etc/hosts

This file contains host-to-IP mappings, as discussed in Chapter 8.

/etc/hosts.allow

The /etc/hosts.allow file controls who can access the daemons compiled with TCP Wrappers support. Learn about it in Chapter 19.

/etc/hosts.equiv

The /etc/hosts.equiv file is used by the r-services (rlogin, rsh, etc.) to let trusted remote systems log in or run commands on the local system without providing a password or even logging in. Hosts listed in this file are assumed to have performed user authentication on a trusted system, so the local system doesn’t have to bother reauthenticating the user.

Such blatant trust is very convenient on friendly networks, much as leaving the doors of your Manhattan townhouse unlocked saves you the trouble of digging out your door keys every time you get home. There’s no such thing as a friendly network.¹ A single disgruntled employee can largely destroy a corporate network with this service, and a machine using the r-services is pretty much dog meat for the first script kiddie who wanders by. In fact, /etc/hosts.equiv and its related services have bitten even top-notch security experts who thought they could use it safely. I suggest leaving this file empty and perhaps even making it immutable (see Chapter 9).

/etc/hosts.lpd

The /etc/hosts.lpd file is one of the simplest files in /etc. Hosts listed here, each on its own line, may print to the printer(s) controlled by this machine. While you can use hostnames, that would allow DNS issues to choke printing, so use IP addresses instead.

Unlike most other configuration files, /etc/hosts.lpd doesn’t accept network numbers or netmasks; you must list individual hostnames or IP addresses.

We configure FreeBSD as a printer client in Chapter 20.

/etc/inetd.conf

inetd(8) handles incoming network connections for smaller daemons that don’t run frequently. See the section on inetd in Chapter 20.

/etc/libmap.conf

FreeBSD’s linker lets you substitute one shared library for another. We discuss this in Chapter 17.

/etc/localtime

This file contains local time zone data, as configured by tzsetup(8). It’s a binary file, and you can’t edit it with normal tools. tzsetup(8) actually copies this file from a subdirectory of /usr/share/zoneinfo. If your time zone changes, you’ll need to upgrade FreeBSD to get the new time zone files and then rerun tzsetup(8) to configure time correctly.

We discuss time in Chapter 20.

/etc/locate.rc

locate(1) finds all files of a given name. For example, to find locate.rc, enter the following:

# locate locate.rc
/etc/locate.rc
/usr/share/examples/etc/locate.rc
/usr/src/usr.bin/locate/locate/locate.rc
/var/db/etcupdate/current/etc/locate.rc

You’ll see that a file called locate.rc can be found in four places: in the main /etc directory, the system examples directory, the system source code, and a copy retained by etcupdate(8).

As part of periodic(8)’s weekly run (see Chapter 21), your FreeBSD system scans its disks, builds a list of everything it finds, and stores that list in a database. The list-building program, locate.updatedb(8), takes its settings from /etc/locate.rc. The following variables in this file all change how your locate.updatedb(8) builds your locate database:

• TMPDIR contains the temporary directory used by locate.updatedb(8), and defaults to /tmp. If you’re short on space in /tmp, change this path to a place where you have more room.
• While you can change the location of the database itself with the FCODES variable, this affects other parts of FreeBSD that expect to find that database in its default location. Be prepared for odd results, especially if you leave an old locate database in the default location of /var/db/locate.database.
• The SEARCHPATHS variable gives the directory where you want to start building your database. This defaults to /, the whole disk. To index only a portion of your disk, set that value here.
• PRUNEPATHS lists directories you don’t want to index. This defaults to excluding temporary directories that traditionally contain only short-lived files.
• The FILESYSTEMS variable lists the types of filesystems you want to index. By default, locate.updatedb(8) indexes only UFS (FreeBSD) and ext2fs (Linux) filesystems. Listing NFS (see Chapter 13) filesystems is a bad idea: all of your servers simultaneously indexing the fileserver will bottleneck either the network or the fileserver.

/etc/login.*

You can control who may log into your system—and what resources those users may access—by using /etc/login.access and /etc/login.conf. See Chapter 9 for instructions.

/etc/mail

Most of the contents of /etc/mail are dedicated to Sendmail. The two exceptions are the aliases(5) file and mailer.conf(5). We discuss both in Chapter 20.

/etc/mail.rc

While FreeBSD uses most .rc files for system startup, the /etc/mail.rc file is used to configure mail(1).

/etc/mail/mailer.conf

FreeBSD allows you to choose any mail server program you like via /etc/mail/mailer.conf, as covered in Chapter 20.

/etc/make.conf

To make, or compile, a program is to build it from source code into machine language. We’ll discuss building software in detail in Chapter 17. The /etc/make.conf contains settings that control how the building process works, letting you set options that directly affect software builds. Remember, anything you add to make.conf affects all software built on the system, including system upgrades. This may cause upgrade failures.² Many of the options from make.conf are useful only to developers.

If you’re interested in setting options that affect only system upgrades, use /etc/src.conf instead.

Here are some common features set in make.conf. Any values set here require the same syntax used by make(1). If you insist on trying to optimize software builds, follow the examples in make.conf(5) or in the software’s documentation. Best of all, though, don’t muck with make at all.

CFLAGS

This option specifies optimization settings for building nonkernel programs. Many other Unix-like operating systems suggest compiling software with particular compiler flags, or CFLAGS. This practice is actively discouraged on FreeBSD. System components that require compiler flags already have that specified in the software configuration, and add-on software has that configuration set for it separately. While people might recommend other settings for CFLAGS, custom options aren’t supported by the FreeBSD Project.

In general, FreeBSD code is expected to compile most correctly out of the box. The only thing that adding compiler options can do is impair your performance. If you build FreeBSD or ports with nonstandard flags and have problems, remove those flags and build it again.

COPTFLAGS

The COPTFLAGS optimizations are used only for building the kernel. Again, settings other than the defaults can build a nonworking kernel.

CXXFLAGS

CXXFLAGS tells the compiler what optimizations to use when building C++ code. Be sure to use the += syntax when using CXXFLAGS so that you add your instructions to those specified in the software. Everything that I said earlier about CFLAGS applies equally well to CXXFLAGS.

/etc/master.passwd

This file contains the confidential core information for all user accounts, as discussed in Chapter 9. Protect it.

/etc/motd

The message of the day (motd) file is displayed to users when they log in. You can place system notices in this file or other information you want shell users to see. The welcome option in /etc/login.conf (see Chapter 9) can point users to different motd files, so you can have separate messages for each login class.

/etc/mtree

mtree(1) builds directory hierarchies with permissions set according to a predefined standard. The /etc/mtree directory stores that standard for the FreeBSD base system. The FreeBSD upgrade process uses mtree records to install the system correctly. If you damage file or directory permissions in your base system, you can use mtree(1) to restore them to the defaults. While you don’t generally need to edit these files, they can be useful if you muck too much with your system. Diskless systems use these files to build memory-based /var filesystems. We’ll use this information in Chapter 19 to inspect system security.

/etc/netconfig

If you’re accustomed to SVR4-derived operating systems, you might expect to configure various parts of networking in /etc/netconfig. FreeBSD uses this file only for RPC code, though. I mention it only to keep old Solaris hands from thinking changes here will help them.

/etc/netstart

This shell script is designed specifically for bringing up the network while in single-user mode. Having a network in single-user mode is terribly useful for any number of reasons, from mounting NFS shares to connecting to remote machines in order to verify configurations. Just run /etc/netstart. This script has no effect when in full multiuser mode.

/etc/network.subr

This shell script isn’t intended for human use; rather, other network configuration scripts use the subroutines defined herein to support common functions.

/etc/newsyslog.conf

This file configures the rotation and deletion of log files. See Chapter 21 for more information.

/etc/nscd.conf

The nscd(8) service caches the results of name service lookups to optimize system performance. It’s useful if you’re running LDAP, but for hostname lookups, you’re better off running a local caching resolver.

/etc/nsmb.conf

FreeBSD’s Windows file-share mounting system uses /etc/nsmb.conf to define access to Windows systems, as described in Chapter 13.

/etc/nsswitch.conf

Name Service Switching is covered in Chapters 8 and 20.

/etc/ntp/, /etc/ntp.conf

Keeping correct time on your host simplifies . . . well, everything. The time daemon ntpd(8) uses these files, as Chapter 20 illustrates.

/etc/opie*

One-time Passwords In Everything (OPIE) is a one-time password system derived from S/Key. While still used in a few places, it’s no longer very popular. You can read opie(4) if you’re interested. For the most part, OPIE has been largely replaced by systems like Kerberos, Google Authenticator, and other PAM plug-ins.

/etc/pam.d/*

Pluggable Authentication Modules (PAM) allow the sysadmin to use different authentication, authorization, and access control systems. If you’re using Kerberos, LDAP, or some other centralized authentication system, you’ll need to configure PAM. PAM, unfortunately, fills an entire book on its own. If you’re trapped into going anywhere near PAM, permit me to recommend my book PAM Mastery (Tilted Windmill Press, 2016).

/etc/passwd

This file contains user-visible account information. We talk about the password files in Chapter 9.

/etc/pccard_ether

This script starts and stops removable network cards, such as Cardbus cards and USB Ethernet. Its name is just a leftover of history, when the only cards available were PC Cards. For the most part, devd(8) runs this script as needed, as discussed in Chapter 13.

/etc/periodic.conf and /etc/defaults/periodic.conf

The system’s regular maintenance jobs that create those annoying mails to root are run by periodic(8), which just runs shell scripts stored in /etc/periodic and /usr/local/etc/periodic. Every one of these scripts can be enabled or disabled in /etc/periodic.conf.

periodic(8) runs programs either daily, weekly, or monthly. Each set of programs has its own settings—for example, daily programs are configured separately from monthly programs. These settings are controlled by entries in /etc/periodic.conf. While we show examples from only the daily scripts, you’ll find very similar settings for the weekly and monthly scripts.

daily_output=”root”

If you want the status email to go to a user other than root, list that user’s name here. Unless you have a user whose job it is to specifically read periodic email, it’s best to leave this at the default and forward root’s email to an account you read. You could also give a full path to a file if you prefer and even have newsyslog(8) rotate the periodic log (see Chapter 19).

daily_show_success=”YES”

With this set to YES, the daily message includes information on all successful checks.

daily_show_info=”YES”

When set to YES, the daily message includes general information from the commands it runs.

daily_show_badconfig=”NO”

When set to YES, the daily message includes information on periodic commands it tried to run but couldn’t. These messages are generally harmless and involve subsystems that your system just doesn’t support or include.

daily_local=”/etc/daily.local”

You can define your own scripts to be run as part of the daily, weekly, and monthly periodic(8) jobs. These default to /etc/daily.local, /etc/weekly.local, and /etc/monthly.local, but you can place them anywhere you like.

Each script in the daily, weekly, and monthly subdirectories of /etc/periodic has a brief description at the top of the file, and most have configuration options in /etc/defaults/periodic.conf. Skim through these quickly, looking for things that are of interest to you. The defaults enabled are sensible for most circumstances, but there’s extra functionality you can enable with a simple setting in /etc/periodic.conf. For example, if you use GEOM-based disk features, you’ll find the daily GEOM status messages useful. Since anything I could list here would be obsolete before I could deliver this manuscript, let alone before the book reaches you, I won’t go into detail about the various scripts.

/etc/pf.conf, /etc/pf.os

We cover the basics of the PF packet filter in Chapter 19.

One less-known feature of PF is its ability to identify operating systems by the packets they send. The /etc/pf.os file contains TCP fingerprints for different operating systems, allowing you to write firewall rules such as “Show FreeBSD users my real home page, but show Windows users a page suggesting that they get a real operating system.” See pf.os(5) for more information. I encourage you to peruse this file, if only to drive home how all these network stacks behave so differently.

/etc/phones

Modem users can store phone numbers for remote modems in /etc/phones, aliasing them so that they can just type home instead of the full phone number. Only tip(1) and cu(1) use this file, however, so it’s not as useful as you might think.

/etc/portsnap.conf

Portsnap provides updates for the ports tree, as discussed in Chapter 18.

/etc/ppp/

FreeBSD supports outbound modems with ppp(8). Read the man page for more information.

/etc/printcap

This file contains printer configuration information. Printing on Unix-like systems can be very complicated, especially with the vast variety of printers you can use. Making your FreeBSD machine send print jobs to a print server isn’t hard at all, however. We cover the topic in Chapter 20.

/etc/profile

The /etc/profile files contain the default account configuration information for the /bin/sh shell, much like /etc/csh.* for csh and tcsh users. Whenever a /bin/sh user logs in, he inherits what’s in this file. Users can override /etc/profile with their own .profile. Bash and other sh derivatives also use this file.

While tcsh is the standard FreeBSD shell, sh and derivatives (particularly bash) are quite popular. Keep settings in /etc/profile and /etc/csh.login synchronized to ease troubleshooting in the future—or, better still, set necessary environment variables in a login class (see Chapter 9) so that they affect any shell the user needs.

/etc/protocols

In Chapter 7, we discussed network protocols. The /etc/protocols file lists the various network protocols you might encounter. Remember, a TCP or UDP port number isn’t the same as a protocol number.

/etc/pwd.db

This is the database version of the /etc/passwd file. It contains public information about user accounts, as discussed in Chapter 9.

/etc/rc*

Whenever your system boots to the point where it can execute userland commands, it runs the shell script /etc/rc. This script mounts all filesystems, brings up the network interfaces, configures devfs(5), finds and catalogs shared libraries, and performs all the other tasks required to set up a system. We discussed the FreeBSD startup system in Chapter 4.

Different systems have radically different startup tasks. A terminal server with three 48-port serial cards works completely differently from a web server. Instead of a single monolithic /etc/rc script that handles every task, FreeBSD segregates each startup process into a separate shell script that addresses a specific need.

Additionally, you’ll find a few scripts directly under /etc, such as /etc/rc.firewall and /etc/rc.initdiskless. These scripts were split out on their own years before the current startup system came along, and remain in their historical locations because there isn’t anything to be gained by moving them.

/et/regdomain.xml

Wireless cards are subject to different regulatory rules depending on where in the world they’re used. The cards read regdomain.xml to learn which frequencies they may use and how strongly they’re allowed to transmit. Edit this at your own risk.

/etc/remote

This file contains machine-readable configurations for connecting to remote systems over serial lines. Today, this is of interest only if you use your system as a serial client—for example, if you want to connect to a serial console. We discuss serial consoles in Chapter 4.

/etc/resolv.conf

This file lets you set nameservers, domain search order, and more DNS client settings. See Chapter 8 for the details.

/etc/rpc

Remote Procedure Calls (RPC) is a method for executing commands on a remote computer. Much like TCP/IP, RPC has service and port numbers, and /etc/rpc contains a list of these services and their port numbers. The most common RPC consumer is NFS, discussed in Chapter 13.

/etc/security/

This directory contains configuration information for the audit(8) security utility.

/etc/services

This file contains a list of network services and their associated TCP/IP ports. We discussed /etc/services in Chapter 7.

/etc/shells

This file contains the list of all legitimate user shells, as discussed in Chapter 9.

/etc/skel/

In /etc/skel/, you’ll find shell dotfiles that get copied to the new user accounts.

/etc/snmpd.config

FreeBSD includes a basic SNMP implementation, which we discuss in Chapter 20.

/etc/spwd.db

This file contains the confidential database of the user password file /etc/master.passwd. See Chapter 9 for all the inglorious detail.

/etc/src.conf

This file contains machine instructions for building FreeBSD from source. It’s a parallel of make.conf for the source tree alone. Values set in /etc/make.conf affect building FreeBSD from source as well, though; the difference is that /etc/src.conf affects only building FreeBSD but not ports and packages. See Chapter 18 for all your upgrading needs.

/etc/ssh/

Configure the Secure Shell software suite (SSH) in /etc/ssh. This includes the client ssh(1) and the server sshd(8). Chapter 20 touches on sshd(8).

/etc/ssl/

FreeBSD includes the OpenSSL cryptographic software. Chapter 19 discusses a few basic uses and configuration. The /etc/ssl directory contains most OpenSSL information.

/etc/sysctl.conf

This file contains information on which kernel sysctls are set during the boot process. See Chapter 6.

/etc/syslog.conf, /etc/syslog.conf.d/

This file controls which data goes into your system logs and where those logs are stored. See Chapter 21.

/etc/termcap, /etc/termcap.small

This file contains the settings and capabilities of different terminal types. In the age when terminals came in dozens of different types and vendors released new terminals on an almost daily basis, understanding this file was vital. Now that the world has largely converged on vt100 as a standard, however, the default configuration is suitable for almost everyone.

The termcap file is a symlink to /usr/share/misc/termcap. This file might not be available in single-user mode. FreeBSD offers the /etc/termcap.small file to provide terminal information in single-user mode.

/etc/ttys

This file contains all of the system terminal devices (the windows containing a command prompt). The name is a relic of the time when terminals were physical teletypes, but today most users use the virtual terminals generated by telnet or SSH.

We’ll use this file to set up serial logins in Chapter 23.

/etc/unbound/

FreeBSD ships with the Unbound DNS client. The configuration information goes in /etc/unbound/. Chapter 20 covers setting up Unbound as a local DNS resolver.

/etc/wall_cmos_clock

This isn’t a vital file, but as I went to the trouble of digging up what it does, you get to learn about it. If this file exists, FreeBSD’s time-keeping routines have determined that the hardware’s CMOS clock keeps a time other than Coordinated Universal Time (UTC). If the file is missing, the CMOS clock is set to some other time. It’s documented in adjkerntz(8).

/etc/zfs/

FreeBSD’s ZFS uses this directory to store NFS integration information. We discuss NFS in Chapter 13.

If you can crawl through all of /etc, you’ll be better prepared than most sysadmins. Now let’s add some software to your server.