System Configuration Files

A major problem with configuration files under Unix is that there are so many of them in so many places. On a multiuser system that provides a variety of services, there may be scores of configuration files scattered among dozens of directories. Even worse, it seems that every implementation of Unix is different. Even different releases of the same flavor of Unix may vary. Add to this the complications that multiple applications contribute and you have a major undertaking. If you are running a number of different platforms, you have your work cut out for you. For these reasons, it is unrealistic to attempt to give an exhaustive list of configuration files. It is possible, however, to discuss configuration files by categories. The categories can then serve as a guide or reminder when you construct your own lists so that you don't overlook an important group of files. Just keep in mind that what follows is only a starting point. You will have to discover your particular implementations of Unix one file at a time.

Basic Configuration Files

There are a number of fairly standard configuration files that seem to show up on most systems. These are usually, but not always, located in the /etc directory. (For customization, you may see a number of files in the /usr/local or /usr/opt directories or their subdirectories.) When looking at files, this is clearly the first place to start. Your system will probably include many of the following: defaultdomain, defaultroute, ethers, gateways, host.conf, hostname,hosts, hosts.allow, hosts.equiv, inetd.conf, localhosts, localnetworks, named.boot, netmasks, networks, nodename, nsswitch.conf, protocols, rc, rc.conf, rc.local, resolv.conf, andservices. You won't find all of these on a single system. Each version and release will have its own conventions. For example, Solaris puts the host's name in nodename.[7] With BSD, it is set in rc.conf. Customizations may change these as well. Thus, the locations and names of files will vary from system to system.
[7]The hostname may be used in other files as well so don't try to change the hostname by editing these files. Use the hostname command instead.
One starting point might be to scan all the files in /etc and its subdirectories, trying to identify which ones are relevant. In the long run, you may want to know the role of all the files in /etc, but you don't need to do this all at once. There are a few files or groups of files that will be of particular interest. One of the most important is inetd.conf. While we can piece together what is probably being handled by inetd by using ps in combination with netstat, an examination of inetd.conf is usually much quicker and safer. On an unfamiliar system, this is one of the first places you will want to look. Be sure to compare this to the output provided by netstat. Services that you can't match to running processes or inetd are a cause for concern. You will also want to examine files like host.conf, resolv.conf, and nsswitch.conf to discover how name resolution is done. Be sure to examine files that establish trust relationships like hosts.allow. This is absolutely essential if you are having, or want to avoid, security problems. (There is more on some of these files in the discussion of tcpwrappers in "Miscellaneous Tools".) Finally, there is one group of these files, the rc files, that deserve particular attention. These are discussed separately in the later section on startup files and scripts.

Configuration Programs

Over the years, Unix has been heavily criticized because of its terse command-line interface. As a result, many GUI applications have been developed. System administration has not escaped this trend. These utilities can be used to display as well as change system configurations. Once again, every flavor of Unix will be different. With Solaris, admintool was the torchbearer for years. In recent years, this has been superseded with Solstice AdminSuite. With FreeBSD, select the configure item from the menu presented when you run /stand/sysinstall. With Linux you can use linuxconf. Both the menu and GUI versions of this program are common. The list goes on.

Kernel

It's natural to assume that examining the kernel's configuration might be an important first step. But while it may, in fact, be essential in resolving some key issues, in general, it is usually not the most productive place to look. You may want to postpone this until it seems absolutely necessary or you have lots of free time. As you know, the first step in starting a system is loading and initializing the kernel. Network services rely on the kernel being configured correctly. Some services will be available only if first enabled in the kernel. While examining the kernel's configuration won't tell you which services are actually being used, it can give some insight into what is not available. For example, if the kernel is not configured to forward IP packets, then clearly the system is not being used as a router, even if it has multiple interfaces. On the other hand, it doesn't immediately follow that a system is configured as a firewall just because the kernel has been compiled to support filtering. Changes to the kernel will usually be required only when building a new system, installing a new service or new hardware, or tuning system performance. Changing the kernel will not normally be needed to simply discover how a system is configured. However, changes may be required to use some of the tools described later in this tutorial. For example, some versions of FreeBSD have not, by default, enabled the Berkeley packet filter pseudodriver. Thus, it is necessary to recompile the kernel to enable this before some packet capture software, such as tcpdump, can be run on these systems. To recompile a kernel, you'll need to consult the documentation for your operating system for the specifics. Usually, recompiling a kernel first requires editing configuration files. This may be done manually or with the aid of a utility created for this task. For example, with Linux, the command make config runs an interactive program that sets appropriate parameters.[8] BSD uses a program called config. If you can locate the configuration files used, you can see how the kernel was configured. But, if the kernel has been rebuilt a number of times without following a consistent naming scheme, this can be surprisingly difficult.
[8]You can also use make xconfig or make menuconfig. These are more interactive, allowing you to go back and change parameters once you have moved on. make config is unforgiving in this respect.
As an example, on BSD-derived systems, the kernel configuration files are usually found in the directory /sys/arch/conf/kernelwhere arch corresponds to the architecture of the system and kernel is the name of the kernel. With FreeBSD, the file might be /sys/i386/conf/GENERIC if the kernel has not been recompiled. In Linux, the configuration file is config in whatever directory the kernel was unpacked in, usually /usr/src/linux/. As you might expect, lines beginning with a # are comments. What you'll probably want to look for are lines specifying unusual options. For example, it is not difficult to guess that the following lines from a FreeBSD system indicate that the machine may be used as a firewall: 

# Firewall options options IPFIREWALL options IPFIREWALL_VERBOSE_LIMIT=25 ...


Some entries can be pretty cryptic, but hopefully there are some comments. The Unix manpages for a system may describe some options. Unfortunately, there is very little consistency from one version of Unix to the next on how such files are named, where they are located, what information they may contain, or how they are used. For example, Solaris uses the file /etc/system to hold some directives, although there is little of interest in this file for our purposes. IRIX keeps its files in the /var/sysgen/system directory. For Linux, take a look at /etc/conf.modules. The list goes on.[9]
[9]While general configuration parameters should be in a single file, a huge number of files are actually involved. If you have access to FreeBSD, you might look at /sys/conf/files to get some idea of this. This is a list of the files FreeBSD uses.
It is usually possible to examine or change selected system parameters for an existing kernel. For example, Solaris has the utilities sysdef, prtconf, and ndd. For our purposes, ndd is the most interesting and should provide the flavor of how such utilities work. Specifically, ndd allows you to get or set driver configuration parameters. You will probably want to begin by listing configurable options. Specifying the driver (i.e., /dev/arp, /dev/icmp, /dev/ip, /dev/tcp, and /dev/udp) with the ? option will return the parameters available for that driver. Here is an example: 

sol1# ndd /dev/arp ? ? (read only) arp_cache_report (read only) arp_debug (read and write) arp_cleanup_interval (read and write)


This shows three parameters that can be examined, although only two can be changed. We can examine an individual parameter by using its name as an argument. For example, we can retrieve the ARP table as shown here: 

sol1# ndd /dev/arp arp_cache_report ifname proto addr proto mask hardware addr flags elxl0 205.153.060.053 255.255.255.255 00:e0:29:21:3c:0b elxl0 205.153.060.055 255.255.255.255 00:90:27:43:72:70 elxl0 205.153.060.001 255.255.255.255 00:00:a2:c6:0e:42 elxl0 205.153.060.005 255.255.255.255 00:90:27:9c:2d:c6 elxl0 205.153.060.248 255.255.255.255 00:60:97:58:71:b7 PERM PUBLISH MYADDR elxl0 205.153.060.150 255.255.255.255 00:c0:05:04:2d:78 elxl0 224.000.000.000 240.000.000.000 01:00:5e:00:00:00 PERM MAPPING


In this instance, it is fairly easy to guess the meaning of what's returned. (This output is for the same ARP table that we looked at with the arp command.) Sometimes, what's returned can be quite cryptic. This example returns the value of the IP forwarding parameter: 

# ndd /dev/ip ip_forwarding 0


It is far from obvious how to interpret this result. In fact, means never forward, means always forward, and means forward only when two or more interfaces are up. I've never been able to locate a definitive source for this sort of information, although a number of the options are described in an appendix to W. Richard Stevens' TCP/IP Illustrated, vol. 1. If you want to change parameters, you can invoke the program interactively. Other versions of Unix will have their own files and utilities. For example, BSD has the sysctl command. This example shows that IP forwarding is disabled: 

bsd1# sysctl net.inet.ip.forwarding net.inet.ip.forwarding: 0


The manpages provide additional guidance, but to know what to change, you may have to delve into the source code. With AIX, there is the no utility. As I have said before, the list goes on. This brief description should give you a general idea of what's involved in gleaning information about the kernel, but you will want to go to the appropriate documentation for your system. It should be clear that it takes a fair degree of experience to extract this kind of information. Occasionally, there is a bit of information that can be obtained only this way, but, in general, this is not the most profitable place to start. One last comment -- if you are intent on examining the behavior of the kernel, you will almost certainly want to look at the messages it produces when booting. On most systems, these can be retrieved with the dmesg command. These can be helpful in determining what network hardware your system has and what drivers it uses. For hardware, however, I generally prefer opening the case and looking inside. Accessing the CMOS is another approach for discovering the hardware that doesn't require opening the box.

Startup Files and Scripts

Once the kernel is loaded, the swapper or scheduler is started and then the init process runs. This process will, in turn, run a number of startup scripts that will start the various services and do additional configuration chores. After the standard configuration files, these are the next group of files you might want to examine. These will primarily be scripts, but may include configuration files read by the scripts. In general, it is a bad idea to bury configuration parameters within these scripts, but this is still done at times. You should also be prepared to read fairly cryptic shell code. It is hoped that most of these will be either in their pristine state, heavily commented, or both. Look for three things when examining these files. First, some networking parameters may be buried in these files. You will not want to miss these. Next, there may be calls to network configuration utilities such as route or ifconfig. These are frequently customizations, so read these with a critical eye. Finally, networking applications such as sendmail may be started from these files. I strongly urge that you create a list of all applications that are run automatically at startup. For systems derived from BSD, you should look for files in /etc beginning with rc. Be sure to look at rc.conf and any rc files with extensions indicating a networking function of interest, e.g., rc.firewall. Realize that many of these will be templates for services that you may not be using. For example, if you see the file rc.atm, don't be too disappointed when you can't find your ATM connection. Unix systems can typically be booted in one of several different states or run levels that determine which services are started. For example, run level 1 is single-user mode and is used for system maintenance. The services started by the different run levels vary somewhat among the different flavors of Unix. If your system is derived from System V, then the files will be in a half dozen or so directories in /etc. These are named rc1.d, rc2.d, and so forth. The digit indicates the run level of the system when booted. Networking scripts are usually in rc2.d. In each directory, there will be scripts starting with an S or a K and a two-digit number. The rest of the name should give some indication of the function of the file. Files with names beginning with an S are started in numerical order when the system is rebooted. When the system shuts down, the files with K are run. (Some versions of Linux, such as Red Hat, follow this basic approach but group these directories together in the /etc/rc.d directory. Others, such as Debian, follow the System V approach.)
WARNING: There is one serious catch with all this. When versions of operating systems change, sometimes the locations of files change. For backward compatibility, links may be created to old locations. For example, on recent versions of Solaris, the network configuration file /etc/hosts is actually a link to /etc/inet/hosts. There are other important network configuration files that are really in /etc/inet, not /etc. Similarly, some of the startup scripts are really links to files in /etc/init.d. If the link is somehow broken, you may find yourself editing the wrong version of a file and wondering why the system is ignoring your changes.

Other Files

There are several other categories of files that are worth mentioning briefly. If you have been following the steps just described, you will already have found most of these, but it may be worth mentioning them separately just in case you have overlooked something.

Application files

Once you have your list of applications that are started automatically, investigate how each application is configured. When it comes to configuration files, each application will follow its own conventions. The files may be grouped together, reside in a couple of directories, or have some distributed structure that spans a number of directories. For example, sendmail usually keeps configuration files together, usually in /etc or in /etc/mail. DNS may have a couple of files in /etc to get things started, with the database files grouped together somewhere else. A web server like apache may have an extensive set of files distributed across a number of directories, particularly if you consider content. But beware, your particular implementation may vary from the norm -- in that case, all bets are off. You will need to look for these on an application-by-application and a system-by-system basis.

Security files

It is likely you will have already discovered relevant security files at this point, but if you are having problems, this is something worth revisiting. There are several different categories to consider:

Log files

One last category of files you might want to consider is log files. Strictly speaking, these are not configuration files. Apart from an occasional startup message, these may not tell you very much about your system's configuration. But occasionally, these will provide the missing puzzle piece for resolving a problem. Log files are described in much greater detail in "Miscellaneous Tools".