Re: cfgtool and non-script configuration (was Re: Upcoming Debian Releases)
On Tue, 14 Jan 1997, Vociferous Mole wrote:
> On Jan 14, bcwhite@verisim.com (Brian C. White) wrote:
> > * Move config information from install scripts to "cfgtool" (???)
>
> While it's fairly obvious how to do this when the configuration
> information is 'normally' imbedded in a shell script, there are other
> cases. Consider cern-httpd. The config file is read by the daemon,
> with no shell processing. The way I've thought about implementing
> this is to have a base configuration file, with placeholders for the
> various configurable variables. The httpdconfig program would let the
> user set the variables, store the info in the cfgtool database, and
> then regenerate the config file from the base config file. I'm not
> real happy about this for a couple of reasons:
Make is perfect for managing this job.
consider the (completely hypothetical) example of a makefile called
/etc/config/cern/Makfile:
#! /usr/bin/make -f
all: backup /etc/httpd.conf restart
/etc/httpd.conf: /etc/config/cern/httpd.conf /etc/config/common.cfg
# sed/ed/awk/perl/sh script -- whatever commands will generate
# the real httpd.conf
backup:
# commands to backup the current running config to a safe
# place. e.g. /etc/httpd.conf.970127. If there is more than one
# config file, use a tar file like httpd.conf.970127.tar.gz.
revert:
# commands to restore the backed-up config files - useful
# only as an emergency override to quickly get the service back
# to what it was while the sysadmin works on fixing the mistakes
# s/he just introduced.
stop:
# commands to stop the daemon (if relevant)
# e.g.
# /etc/init.d/cern-httpd stop
start:
# commands to start the daemon (if relevant)
restart:
# commands to restart the daemon (if relevant)
The source config file /etc/config/cern/httpd.conf contains a normal
config file, with replaceable tokens for hostname, ip address, or
whatever else is needed. These can be processed with any desired
language/tool (perl, ed, m4 etc) to generate the desired target config
file.
A "top-level" makefile /etc/config/Makefile can iterate through all
the subdirectories, allowing easy global changes of all config files.
This probably requires having an /etc/config/common.cfg which contains
generic information which should be common to all programs, as well as
individual config files specific to individual packages, and config
files specific to types of packages (e.g. /etc/config/network.cfg
contains ip addresses and other stuff which is common to all or nearly
all networking apps)
This can easily be extended for packages that may require it (e.g.
squid) to include multiple input files (e.g. a file containing a list of
acls to block)
#! /usr/bin/make -f
all: backup /etc/squid.conf restart
/etc/config/squid/30-acls.inc: /etc/config/proxy-acls.cfg
# generate the squid format acl file
/etc/config/squid/convert-acls </etc/config/proxy-acls.cfg \
>>/etc/config/squid/30-acls.inc
/etc/squid.conf: /etc/config/squid/*.inc /etc/config/common.cfg
# combine all the include files into one
# files in /etc/config/squid/ would include things like:
# 00-head.inc, 30-acls.inc, 99-tail.inc etc
cat /etc/config/squid/[0-9][0-9]-*.inc >/etc/config/squid/squid.m4
# and now process it to generate the target
m4 </etc/config/squid/squid.m4 >/etc/squid.conf
In this example, /etc/config/proxy-acls.cfg is a simple text list of
acls to block/allow access to. It can be maintained with vi, perl, ed,
sed, awk, or even a webform/cgi program. Even better, the proxy-acls.cfg
file is generic and can be used with apache's proxy module too or cern
proxy - if appropriate converters are written for apache or cern as
well as squid. One config file which can be used with multiple similar
applications.
Big advantages of this scheme as i see it are:
1. it's relatively simple - there's nothing really new, it just
uses existing tools, and requires only a defined standard. It's also
pretty simple to understand how it works.
2. it's flexible. it's not just limited to doing things in one
specific way. make is flexible enough to run any programs needed to
generate the target config file. Use any tools which are appropriate
to the task at hand (should be limited to tools/languages marked
'essential').
3. it fosters development of alternative access/config methods (e.g.
web form) by encouraging developers to think of configuration
data in a source/object code analogy...prompting the same sort of
development model as for code generators, macro processors etc. i.e.
"modify/generate the source (in any way you choose), then run make"
4. it is easy to make global config changes, and have them propagate
to every package/config file which depends on that config info.
5. the 'backup' and 'revert' targets are probably overkill but they are
good for demonstrating to novice sysadmins that config files should
(nearly :-) always be backed up before they're edited! Second rule
of system admining: "always leave yourself a way to back out". First
rule is, of course, "THINK!!!"
6. as shown with the squid proxy-acls.cfg example, it is fairly easy to
abstract common data types so that the same configuration file can
be used by several competing packages - eliminating the need to have
separate web forms (or ncurses config tools) for each package.
7. like any other scripting language you can embed comments in the
make scripts and also in the source files.
(This is so valuable and useful that, in my opinion, any format
other than plain text for the config database is just plain wrong.
The ability to temporarily comment out the current configuration
while you're testing something new is priceless...if you mess up,
just uncomment the old config. The only way to do that with a real
database config file would be if the db file was generated from a
plain text file, e.g. /etc/aliases is converted to /etc/aliases.db
by /usr/bin/newaliases)
8. sendmail already does something similar to this with sendmailconfig
and the /etc/mail/sendmail.mc file. sendmailconfig could fairly
easily be converted to a makefile and sh script combination ...
avoiding the need to ask if the user wants to generate a new
sendmail.cf from sendmail.mc - make already knows how to handle
source file dependancies
> 1. If the config file is modified by hand, then the changes will be
> lost the next time httpdconfig is run (this is true now, but I still
> don't like it).
document things so that users know that they are supposed to change the
source config file (i.e. /etc/config/httpd/htppd.conf) rather than the
target config file (/etc/httpd.conf)
> 2. If the user modified the cfgtool database directly (which should
> work, and does for script based configuration), the changes don't
> propagate until the httpdconfig program is run.
after editing the database, propagating the changes is as simple as:
cd /etc/config/httpd
make
Comments, suggestions, improvements, disagreements are welcome.
flames >/dev/null.
craig
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: