[Logwatch-Devel] Service Script self-configuration

Bjorn L. 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.

Some pitfalls:

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
main-line logwatch.

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 mailing list