System Configuration | Beginning Fedora 2

What do you think of when you hear the term system configuration? If you were to pose that exact same question to a group of people, you would most likely get entirely different responses. System configuration encompasses such a broad area of system administration that it is difficult to cover all aspects. And so, we will concentrate on configuration related to users and login, hardware, booting up and startup services, networking, and security. Even though numerous applications will allow you to manipulate system configuration through a graphical interface, you will have better control of the system if you know where the configuration information is stored and how to modify it manually when necessary.

Depending on the operating system, the configuration information is stored in different locations. For example, Microsoft Windows stores most configuration data in the Registry, while Mac OS stores it in separate binary files in a special Preferences folder. Where does Linux store the configuration details? For the most part, Linux, by which we mean the core components as well as individual applications, stores the information in plain text files in the /etc directory or in one of its subdirectories. This gives it a number of advantages over the other operating systems:

You can read and edit the information easily with a text editor.
You can back up the files consistently.
You can maintain version control, thereby keeping track of all changes.

Unfortunately, because each component or application stores its configuration information individually in a separate file, there are bound to be differences in syntax between them. However, a majority of the files have a syntax that is easy to understand, as you will see in a moment.

Example: Finding the DNS Server

For example, perhaps you entered a DNS server address when you were installing the operating system in Chapter 1. That DNS server address forms part of the system s configuration, and its value is stored in the appropriate configuration file under the /etc directory hierarchy.

If you take a look at the /etc directory, you ll see that there are quite a lot of configuration files there. Which one contains the DNS server configuration? If you know the DNS server address, one way to find out is to use the grep command to search for the file that contains that address. For example, if you used the primary name server address 192.168.1.1 , you can find the correct configuration file via the following command:

   # grep -ri 192.168.1.1 /etc   /etc/resolv.conf:nameserver 192.168.1.1

The output from this command points you in the direction of the file /etc/resolv.conf ”in fact, it is this file that holds all the DNS server information. You can take a look at this file using a text editor such as gedit :

   # gedit /etc/resolv.conf

You ll see that it is simply a text file with the following format:

 nameserver 192.168.1.1   ## primary nameserver 192.168.1.2   ## secondary, etc.

Let s take a look at some more configuration files.

Configuration Files

We mentioned that a large number of configuration files are contained in the /etc directory hierarchy. They re stored in a tree structure.

We can t possibly mention them all here, but in the next few pages we will cover some of the configuration files that you re most likely to find important. You should take some time to explore these files to see what information they contain, either using the cat , more or less commands, or an editor of some sort ; just be careful not to accidentally modify or delete any information.

/etc/X11/xorg.conf

The xorg.conf configuration file (named XF86Config in previous versions of Red Hat Linux) controls specific aspects of the X Window system (X11) server, from keyboard and mouse to monitor. This file is essential if X11 is to work properly on your system.

Note	While it is generally possible to modify configuration files by hand, we recommend that you don t try it with this one because its configuration is quite difficult. It is best to use the following Fedora Core GUI applications to manipulate the information in this file:

system-config-display (Main Menu > System Settings > Display)
system-config-keyboard (Main Menu > System Settings > Keyboard)
system-config-mouse (Main Menu > Preferences > Mouse)

/etc/aliases

The aliases configuration file contains aliases for mail users and is used by the sendmail application discussed in Chapter 9. For example, you can set up an alias such that all mail sent to the alias mickeymouse is forwarded to the system administrator:
```
   mickeymouse: root   
```

Whenever you modify this file manually, you must also run the newaliases application (located in /usr/bin ) for the changes to take effect.

Note	The postfix mail transport application, an alternative to sendmail , has a similar configuration file, which is located at /etc/postfix/aliases .

/etc/bashrc and /etc/csh. cshrc

These two configuration files set the defaults (file creation masks/permissions, shell prompts, and so on) that are used by all bash and csh shell users upon starting a new shell.

/etc/crontab

This file is a configuration file for the cron daemon ( crond ) , which allows you to execute automated tasks , tasks that run unattended at specified times. Once a minute, the cron daemon checks for changes in the crontab file (and also in the /etc/cron.d directory and the /var/spool/cron directory), and reloads them into memory as necessary.

The following is a crontab entry that records the system load averages into a file every hour from 8:00 pm until 11:00 pm on Mondays:

 min hour  day  mon  weekday  command   00  20-23 *    *    01       /usr/bin/uptime >> /var/log/load.log

You don t need root privileges to set up automated tasks using the crontab application. Any user can edit his or her own crontab entries via the command crontab -e . There s more about the cron daemon in Chapter 6.

/etc/default/useradd

This file sets the default parameters that are used whenever a new user is created. For example, if you want all new users to have the C shell by default, you would change the SHELL directive in the useradd configuration file, so that it reads as follows :

   SHELL=/bin/csh

/etc/fstab

The fstab file contains the filesystem table , which is a table of all disk partitions and their mount points and default mount options. You can use this file to tell Linux about any and all filesystems to which the machine has access.

/etc/group

This configuration file lists the group names and group IDs (GIDs) of all the groups of users known to the system. Groups are important in Fedora Core ”indeed, every user must be associated with at least one group. See Chapter 7 for a more detailed discussion of users and groups.

If you don t want to deal with this file directly, you can use the system-config-users GUI application (Main Menu>System Settings>Users and Groups).

/etc/grub.conf

The grub.conf configuration file is used at the time you start your system (unless you specified LILO). When you start your system, the first program that runs is the grand unified bootloader (GRUB). The GRUB is responsible for transferring control to the Linux kernel. The grub.conf file found in the /etc directory is, in fact, a symbolic link to the file /boot/grub/grub.conf ”which, in turn , specifies the path to the kernel and the root partition.

Here is an example of what you might find in a grub.conf file:

   title Fedora Core (2.6.5-1.358)     root (hd0,0)     kernel /boot/vmlinuz-2.6.5-1.358 ro root=LABEL=/ rhgb     initrd /boot/initrd-2.6.5-1.358.img

In Chapter 12, when we build our own custom kernel, we will modify the grub.conf file to point to our new kernel.

/etc/ hosts

The hosts file allows you to set up aliases for local and remote hosts. This is a very powerful feature that can simplify host name lookups. For example, if you wanted to force all of your users to go to www.google.com when they enter google , simply add this record to the hosts file:

   216.239.53.99 google

The IP address 216.239.53.99 is one of many IP addresses assigned to www.google.com . You can use the ping command to verify that the alias has taken effect:

   $ ping google   PING www.google.com (216.239.53.99) from 192.168.254.2: 56(84) bytes of data. 64 bytes from www.google.com (216.239.53.99): icmp_seq=1 ttl=45 time=72.5 ms ...

Note	Note that this will not work properly with network applications that perform their own DNS lookups, such as the Lynx text browser.

/etc/hosts.allow and /etc/hosts.deny

The hosts.allow file specifies (by name or IP address) the hosts that are allowed access to local TCP/IP services. By default, all other hosts are denied access. Or, you can specifically list the hosts for which you want to deny access in the hosts.deny file.

Suppose you want to control access to your server through the telnet protocol. Specifically, suppose you want to allow access only to remote users from the host www.wrox.com and to local users. To achieve this, you would specify this line in hosts.allow :

   telnetd: LOCAL, 192.168.1., www.wrox.com

And specify this line in hosts.deny :

   telnetd: ALL

All entries listed in hosts.allow take precedence over any entries in hosts.deny .

Note	Note that you can use this access control mechanism only if tcp_wrappers (the /usr/sbin/tcpd server) is enabled for that specific service. See the xinetd.d entry later in this section for more information.

/etc/init.d

This is a symbolic link to a directory that contains a number of startup scripts . The startup scripts perform a number of functions, including initialization of network connections and startup of server daemon processes. For example, the file /etc/init.d/crond implements functionality to start, stop, restart, and reload the cron daemon.

Not all of the scripts in this directory are executed when you start the system. Rather, execution is governed by the system s run level . We discussed run levels in Chapter 2 ”as you ll recall, the run levels (0 “6) are represented by the directories /etc/rc.d/rcX.d . Each of these directories contains symbolic links to the chosen scripts in the init.d directory. If you want a particular application or process to run within a particular run level, you can simply add a symbolic link to that application to the corresponding run level directory.

/etc/inittab

The inittab configuration file is probably the single most important file in the system ”it controls the initialization process that occurs when you start the system. It is responsible for starting the init process. It contains a line to set the default run level to be used:

   id:3:initdefault:

This line sets the run level to 3 (see Chapter 2 for more information on the different run levels). If you want to start your system with an X Window system interface, you can simply change this to run level 5:

   id:5:initdefault:

/etc/issue and /etc/issue.net

The issue and issue.net configuration files contain the text that is displayed when you start a terminal session. Typically, this message contains the Fedora Core release number and the kernel identification. The only difference between these two files is that issue.net is displayed only to remote users who log in to the system, whereas the contents of issue are displayed to local users only.

/etc/ld.so.conf

This file contains a list of directories in which shared libraries ( *.so ) can be found. The information in this file is used by the ldconfig application to create the necessary links and cache to these libraries, so that development tools (such as the dynamic linker) can find them. You need to run ldconfig whenever you add, remove, or change the entries in this file.

/etc/logrotate.conf

This file contains information that controls the rotation of log files and is used in conjunction with the logrotate application.

The main reasons for rotating log files are to keep them organized and to limit their size. If you don t control the size of your log files, your backups take longer, and you also run the risk of your disk space filling up unexpectedly.

Moreover, when something goes wrong with the system, examination of the log files often helps to trace the cause of the problem. But if the log files get too large, this examination process becomes more difficult ”and finding the problem is like searching for the proverbial needle in a haystack.

So the idea is that you rotate your log files periodically, or when a log file reaches a specified size. The logrotate application (located in /usr/sbin ) does the work; to do so it uses the rotation time interval or file-size limits specified in logrotate.conf .

In fact, the /etc/cron.daily directory contains a simple script called logrotate , which invokes the following command to rotate the logs:

   /usr/sbin/logrotate /etc/logrotate.conf

If you look at the crontab file, you will see that all the scripts in cron.daily are configured to run at 4:02 AM every day:
```
   02 4   *   *   *   root   run-parts /etc/cron.daily   
```

/etc/ modprobe .conf

The modprobe.conf configuration file (named modules.conf in Red Hat Linux 9) tells the kernel (or more specifically, the modprobe and depmod applications) which modules to load on demand.

For example, if you want to use the tulip driver to handle your Ethernet/network card, you add the following line to the modprobe.conf file:

   eth0 tulip

Of course, this assumes that the tulip driver ( tulip.ko ) exists in the /lib/modules/2.6.5-1.358 directory; this directory contains the modules for the Linux kernel 2.6.5-1.358. You can use the following command to check that the driver exists:

 # find /lib/modules/ -name 'tulip.ko'   /lib/modules/2.6.5-1.358/kernel/drivers/net/tulip/tulip.ko

Note	Chapter 12 discusses the modular nature of the Linux kernel, and the Linux Loadable Kernel Modules (LKM).

/etc/passwd

The passwd configuration file stores the account information (including the username, full name, and path to the home directory and default shell) for every user on the system. You can use the system-config-users application (Main Menu>System Settings>Users and Groups) if you do not feel comfortable modifying the contents of this file. See Chapter 7 for more information on adding users and groups.

/etc/rc

The rc file and the files in the rc.d directory control what applications and services run at specific run levels. The rc.d directory contains a number of subdirectories ”each subdirectory represents a run level from 0 “6. These subdirectories, in turn, contain symbolic links to startup scripts in the init.d directory (see the previous entry for init.d ).

The rc file itself is responsible for starting and stopping services when a run level changes.

/etc/resolv.conf

We discussed the resolv.conf file at the beginning of this chapter.

/etc/security

The security directory contains a list of configuration files that impose restrictions on various resources. This includes information about who can log in and from which location(s) they can log in, the privileges that console users are given, and resource limits for all users.

For example, if you want to increase the hard limit for resources allocation (that is, the number of file descriptors) to all users from 1024 to 8192, you could add the following lines to limits.conf :

   *       soft    nofile  1024     *       hard    nofile  8192

This change, along with the following change to /etc/pam.d/login , will allow users to increase their file descriptor limits:

   session    required     pam_limits.so

At this point, users can increase their limits up to their allocated hard limits by issuing the following command:

   $ ulimit -n unlimited

Typically, you would increase resource limits for users and processes that are under a heavy and constant load, such as the Web server process.

/etc/shadow

If shadow passwords are enabled, the shadow configuration file contains encrypted passwords for all users listed in the passwd file. This is a more secure approach because the shadow file is readable only by root. See Chapter 7 for more information on users and passwords.

/etc/ shells

This file can be used to list all the valid shells on the system. The chsh command, which allows users to change their default shell, makes use of this list. Historically it has been used to restrict access: network services such as FTP daemons have required users logging in to have a valid shell. With no valid shell, access is denied.

/etc/skel

The skel directory contains a list of files that will be copied to a user s directory when the user is first created. This allows you to provide each user with a set of default resources, such as scripts, and configuration and data files.

/etc/sysconfig

The sysconfig directory is critical. It consists of important configuration files used by various applications, including hardware and network configuration applications and tools.

For example, consider the information stored within the /etc/sysconfig/network file and the files in the /etc/sysconfig/network-scripts directory. This information specifies how the system is connected to an external network. Or, take a look at the hwinfo file, which keeps track of the system hardware and devices, and the iptables configuration file, which lists the firewall rules.

/etc/sysctl.conf

This is a highly powerful configuration file that allows you to configure kernel parameters at runtime. For example, to increase the number of file descriptors system-wide from 8,192 to 32,768, you would insert the following entry into this file:

   fs.file-max=32768

Some of these kernel parameters can also be changed by modifying the relevant files in the /proc directory.

/etc/syslog.conf

The syslog.conf configuration file is the main driver for the syslogd daemon, which is responsible for logging information. For example, take a look at the following entry in the configuration file:

   *.info;mail.none;authpriv.none;cron.none      /var/log/messages

This directive instructs the syslogd daemon to log all messages that have a severity level greater than that of an information-only message (with the exception of mail , authentication , and cron -related messages) to /var/log/messages .

Various administrative log files are examined later in this chapter, including the /var/log/messages log file previously mentioned.

/etc/xinetd.conf

Finally, the xinetd.conf configuration file configures the services provided by the xinetd daemon, which include FTP and telnet. In fact, the xinetd.d directory contains a configuration file for each service. Each of these configuration files looks something like this:

   service telnet     {     flags           = REUSE NAMEINARGS     protocol        = tcp     socket_type     = stream     wait            = no     user            = root     server          = /usr/sbin/tcpd     server_args     = /usr/sbin/in.telnetd     log_on_failure += USERID     }

We discussed the tcp_wrappers application as a means to implement access control earlier in this section. Incidentally, the preceding configuration file uses tcp_wrappers, as signified by the /usr/sbin/tcpd server setting. This server provides the access control for each incoming request and, if the request is successful, invokes the application specified by the server_args argument ”telnet daemon in this case.

The next section looks at the various administrative log files so you can better understand what is happening with your system.