1. Introduction

The configuration of a Unix/Linux computer is done through a collection of editable (ASCII) files located mostly under the /etc directory tree. On a local network most computers are configured in an identical or at least a very similar way: they will have the same base of users, use the same software, implement the same security strategy... . One of the network administrator's duties is to maintain these configuration files and keep them up to date. When the configuration files are identical it is useful if they can all be maintained centrally from a master file.

The Network Information Service (NIS is also known as the yellow pages) addresses this issue for a few files like the /etc/passwd file for example: the data are stored centrally in a database and computers query this database instead of reading the local file. One of the limitations of NIS is that it can only be used for the files for which it has been designed. One can easily create other NIS tables, but for a computer to consult the NIS server for these new tables, one would usually have to modify some internal libraries. Another limitation of the NIS entry is that it only works for files that are identical for all computers, or at best, the data stored in the NIS table can be added to the content of the local file (like the passwd file for example).

1.1 Managing system files across a network

There are many configuration files that are not implementable as NIS tables but that would benefit from being maintained centrally. sysf (pronounced sys-ef) is a tools designed to do this. The administrator choses which system files he or she wants to maintain with sysf (as described below) and use the tool to archive the configuration files for each host keeping only one copy of the files when its content is the same for a group of hosts.

WARNING: sysf is an administration tools which can modify important system files across an entire network. Configuring or using sysf without a detailed understanding of how it works can seriously damage vital files on many hosts at once. Although sysf has been thoroughly tested by its author there is no guarantee that it is entirely bug free. It is thus recommended that every user tests new configurations on dummy files before deploying them on a real system.

Here are a few examples of files that can be managed with sysf:

• syslog.conf : this file sets how error messages are logged on the system (what to log, what to dismiss, and where to log it). Administrators usually spend a fair amount of time thinking this through then stick to the same policy, but make some changes occasionally. Most computers will be configured in the same way and thus have identical syslog files (though some servers might be configured slightly differently). When using sysf one would archive the file syslog.conf.DEFAULT that the majority of hosts would share except for those that have their own file which would be called for example syslog.conf.trovald for the host trovald or syslog.conf.SERVERS for all the hosts belonging to a group called SERVERS (sysf defines its own group of hosts in a dedicated file). If a change is required in some of the syslog.conf file, the administrator only has to edit the few files that needs changing and execute the command

      # sysf -I syslog.conf -h ALL
  

  This will copy the correct syslog.conf file on every hosts where it has changed and restart the syslog daemon.
• /root/.cshrc and /root/.bashrc: the files contain the standard shell setup for root as well as the definition of useful aliases. The files are usually identical on all computers. Sourcing a file on a common file-system can do the trick but this will cause problems when there are network troubles and do nothing when one boots in single user mode so this should not be done for root. Only one files need to be archived for the whole network. If the administrator decides to add an alias or variable definition in one of these files, he/she only has to edit the archived file (which from now on we will refer to as the config file) and execute the command

      # sysf -I root_cshrc -h ALL
  

  to copy the file on every host on the network.
• /root/.rhosts : the files lists the computers from which root can login remotely (rlogin, rsh ...) without entering a password. In many cases one wants to make sure that such a file does not exist or if it does that it contains a very limited list of hosts. sysf can be used to ensure that the file only exists on the desired hosts and, when it does exist, make sure it has the correct content. The command

      # sysf -I root_rhosts -h ALL
  

  will remove the file /root/.rhosts on every host where it should not exists and update the content of the files where it has changed.
• /etc/printcap : in an environment of networked printers, many computers will share the same printcap file while some computers will have a different one as those that have a local printer attached to them will require an extra printcap entry. Nevertheless, many computers are likely to have identical files. For example if there are two classrooms of computers say RoomA and RoomB each having their own printer, the computer in each room will share the same printcap file each having an entry for the default printer, say lp, referring to the printer physically located in that room. Thus one would like to have two centrally managed files, printcap.RoomA and printcap.RoomB, that will be installed on the corresponding computers. To update them one would use the command

      # sysf -I printcap -h RoomA,RoomB
  

  to copy the modified printcap files and to restart the lpd daemon on every hosts in the two rooms.
• /etc/rc.d/rc3.d : the directory contains the script files that are executed at boot time to run various services. Under most version of Unix/Linux these script files are symbolic links to the corresponding script files in /etc/rc.d/init.d. sysf can be used to maintain these links, making sure that no extra file or links are created and that none are missing either.
• /etc/X11/XF86Config : under Linux this file contains configuration parameters for the X library related to the type of video card and monitor. This file is usually different on every computer, but for computers fitted with the same hardware, the same file can be used.

To manage these files centrally, we make a copy of each of them in a shared directory (typically /usr/local/sys/config) which we will now refer to as the config directory. We also add a suffix to their name to distinguish the host they belong to. For example, the file XF86Config.trovald, printcap.RoomA and root_cshrc.DEFAULT will be respectively the XF86Config file for the host trovald, the printcap file for all the computers in the classroom A and the /root/.cshrc file shared by all computers. To check that the config file root_cshrc.DEFAULT is identical to the system file /root/.cshrc on every host one executes the command

    # sysf -check root_cshrc -h ALL

    # sysf -check XF86Config -h MATROX

As the number of files to maintain can become quite large, the files are split in different categories each of which correspond to a sub-directory of the config directory.

In what follows we will refer to the actual Unix/Linux files (/etc/printcap) as the system files and to their archived copies (/usr/local/sys/config/printing/printcap.DEFAULT) as the config files.

The suffix used for the config files can be of four different types:

• A host-name implies that the file is specific to that host. For example the file XF86Config.trovald belong to the host trovald.
• A group of hosts (defined in the configuration file hosts.conf) indicates that the file is used for any member of that group. In the printcap example above, the groups RoomA and RoomB would contain the names of all the computers located in the corresponding room and the files printcap.RoomA and printcap.RoomB will be the corresponding printcap files.
• The word DEFAULT implies that the file must be used for any host for which there is no specific and no host group file. For example the file root_cshrc.DEFAULT will be the default /root/.cshrc file. If a host, say cox, needs a different one, one just saves the file for that host as root_cshrc.cox. Notice that in this case we use the name root_cshrc instead of .cshrc to make the config file "visible".
• The suffix SHARED is used for files that are stored on an NFS mounted partition indicating that every host actually sees the same file.

sysf determines the actual config file as follow. First it searches for the config file CONFIG_NAME.HOST_NAME for the current host where the config name is the name in the fourth column of the file sysf.conf for the corresponding entry. Then it searches for the file CONFIG_NAME.HOST_GROUP for all the host groups to which the the current host belongs in the order they are defined in the file hosts.conf, taking the first one it finds. If none are found, then the config file is taken as CONFIG_NAME.DEFAULT.

To avoid having a very large number of files in the same directory, the configuration files are split in different categories each of which has its own directory (the group directory in the config directory). For example the group directory X11 contains all the files related to the X library, filesys contains the files related to the file system (fstab, exports, auto.home ...) and security contains the files addressing some security issues (ftpaccess, httpd.conf, ...).

The sysf command is used to manage the system files and their copy (config files in the sysf nomenclature) . One can copy a system file into its config file (archive) and vice-versa. One can also check that a system file is identical to its config file or list the difference between the two (as the output of the diff command). It is also possible to compare the config files of two different hosts. All operations can be performed for a single file as well as on any group of file. Sysf can also check files for a specific hosts as well as any group of hosts. For example, the command

    sysf -check ALL -host ALL

    sysf -install fstab 

    sysf -diff printcap -host RoomA

The sysf command can also execute some auxiliary commands to perform further configuration tasks. For example, after the printcap file has been modified one should restart the lpd daemon. This can be done by configuring sysf to execute a specific command, usually a script file, to perform that operation each time the printcap file is updated.

1.2 What sysf was designed for

The strength of sysf is to simplify the maintenance of the system files across a network and in particular:

• to offer a global view of all the configuration files across the network.
• to guarantee that some system files are identical across all hosts belonging to the same host group. This is particularly important for files like inetd.conf or hosts.allow that implement some security policy.
• to ensure that all configuration files have the correct access mode and ownership.
• to monitor a directory ensuring that no file are modified, removed or added (/etc/rc3.d, /etc/cron.daily.
• to help configuring identical hosts.
• to make configuration changes on many computers at the same time.
• to simplify the configuration of new hosts when they are added to the network.
• to maintain a backup copy of the entire configuration of the network.
• to easily reconfigure a computer after an operating system upgrade.

Aside from helping the management of a large number of configuration files, the config directory can be used as a backup copy of all configuration files of all computers on the network. Should a computer need to be reinstalled from scratch all the information is contained in the config directory. The only two missing parts are the user data files and other shared disks, which should be stored carefully and be thoroughly backed up, and the software installed on the computer (which one can reinstall from CD or other media). If one used rpm, the sysf rpm.list entry described below will provide the list of rpms that were installed. To configure a new computer on the network where sysf has been properly configured, one only has to execute the command

    # sysf -OSI ALL

1.3 Terminology

Before we continue, we must define some terminology used in this manual:

• config directory:

  The directory where all the config files are stored. The directory contains the sysf.conf and hosts.conf files used to configure sysf and the BIN directory containing auxiliary commands (described in a separate section below). The other directories correspond to the different groups of files and contain the config files. The path of the config directory is defined in the /etc/sysf.cf file.

• entry name :

  The name of an entry in the sysf.conf file and the name used to specify the file on which sysf must operate. It is the first column of the sysf.conf file. Most of the time, the entry name is named after the system file (without the full path), but sometime it is convenient to use another name like root_cshrc instead of .cshrc.

• system file :

  The full path of the Unix/Linux configuration file, i.e. the file used by the operating system. It is the full path given in the third column of the sysf.conf file.

• config file :

  The copy of the system files maintained by sysf and grouped together in separate directories. The name of the config file are of the form CONFIG_NAME.SUFFIX where the prefix, config name, is the 4th column in the sysf.conf file and where the suffix can be a host-name, a host group, DEFAULT or SHARED.

• config name :

  The prefix of the config file. Most of the time, the config name is identical to entry name but it doesn't have to be. If for example two entries share the same config file one would have two entry names but only one config name. The config name is the name in the third column of the sysf.conf file.

• config group :

  sysf entries are split in various config groups which are defined when configuring sysf. The config group to which an entry belong is given by the name in the second column of the sysf.conf file for that entry. Each config group must have a directory named after the group in the config directory. The set of config group is collected by sysf from the second column of the file sysf.conf and sysf tests that the corresponding directory exists. sysf aborts with and error message if a config group and an entry name have the same name.

• group directory :

  The sub-directories of the config directory named after each config group. The config files for a given config group are all archived in the corresponding group directory . These directories must be created for every config group defined in the sysf.conf file.

• auxiliary commands:

  sysf can execute some auxiliary commands, written by the administrator, to perform further configuration operations. The executable files, usually script files, are in the BIN sub-directory of the config directory and are named after the entry name.

• host group :

  The groups of hosts defined in the file hosts.conf in the config directory. The names of the host groups can be used as suffix for config files. The config file will then be used for every host belonging to that group except when another config file exists (i.e. a host specific config file or another group file to which the host also belongs but defined before in the file hosts.conf).

Sysf uses three configuration files

• /etc/sysf.cf which sets various general properties of sysf including the path name of the config directory.
• sysf.conf (in the config directory) lists the files and directories maintained by sysf, what the config file are called and how the system files are achieved. It also defines the config groups.
• hosts.conf (in the config directory) which defines the host groups used by sysf.

1.4 The Config Directory

The config directory, typically /usr/local/sys/config is where all the configuration files are saved. This directory must be accessible from every host. It is thus normally somewhere on an NFS mounted directory. One cannot use a samba mounted file system because sysf must be able to creates symbolic links, something that samba does not support.

The directory must contain the files sysf.conf and hosts.conf and a directory for every config group. It must also contain the directory BIN which contains the auxiliary commands, typically shell scripts, that one can write to get sysf to perform further operations.

We illustrate below the structure of the config directory by listing a few of the files it might contain. In the example, trovald and cox would be the name of two hosts, lprsever would be the print server while MATROX and ELSA will be host groups corresponding to the computers fitted with Matrox and Elsa graphic cards respectively.

 ../config/
          |
          + sysf.conf
          |
          + hosts.conf
          |
          + BIN/
          |    |
          |    + crontab
          |    |
          |    + printcap
          |    
          + etc/
          |    |
          |    + fstab.trovald
          |    | 
          |    + fstab.cox
          |    | 
          |    + printcap.DEFAULT
          |    | 
          |    + printcap.lprsever
          |      
          + local/
          |      |
          |      + motd.SHARED
          |      
          + X11/
               |
               + XF86Config.MATROX
               | 
               + XF86Config.ELSA
               | 
               + Xsession.DEFAULT

Notice that the config files belonging to a given group are saved in the corresponding directory.

1.5 The Config Files

The config files are archived copies of the corresponding system files. Their full path name have the following form:

    /CONFIG_DIR/CONFIG_GROUP/CONFIG_NAME.SUFFIX

• CONFIG_DIR is the path of the config directory.
• CONFIG_GROUP is the name of the config group and is given by the 2nd column of the sysf.conf file for that entry.
• CONFIG_NAME is the config name given by the 4th column of the sysf.conf file for that entry.
• SUFFIX can be a host-name (in lower case) a host group (starting with an upper case letter), DEFAULT or SHARED.

To determine the config file of a given host, sysf searches first for the file with the host-name extension. If there isn't one, sysf scans all the host groups the host belongs to (in the same order as they appear in the hosts.conf file) and takes the first file found with the matching suffix. If this fails, the DEFAULT file is used, and if there isn't any, a warning message is displayed. The suffix SHARED is used for the sysf entries which have the s flag set (cfr below). This is for files that are stored on a shared (NFS mounted) file system.

One can also specify that a system file must not exist. This is done by creating the corresponding config file as a symbolic link to the name NONE (which does not have to exist as a file).

Config files should not be symbolic links to other files as sysf removes any such link when performing an archive operation and creates a regular files instead. This is a design choice was made to avoid making unintentional modification to a config file. If two computers share the same config file a host group should be created for them instead. Symbolic links (to NONE) should only be used to specified that a system file does not exist.

1.6 The System Files

The system files are most of the time the files used directly by the operating system. The file names and the locations of these files are set by the operating system and must be given as the 3rd column of the file sysf.conf. Rather than maintaining all the system files with sysf one would usually maintain only the ones that have been modified after the installation of the operating system.

Some of the system files are special in that they are not editable files. An example is the standard Unix crontab file; the crontab entries are stored in a binary file but can be listed by executing the command crontab -l. The list of installed Red Hat packages (rpms) is another example of a system file stored in a binary format. The list of packages can be obtained with the command rpm -qa. To work properly, sysf must first create a temporary file containing the relevant information which can then be compared to the corresponding config file. These entries must have the C flag set in the sysf.conf telling sysf to execute the corresponding auxiliary command to create the system file each time a sysf command is executed.