config groups
The choice of config group
is left entirely upon the administrator. The
config groups
were introduced for convenience so that the config directory
does not contain too many files but also to make it easier
to find a given config file
when needed.
Here is a reasonable but not exhaustive set of suggestions
filesystem
: the files describing the file-system
fstab
, exports
, amd.conf
, auto.master
, smb.conf
...mail
: the mail configuration files sendmail.cf
,
mailcap
, mime.types
, pine.conf
. etc
: files located in the /etc
directory and not part
of any other config group
.net
: the network configuration files:
ifcfg-eth0
, network
, yp.conf
...nis
: all the NIS files hosts
,groups
, ...keys
: the security keys (ssl_server.key
, ssl_server.crt
).
This group directory
should have the access modes set to 700
. security
: security related files : hosts.allow
,
hosts.deny
...services
: the network services configuration files
httpd.conf
, srm.conf
...xinetd
: the various xinetd
files in the /etc/xinetd.d
directory.root
: the files in the root home directory: .cshrc
,
.login
, .rhosts
...printing
: the printer configuration files: printcap
,
printcap.local
, lpd.conf
, lpd.perms
...cron
: the crontab files : crontab
, cron.hourly
,
tetex.cron
...X11
: the X11 files : XF86Config-4
, xfs_config
,
xinitrc
, Xsession
...rc
: the rc
script files and directories:
/etc/rc.d/rc2.d/
, /etc/rc.d/rc3.d/
,
/etc/rc.d/rc5.d/
as directory lists plus some start-up script files
in /etc/rc.d/init.d/
.extra
: various files that don't fall into other categories like
/usr/share/texmf/web2c/texmf.cnf
or
/usr/share/texmf/dvips/config/config.ps
.dirs
: various directories that one wants to monitor as directory
lists /etc
, /var/log
, /bin
, /usr/sbin
...hosts groups
The host groups
must be chosen to reflect the diversity of host
configuration.
First of all there should be a group called ALL
which contains all the
known hosts.
Another group that must be created is called DEAD
and it must contain the
name of all the hosts that are not currently running (being repaired, or
switched off for whatever reason). sysf
will always skip these hosts
to avoid wasting time by waiting for the remote connection to time out.
It is a good idea to have a group defined for every version
of the operating system. For example example the group RH7.1
and
RH7.2
would correspond to the Linux box running RedHat 7.1 and 7.2
respectively. This is particularly useful when an operating system upgrade is
installed progressively across the network. Once all the config files
have
been properly created (as part of upgrading the first host) all one has to do
when upgrading a computer is to change the operating system host group
to
which it belongs and use sysf
to reinstall the system files
.
Computers that provide special services also benefit from belonging to a
special group. For example one could define the host group
XDM
for the hosts that run the xdm
daemon.
Another useful set of groups are those that correspond to the hardware. For
example the file XF86Config-4
depends very much on the type of video
card and monitor used. One can have a host group
for each combination and
have one copy of XF86Config-4
for each.
When sysf
searches for a config file
for a given hosts its scan the
host groups
defined in hosts.conf
in the order in which they are
listed. This
means that the more general groups should be defined last. A given host
can always belong to more than one host group
, but if a config file
exists
for two such groups, the one that appears first in the hosts.conf
file
will be picked. Remember also that if a config file
suffixed with the
name of the host exists, it will always be taken by sysf
instead of any
other host group
or DEFAULT
config file
.
rc
files.
On some versions of Unix/Linux (like Red Hat) the rc
script files starts
some services when the computer boots up. A full description of how this works
is well beyond the scope of this manual. Moreover the start-up procedure varies
between different version of Unix/Linux. To make our point, we will
nevertheless give a brief summary of how things are setup on Redhat.
When the computer boots at level 3, all the scripts files in
/etc/rc.d/rc3.d
starting with the letter K
are executed in
alphabetical order with the argument stop
. This is supposed to stop these
services. Then all the script files starting with the letter S
are
executed in alphabetical order with the argument start
to start these
services.
For computers that start the graphical interface at boot time, the boot level
is 5
instead of 3
(this is set in the file /etc/inittab/.)
The script files are actually located in the directory
/etc/rc.d/init.d
and the rc3
script files are symbolic links to these files (the reason
being that the start-up script files are the same for all boot level, the major
difference between levels being which service is started and which one is not).
To maintain the rc script files with sysf
one must first maintain the
actual script files in /etc/rc.d/init.d
. Normally these files don't
change so one needs to maintain only the files that are modified or added to
that directory using a standard sysf
entry. Here is an example of a
sysf.conf
entry for the xdm
script file:
xdm = rc /etc/rc.d/init.d/xdm xdm ;One could add an auxiliary command for that entry to restart the service when the script file is modified, but as this is rare and as the addition and removal of start-up services can be done as described below, it is not really worth it.
The most important files to maintain are the start-up directories. For this we
must use a directory list to monitor the addition and removal of files.
We also need an auxiliary command to stop or start services when a file
is added or removed. The sysf.conf
entries will look like this:
######## GROUP RC ################################################## rc2_DL = rc /etc/rc2.d rc2_DL grI; rc3_DL = rc /etc/rc3.d rc3_DL grI; rc5_DL = rc /etc/rc5.d rc5_DL grI;
where the auxiliary scripts, located in the BIN
directory are named
rc2_DL
, rc3_DL
and rc5_DL
and are all the same file (two of
them could be symbolic links to the third one):
#!/bin/csh ############### AUXILIARY COMMAND rcN_DL ################## if( $# != 5 ) then echo "$0 ERROR : invalid No of argument"; echo "SYNTAX : $0 SYSTEM_FILE TYPE ACTION ECHO_ON" exit(0); endif set SYS_PATH = $1 set TYPE = $2 set ACTION = $3 set ECHO_ON = $4 set SYSF_COM = $5 set ENTRY_NAME = $SYS_PATH:t # we only deal with symbolic links if ( "$TYPE" != "l") then exit(0) endif if ( "$ACTION" == "CREATE") then switch($ENTRY_NAME) case "K*" : echo "KILLING service "$ENTRY_NAME rsh $SYS_PATH stop breaksw case "S*" : echo "STARTING service "$ENTRY_NAME rsh $SYS_PATH start breaksw endsw else if ( "$ACTION" == "REMOVE") then switch($ENTRY_NAME) case "K*" : breaksw case "S*" : echo "KILLING service "$ENTRY_NAME rsh $SYS_PATH stop breaksw endsw endif
Most computers will run the same services and will thus share the same
config file
. Others will run some special services requiring they own
config file
or one shared by a small group. For example one could have a host group
called SAMBA_SERVER
for all the smb
servers which will share the
same rc3_DL
config file
.
Under Solaris, the start-up script files are hard linked to the
/etc/init.d
files. This can't he handled by sysf
as such, so
in that case, one must use a directory list as before to check the content
of the rc.N
directories and ordinary entries to maintain the actual
script files. The major difference is that line 15 of the script files
rcN_DL
must now become
if ( "$TYPE" != "f") thenOne alternative would be to use an auxiliary command for the
/etc/init.d
script entry that would create the hard link when
required as well as start or stop the service. This has the disadvantage of
requiring a potentially large number of sysf
entries.
NIS
files.
Despite the fact that NIS provides a similar functionality to sysf
it is worth creating sysf
entry for all the NIS files, if only to
have a backup copy of them.
There is nothing special about the NIS files except that when the sysf
install
, first_install
or OS_install
commands are executed on
the master NIS server, the NIS maps must be updated by running make
in
the /var/yp
directory. This will be done by the auxiliary command
when the action is -UpdateSysFile
.
The sysf.conf
entries for the NIS files should look like this:
#########GROUP NIS #################################### aliases = nis /etc/mail/alias alias I; bootparams = nis /etc/bootparams bootparams I; ethers = nis /etc/ethers ethers I; group = nis /etc/group group I; hosts = nis /etc/hosts hosts Ih; netgroup = nis /etc/netgroup netgroup I; netmasks = nis /etc/netmasks netmasks I; networks = nis /etc/networks networks I; protocols = nis /etc/protocols protocols I; publickey = nis /etc/publickey publickey I; rpc = nis /etc/rpc rpc I; services = nis /etc/services services I; timezone = nis /etc/timezone timezone I; ypservers = nis /var/yp/ypservers ypservers I;
The same script file can be used for every NIS file, so we will create the file
NIS
in the BIN
directory and create symbolic links to it named
after every NIS files.
The BIN/NIS
script file:
#!/bin/csh set ACTION = $1 set COM = $2 set SYSTEM_FILE = $3 set CONFIG_FILE = $4 set ECHO_ON = $5 set NIS_SERVER = my_serv switch( $ACTION ) case "-CreateSysFile" : breaksw; case "-UpdateSysFile" : breaksw; case "-PreInstall" : breaksw; case "-PostInstall" : if (`uname -n` == $NIS_SERVER) then (cd /var/yp; make) endif breaksw; case "-Remove" : breaksw; default : echo "Unknown ACTION " $1 breaksw; endsw
crontab
file.
The crontab
service is peculiar in the sense that it does not have a
configuration file. The configuration is displayed by executing the command
# crontab -lTo maintain the crontab setup using
sysf
one must create a temporary
config file
using an axillary command. The directories
/etc/cron.hourly
, /etc/cron.daily
,
/etc/cron.weekly
and /etc/cron.monthly
should be maintained
using a directory list and possibly a few ordinary entries for some of the
script files they contain.
The entry in the sysf.conf
file could thus look like this
######### GROUP CRON ########################################### crontab = cron /tmp/crontab.list crontab C; cron.hourly_DL = cron /etc/cron.hourly cron.hourly_DL gr; cron.daily_DL = cron /etc/cron.daily cron.dailyy_DL gr; cron.weekly_DL = cron /etc/cron.weekly cron.weekly_DL gr; cron.monthly_DL = cron /etc/cron.monthly cron.monthly_DL gr;and the
crontab
auxiliary command will create the temporary
system file
when called with the action -CreateSysFile
and will
update the crontab entry when called with the action -UpdateSysFile
.
The BIN/crontab
script file:
#!/bin/csh set ACTION = $1 set COM = $2 set SYSTEM_FILE = $3 set CONFIG_FILE = $4 set ECHO_ON = $5 switch( $ACTION ) case "-CreateSysFile" : crontab -l >! $SYSTEM_FILE breaksw; case "-UpdateSysFile" : crontab $SYSTEM_FILE breaksw; case "-PreInstall" : breaksw; case "-PostInstall" : breaksw; case "-Remove" : breaksw; default : echo "Unknown ACTION " $1 breaksw; endsw
passwd
and shadow
file
On most networks, the passwd
and shadow
entries are distributed
using NIS. This is configured in the file /etc/nsswitch.conf
where
only usually specifies that the entries are searched in the
/etc/passwd
and /etc/shadow
files first and then in the NIS
tables. These two files usually can be identical on every hosts of the
network, except on the master NIS server which will contain the users entries
as well.
One of the most important piece of data stored in these files is
probably the root password. sysf
can be used to change the root password
on the network (assuming it is the same on every computer). To do this one
creates a sysf
entry for the passwd
and shadow
files if there
is none yet. Then once changes the root password on one typical host and
copies the files as follow across the entire network, making sure the NIS
master server has its own entry for the passwd
and shadow
files!
# sysf -MD shadow # sysf -I shadow -h ALL -eh -xh nis_master
printcap
file.
The printcap
file is a typical example of a file that should trigger
the restart of a service (lpd
in this case) after it has been modified.
The lpd
configuration files lpd.conf
and lpd.perms
should
do the same. This can be achieved with the following sysf.conf
entries
#########GROUP PRINTING ################################## printcap = printing /etc/printcap printcap I; printcap.local = printing /etc/printcap.local printcap.local; lpd.conf = printing /etc/lpd.conf lpd.conf I; lpd.perms = printing /etc/lpd.perms lpd.perms I;where the auxiliary command (in
BIN
) for the three files with the flag
I
will be identical: they will restart the lpd
daemon when the
action (the first argument) is -PostInstall
.
The BIN/printcap
script file:
#!/bin/csh set ACTION = $1 set COM = $2 set SYSTEM_FILE = $3 set CONFIG_FILE = $4 set ECHO_ON = $5 set LPD = /etc/rc.d/init.d/lpd switch( $ACTION ) case "-CreateSysFile" : breaksw; case "-UpdateSysFile" : breaksw; case "-PreInstall" : breaksw; case "-PostInstall" : # restart the lpd daemon $LPD restart breaksw; case "-Remove" : breaksw; default : echo "Unknown ACTION " $1 breaksw; endsw
rpm
list file.
Red Hat and other versions of Linux use packages to install software. The list
of installed software is stored in the rpm database and it can be extracted
using the rpm command "rpm -qa
".
To be able to check if new packages have been installed
or compare different hosts, one can define the following sysf entry in
sysf.conf
:
rpm.list = extra /tmp/rpm.list rpm.list C;As such there is no
system file
for rpm.list
so we create it as the
temporary file /tmp/rpm.list
using the -CreateSysFile
action in the auxiliary command
. Sysf
can be used to check if new
packages have been added on a system or compare the package lists on
different hosts. Notice that the sysf -install
command does not do
anything useful in this case.
The following script file creates the file /tmp/rpm.list
when
required.
The BIN/rpm.list
script file:
#!/bin/csh set ACTION = $1 set COM = $2 set SYSTEM_FILE = $3 set CONFIG_FILE = $4 set ECHO_ON = $5 switch( $ACTION ) case "-CreateSysFile" : if ( $ECHO_ON == "on" ) then echo "Creating $SYSTEM_FILE" endif /bin/rpm -q -a | sort >! $SYSTEM_FILE breaksw; case "-UpdateSysFile" : breaksw; case "-PreInstall" : breaksw; case "-PostInstall" : breaksw; case "-Remove" : breaksw; default : echo "Unknown ACTION " $1 breaksw; endsw
The tool sysfrpm
distributed with sysf
was specially written to
monitor the packages that are installed on a system. It is better suited to
compare the packages that have been installed on different computers and
to list the packages that should be added, upgraded or removed.
diskinfo
file
Every system manager must backup file systems to be able to restore them after a disk crash. Tape backups are not sufficient to restore a computer as one also needs to know how the disk was partitioned and sometimes, it might also be useful to know how full each partition is.
sysf
can be used to keep this information available for every hosts,
a bit like the rpm.list
entry described above by creating a entry
like this
diskinfo = info /tmp/diskinfo diskinfo Wh;where the flags
h
is set because every config file
will be specific
to a host and where the flag W
is set because the actual work will
be entirely done by the auxiliary file
diskinfo
which
will look, under Linux, like this:
#!/bin/csh set ACTION = $1 set COM = $2 set SYSTEM_FILE = $3 set CONFIG_FILE = $4 set ECHO_ON = $5 switch( $ACTION ) case "-CreateSysFile" : if ( $ECHO_ON == "on" ) then echo "Creating $SYSTEM_FILE" endif echo "hdparm -acdgkmnrui /dev/hda" >! $SYSTEM_FILE hdparm -acdgkmnrui /dev/hda >> $SYSTEM_FILE echo "\n\n" >> $SYSTEM_FILE echo "# df -kF ext2" >> $SYSTEM_FILE df -kF ext2 >> $SYSTEM_FILE echo "\n\nFSTAB" >> $SYSTEM_FILE cat /etc/fstab >> $SYSTEM_FILE if ( $CONFIG_FILE != "" ) then # This is dodgy but does the job. # Check might not always work /bin/cp -f $SYSTEM_FILE $CONFIG_FILE else echo "No config file for diskinfo" sysf -new diskinfo endif breaksw; case "-UpdateSysFile" : breaksw; case "-PreInstall" : breaksw; case "-PostInstall" : breaksw; case "-Remove" : breaksw; default : echo "Unknown ACTION " $1 breaksw; endsw
Each time sysf
needs the system file
it creates the file
/tmp/diskinfo
(as defined in the sysf.conf
file) by listing
various information related to the disks (hdparm
), how full each
partition is (df
) as well as the content of the
/etc/fstab
file.
The system file
is then copied into the config file
ensuring that
it is always up to date. This is required here because the system file
will be different each time it is created, as the output of df
varies as the disk is being filled up, and also because this sysf
entry
is used only to record the current configuration entry.
If one checks the config file
consistency with the command
# sysf -c -h ALL -ehthe
diskinfo
config file
will be updated automatically.
Notice that if the config file
does not exist, it is created automatically
with the host-name
extension (equivalent to a sysf -new
).
As the disk on which the config dir
is stored can crash just as any other
disk it will be wise to archive the entire config dir
on a media like
a floppy or ZIP disk at regular interval using a cron job.