From SpectLog
Jump to: navigation, search

As configuration in UNIX-like systems is text-based, there are few general approaches to note.

This is just an overview of the "zoo". Once most of the types of beasts are familiar, they are more pleasure to deal with.

Text tables / databases

The most basic approach to text configuration files is to build a table of records:

  • Each record (row) in the file is placed in its own single line.
  • Each field (column) in the record is separated by a sequence of whitespace characters.

Although the format is basic, it is very flexible and can be easily processed by scripting.

While each record in tables or in databases normally have the same number of fields, such text files are far more flexible without breaking consistency. There is a common generic approach to make number of fields (columns) arbitrary. It basically demands only first few fields in the record to be mandatory. Content of these first few fields defines "type of the record" or, in other words, what content can be placed in the remaining fields.

Examples of records (resource records) from (what might be) Google DNS zone file:

;1                 ;2       ;3    ;4     ;5              ;6                    ;7      ;8   ;9   ;10     ;11        86400    IN    SOA 1460673 7200 1800 1209600 300        300      IN    A        345600   IN    NS

The first 4 fields are mandatory and define content of the fields starting from 5th. In fact, content of the fields starting from 5th is precisely defined by only 3rd and 4th fields ("class" and "type" according to DNS standard).

Details go further with variations depending on the application:

  • Rules to ignore blank lines and comments (i.e. lines started by '#' or ';') normally exist.
  • New line character may be escaped (usually by '\').
  • Field separator may actually be anything (i.e. ':' for many key configuration files, ',' in CSV format, etc.).


  • All basic configuration files like /etc/passwd, /etc/exports, /etc/services, /etc/fstab.
  • Records in DNS zone files.

Shell-based configuration

In essence, these configuration files are simple shell-scripts. This is the key point which tells everything about their syntax.

Normally, they only assign variables and surely contain no commands which are expected to fail. Such files are included inside real shell scripts (sourced by source or '.' command). Real shell scripts are more complex and executed from command line (x-permission is not set on "configuration shell-scripts").


  • Network interface configuration in /etc/sysconfig/network-scripts/ifcfg-* files.
  • Numerous system configuration in /etc/sysconfig/* files.

Generalization of approach

Inclusion of one file into others is supported by almost any computer language in one way or another. Therefore, approach is universal and is not just shell-based.

For example,

  • Apache HTTP server by additional configuration files in /etc/httpd/conf.d directory;
  • YUM configuration includes files from /etc/yum.repos.d/ directory;
  • makefile may include file with dependencies to configure build process;
  • C-program can be configured by including header files during compile-time which affects generated code.

CLI-driven configuration

CLI (Comman Line Interface) of tools may impose associated configuration file format.

Such configuration files simply contains lines which are fed to the tool without any modification as part of command line arguments. Therefore, if the CLI of the tool is well known, configuration format is well known too.

For example, firewall configuration based on iptables in /etc/sysconfig/iptables.

XML-based configuration

XML is described by itself. Apparently, that was the motivation behind the standard.

Because of its flexibility, it is also complex to parse and to be strictly followed. Simple light weight tools avoid reliance on this format. Everything else in the bottom of the system supports high-level services which often use XML.


  • Virtualization configuration (libvirt).
  • GNOME desktop configuration.

"Ergonomics" of XML is far from perfect. Humans just agreed on common format which is the only achievement. All those automated aspects are to be created manually anyway.

Custom syntax

Anything else is not worth categorizing it. This is usually custom syntax with specific grammar.


  • Apache HTTP server.
  • DHCP server, BIND DNS server.