[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
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
> 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.
More information about the Logwatch-Devel