This article explains configuration files on a Linux system that control user permissions, system applications, daemons, services, and other administrative tasks in a multi-user, multi-tasking environment. These tasks include managing user accounts, allocating disk quotas, managing e-mails and newsgroups, and configuring kernel parameters.

Every Linux program is an executable file holding the list of opcodes the CPU executes to accomplish specific operations. For instance, the ls command is provided by the file /bin/ls, which holds the list of machine instructions needed to display the list of files in the current directory onto the screen.

The behaviour of almost every program can be customized to your preferences or needs by modifying its configuration files.

Is there a standard configuration file format in Linux?

In a word, no. Users who are new to Linux (rightly) feel frustrated that each configuration file looks like a new challenge to figure out. In Linux each programmer is free to choose the configuration file format he or she prefers. Format options range from the /etc/shells file, which contains a list of possible shells separated by a newline, to Apache's complex /etc/httpd.conf file.

What are system configuration files?

The kernel itself may be considered a "program." Why does the kernel need configuration files? The kernel needs to know the list of users and groups in the system, and manage file permissions (that is, determine if a file can be opened by a specific user, according to the permissions, UNIX_USERS). Note that these files are not specifically read by programs, but by a function provided by a system library, and used by the kernel.

For instance, a program needing the (encrypted) password of a user should not open the /etc/passwd file. Instead, it should call the system library function getpw(). This kind of function is also known as a system call. It is up to the kernel (through the system library) to open the /etc/passwd file and after that, search for the password of the requested user.

Most of the configuration files in the Red Hat Linux system are in the /etc directory unless otherwise specified. The configuration files can be broadly classified into the following categories:

Access Files

Linux configuration files - Booting and login/logout

File system

The kernel provides an interface to display some of its data structures that can be useful for determining the system parameters like interrupts used, devices initialised, memory statistics, etc. This interface is provided as a separate but dummy filesystem known as the /proc filesystem. Many system utilities use the values present in this filesystem or displaying the system statistics.

For example, the file /proc/modules lists the currently loaded modules in the system. This information is read by the command lsmod, which then displays it in a human readable format. In the same way, the file mtab specified in the following table reads the /proc/mount file, which contains the currently mounted filesystems.

System administration

Networking

System commands

System commands are meant exclusively to control the system, and make everything work properly. All the programs like login (performing the authentication phase of a user on the console) or bash (providing the interaction between a user and the computer) are system commands. The files associated with them are therefore particularly important. This category has the following files of interest to users and administrators.

Daemons

A daemon is a program running in non-interactive mode. Typically, daemon tasks are related to the networking area: they wait for connections, so that they can provide services through them. Many daemons are available for Linux, ranging from Web servers to ftp servers.

User programs

In Linux (and UNIX in general), there are countless "user" programs. A most common user program config file is /etc/lynx.cfg. This is the configuration file for lynx, the well-known textual browser. Through this file you can define the proxy server, the character set to use, and so on. The following code sample shows a part of the lynx.cfg file that can be modified to change the proxy settings of the Linux system.

These settings apply (by default) to all the users running lynx in their respective shells, unless a user overrides the default config file by specifying --cfg = "mylynx.cfg".

Proxy settings in /etc/lynx.cfg

.h1 proxy


.h2 HTTP_PROXY


.h2 HTTPS_PROXY


.h2 FTP_PROXY


.h2 GOPHER_PROXY


.h2 NEWS_PROXY


.h2 NNTP_PROXY


# Lynx version 2.2 and beyond supports the use of proxy servers that can act as


# firewall gateways and caching servers. They are preferable to the older


# gateway servers. Each protocol used by Lynx can be mapped separately using


# PROTOCOL_proxy environment variables (see Lynx Users Guide). If you have 


# not set them externally, you can set them at run time via this configuration file.


# They will not override external settings. The no_proxy variable can be used


# to inhibit proxying to selected regions of the Web (see below). Note that on


# VMS these proxy variables are set as process logicals rather than symbols, to


# preserve lowercasing, and will outlive the Lynx image.


#


.ex 15


http_proxy:http://proxy3.in.ibm.com:80/


ftp_proxy:http://proxy3.in.ibm.com:80/


#http_proxy:http://penguin.in.ibm.com:8080


#ftp_proxy:http://penguin.in.ibm.com:8080/


.h2 NO_PROXY


# The no_proxy variable can be a comma-separated list of strings defining


# no-proxy zones in the DNS domain name space.  If a tail substring of the


# domain-path for a host matches one of these strings, transactions with that


# node will not be proxied.


.ex


no_proxy:demiurge.in.ibm.com, demiurge

Changing configuration files

When changing a configuration file, make sure that the program using that configuration is restarted if it's not controlled by the system administrator or the kernel. A normal user doesn't usually have privileges to start or stop system programs and/or daemons.

The kernel

Changing configuration files in the kernel immediately affects the system. For example, changing the passwd file to add a user immediately enables that user. Also there are some kernel tunable parameters in the /proc/sys directory on any Linux system. The write-access to all these files is given only to the super-user; other users have only readonly access. The files in this directory are classified in the same manner as the Linux kernel source. Every file in this directory represents a kernel data structure that can be dynamically modified to change the system performance.

NOTE: Before changing any value in any of these files, make sure you know everything about the file to avoid irreparable damage to the system.

Files in the /proc/sys/kernel/ directory:

Daemons and system programs

A daemon is a program that is always running in background, quietly carrying out its task. Common ones are in.ftpd (ftp server daemon), in.telnetd (telnet server daemon), and syslogd (system logging daemon).

Some daemons, while running, keep a close watch on the configuration file and reload it automatically when it changes. But most of the daemons do not reload automatically. We need to "tell" them somehow that the configuration file has changed and that it should be reloaded. This can be achieved (on Red Hat Linux systems) by restarting the services using the service command.

For example, if we have changed the network configuration, we need to issue:

service network restart

NOTE: The services are most commonly the scripts present in the /etc/rc.d/init.d/* directory and are started by the init when the system is booted. So, to restart the service you can also do the following:

/etc/rc.d/init.d/

Start, stop, and status are the values that these scripts take as input to perform the action.

User programs

A user or system program reads its configuration file every time it is launched. Remember, though, that some system programs are spawned when the computer is turned on, and their behaviour depends on what they read in the configuration files in /etc/. So, the first time a user program is started, the default configuration is read from the files present in the /etc/ directory. Later, the user can customise the programs by using rc and . (dot) files as explained in the next section.

User configuration files: . (dot) files and rc files

We have seen how programs can be easily configured. But what if someone does not like the way a program has been configured in /etc/?

A "normal" user cannot simply go into /etc and change the configuration files; they are owned -- from the filesystem's point of view -- by root!

This is why most user programs define two configuration files: the first one at a "system" level, located in /etc/; and the other one, "private" to the user, that can be found in his or her home directory.

For example, in my system I have installed the very useful wget utility. In /etc/ there is an /etc/wgetrc file. In my home directory, there is a file named .wgetrc, which describes my customised configuration (which will be loaded only when I, the user, run the wget command). Other users may also have the .wgetrc file in their home directory (/home/other); this file will be read, of course, only when the user runs the wget command.

In other words, the /etc/wgetrc file provides "default" values for wget, while the /home/xxx/.wgetrc file lists the "customisations" for a certain user.

It is important to understand that this is the "general rule", and is not necessarily true for all cases. A program like pine, for instance, does not have any files in /etc/, but only the custom configuration in the users' home directory, in a file named .pinerc.

Other programs may only have a default configuration file in /etc/, and may not let users "customize" them (it's the case with only a few of the config. files in the /etc dir.).