[Logwatch-Devel] Service Script self-configuration

Gary Allen Vollink Gary.Vollink at CorVu.com
Fri Jun 10 13:01:45 MST 2005


Bjorn L. wrote:

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

For the reasons you state, I would never imagine trying to shoe-horn 
this into any of the logwatch shared code - it would have to be module 
specific.  Further, there are plenty of programs where granularity is 
completely unnecessary.

I should further clarify that the intent is not to try and change where 
logwatch LOOKS for log files to watch (although that would also be 
tempting), but merely have a method by which messages can be parsed 
based on certain parameters within a configuration file.

> Some pitfalls:
>
> A. Configuration files define methods, not intent.
> Maybe some people [change configs] precisely so
> that logwatch does not parse those log files.

This is a very good point, there - natrually - have to be some limits to 
how something can change from the 'expected defaults' before a service 
script simply gives-up trying.
On The Other Hand, I think your example could equally be answered 
through ignore.conf.

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

I agree with the idea of keeping it relatively generic.  However, there 
are a great deal of messages that are frequently changed, and relatively 
easy to parse configuration files for.

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

Do you see a case where this would differ within a given service, as 
that would be my biggest concern?

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

This falls back to pitfall A... once someone changes something beyond a 
given limit, all bets are off.

> C. Multiple distributions make it difficult.
>
>    Example: Fedora/Redhat makes use of /etc/sysconfig directory;
>    other distributions have other configuration mechanisms.

Even RedHat (which, yes, I'm guilty of using) only has a minor sub-set 
of services config files directed to /etc/sysconfig.  Even so, package 
distributions and package compile defaults also differ greatly - so - 
yes, someone with a good knowledge of a given package should be able to, 
at least, account the 3 most common defaults.

> I'd prefer a two-stage process:  the first one parses configuration

Makefile magic... exactly!  There would still be limitations to what can 
be accomplished, but I see this as a useful possibility.

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

Your thoughts here, coupled with something 'Who Knows' mentioned earlier 
makes me wonder if logwatch itself would benefit from a 'plugins' style 
folder - shipped default with a 'README' - where users could simply dump 
their own overrides without fear of an upgrade overwriting, and without 
fear of the plugin causing permanent damage (at least beyond the 
possibility of having to remove it).  This part is probably worthy of 
it's own discussion thread.

> In summary, it all depends on the scope and complexity of the specific
> service and configuration you are trying to automate.

Agreed.


More information about the Logwatch-Devel mailing list