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).
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 ALLThis 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 ALLto 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 ALLwill 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,RoomBto 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 ALLSimilarly, to check the file
XF86Config
on all the computers that
have a Matrox
card, one uses
# 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:
XF86Config.trovald
belong to the host trovald
.
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.
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".
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 ALLlists all the
system files
which differ from their config file
on all the hosts.
sysf -install fstabupdates the
fstab
system file
from the config file
on the
current host.
sysf -diff printcap -host RoomAlists the differences between the
printcap
system files
and their
config file
for all the computers belonging to the host group
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.
sysf
was designed for
The strength of sysf
is to simplify the maintenance of the
system files
across a network and in particular:
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./etc/rc3.d
, /etc/cron.daily
.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
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
.
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.
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.SUFFIXwhere
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.
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.