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") then
One 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 -l
To 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 -eh
the 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.