Configuring a System
PIKT isn't just for reporting and fixing problems. You can use it to manage your system configuration files as well, for example: inetd.conf, syslog.conf, hosts.equiv, motd, etc.
In this example, we demonstrate how to manage the resolv.conf file(s). In the piktmaster files.cfg, we have the following #include directive:
#include <files/resolv_conf_files.cfg>
Here is the resolv_conf_files.cfg #include file:
///////////////////////////////////////////////////////////////////////////
//
// resolv_conf_files.cfg
//
///////////////////////////////////////////////////////////////////////////
resolv.conf path "/etc/resolv.conf" mode 644 uid 0 gid 0
#include <files/adm/resolv_conf_common_files.cfg>
///////////////////////////////////////////////////////////////////////////
#if mandrake
resolv.conf_postfix path "/var/spool/postfix/etc/resolv.conf"
mode 644 uid 0 gid 0
#include <files/adm/resolv_conf_common_files.cfg>
#endif
///////////////////////////////////////////////////////////////////////////
We have two instances of resolv.conf to manage: one in its usual place, the /etc directory, and a second--for Mandrake Linux systems--in a special Postfix config directory. Except for their location, these resolv.conf files are identical. We get their content from a common #include file, resolv_conf_common_files.cfg:
///////////////////////////////////////////////////////////////////////////
//
// resolv_conf_common_files.cfg
//
///////////////////////////////////////////////////////////////////////////
domain pikt.org
nameserver 192.168.3.50
#if earthlink
nameserver 11.22.33.44
nameserver 44.33.22.11
search earthlink.net
#else
# if ! ottawa
nameserver 123.100.222.3
nameserver 123.100.111.3
# endif
#endif
///////////////////////////////////////////////////////////////////////////
We have a rather complicated network arrangement, and depending on who's on what network, we get our name service from several different sources--a local name server on the 192.168.3.0 private subnet, nameservers on the Earthlink consumer network, and still other nameservers on the Road Runner commercial network. We have "earthlink" (and "roadrunner") defined as hosts groups (with associated hostnames) in the piktmaster systems.cfg file.
Here is a piktc command to install resolv.conf on the Linux systems (in /etc everywhere, in /var/spool/postfix/etc only on the Mandrake Linux systems):
# piktc -iv +F resolv.conf resolv.conf_postfix +H linux
processing calgary...
installing file(s)...
resolv.conf installed
processing winnipeg...
installing file(s)...
resolv.conf installed
resolv.conf_postfix installed
processing ottawa...
installing file(s)...
resolv.conf installed
...
Just to be clear: Post-installation, the Earthlink-connected SuSE Linux calgary system would have an /etc/resolv.conf file with contents
domain pikt.org
nameserver 192.168.3.50
nameserver 11.22.33.44
nameserver 44.33.22.11
search earthlink.net
The Road Runner-connected Mandrake Linux winnipeg system would have identical resolv.conf copies in both /etc and /var/spool/postfix/etc/ with contents
domain pikt.org
nameserver 192.168.3.50
nameserver 123.100.222.3
nameserver 123.100.111.3
And the SuSE Linux ottawa system, which is only on the local private subnet, would have an /etc/resolv.conf file with contents of simply
domain pikt.org
nameserver 192.168.3.50
After doing some reconfiguration--for example, changing an Earthlink nameserver--if we now want to diff our changes against the existing configuration, but only for the Earthlink-connected systems, we might use the command
# piktc -fv +F resolv.conf resolv.conf_postfix +H earthlink
Seeing the expected diffs, and confident that our changes are correct, we might then install resolv.conf on the Earthlink-connected systems with:
# piktc -iv +F =resolvconf +H earthlink
where =resolvconf is a macro defined as
resolvconf resolv.conf resolv.conf_postfix
Of course, reinstalling all PIKT-managed files on all systems with
# piktc -iv +F all +H all
would also install all instances of resolv.conf in the appropriate place on every system.
You could, as another example, use PIKT to manage inetd.conf. After installing or refreshing an updated inetd.conf with the piktc command
# piktc -iv +F inetd.conf +H all
you might then restart the inetd everywhere with the command
# piktc -Xv +C "/etc/init.d/inet restart" +H all
You can use PIKT to manage just about all of your system configuration files (and other text data files). Just after a new operating system installation, and after setting up PIKT on the new system, you could install the PIKT-managed configuration files with
# piktc -ivb +F all +H <newsys>
where the '-ivb' says to do a verbose install, with backup of the original file versions.
Over time, you would continue to employ PIKT to manage your system configuration files. You could routinely diff them against the piktmaster's central configuration, and/or do a checksum comparison, for example:
# piktc -m5v +F all +H all
(where '-m5' says to compare MD5 checksums).
Regular reinstalls would (re)set the ownerships and permissions properly, or perhaps you might have some other PIKT monitoring script routinely ensuring correct file attributes. Note, too, that if you configure your system files the PIKT way, you have a handy central backup repository (the piktmaster config files) in case disaster strikes one of your outlying systems (for example, accidental erasure of a vital system file, or a hacker reconfiguring a system to his or her advantage).
All in all, then, using PIKT to configure your systems has much to recommend it.
|