[Logwatch-Devel] Service Script self-configuration
bl_logwatch at mblmail.net
Fri Jun 10 10:15:49 MST 2005
Gary Allen Vollink wrote:
> Is there an official stance on having a service script read that
> service's configuration file prior to doing it's work?
Here is my long-winded commentary:
In principle, I like the idea. But it really is going to come down
on how good the implementation is for that particular service. Making
it so it 'just works' may be more difficult than it appears.
A. Configuration files define methods, not intent.
Example: yesterday Kenneth Porter indicated that he used
"named.conf logging section to break out all the categories into
separate log files." Maybe some people would prefer logwatch to
find all those log files. Maybe some people do that precisely so
that logwatch does not parse those log files.
Example: I've wondered about parsing the syslog.conf file to
get log file information. But some people might choose to
log debug level to a different file so that logwatch does not parse
B. Completeness and correctness are hard to prove.
Example: the logwatch script for sendmail used to parse the
local-host-names file to attempt to determine which domains were
local. But it did not parse other files that also have a bearing,
such as domaintable, virtusertable, mailertable, sendmail.cf, and
sendmail.mc. So it might have worked for the author's setup, but
was not a general and correct solution.
Also, many configuration files have constructs like '#include', and
specific rules on duplicate declarations (Are they cummulative?
Does the first or last take precedence? Or are they all ignored?).
Maybe they are corner-cases, maybe they are very common.
And run-time (command-line) configuration options may not be found at
all, especially if they are built "on-the-fly" (dynamically). They
usually take precedence, too. Some services actually have a run-time
option to specify an alternate configuration file.
C. Multiple distributions make it difficult.
Example: Fedora/Redhat makes use of /etc/sysconfig directory;
other distributions have other configuration mechanisms.
I'd prefer a two-stage process: the first one parses configuration
files and writes out logwatch configuration and/or script files, which
then logwatch can use. That way the parsing of configuration files
can be made optional, and its development is decoupled from the
In summary, it all depends on the scope and complexity of the specific
service and configuration you are trying to automate.
More information about the Logwatch-Devel