[Logwatch-Devel] Ideas for splithost, hostname, multiemail in Logwatch 8.0
ross at trapezenetworks.com
Sun Sep 16 14:44:38 MST 2007
Hey folks, I've been using logwatch quite a while, and find it very
useful- it's great stuff!
Just some comments on this thread, as I'm going to be embarking on
re-vamping my logwatch use soon, and this discussion centers around some
of the things I'm looking at.
I'm in full agreement with keeping report format, how reports are split,
and where they go separate. I'd suggest killing off --splitemail and
rolling that into --output email with
I prefer being able to specify multiple hosts in a config option than
specifying the config option multiple times. Perhaps getoptslong
supports it, but you're not going to specify the same option multiple
times in a config file, so specifying multiple hosts both in the
corresponding config file and command-line options makes a lot of sense
I've got some additional comments, but they belong in a separate
discussion, so I'll post my own email to the mailing list.
From: logwatch-devel-bounces at logwatch.org
[mailto:logwatch-devel-bounces at logwatch.org] On Behalf Of Tom Metro
Sent: Monday, July 16, 2007 2:29 PM
Subject: Re: [Logwatch-Devel] Ideas for splithost, hostname, multiemail
in Logwatch 8.0
> It think *how* the reports are split should be distinct from *where*
> reports go (email, file, screen), and distinct from email address
I agree with this, though I don't have a strong opinion on these
features as I don't have any plans to run logwatch on a machine with
logs consolidated from multiple hosts.
> As a personally preferance, I think --reportbyhost is clearer than
I'd vote for this as well.
> I would suggest a more common, vanilla approach:
> Usage of the --no prefix is very common, and built into Getopts.
I'd second that.
> Lists can be comma or whitespace separated...
If Getopt::Long is being used, I believe it permits specifying a switch
multiple times on the command line and will return an array of values,
thus avoiding the need to post-process. It makes the command line a tad
more verbose, but simpler on the coding side.
Mike Tremaine wrote:
> ...we have had a tendency to feature grow the available switches
> and people forgot how to use them all.
One way to lessen this problem is to unify command line switches and
config file directives into one common namespace, so you only have to
document things once. With logwatch this may extend to the logwatch.conf
and maybe the ignore.conf, but probably not to the log file group and
service file config files.
It also permits easy overriding of conf file option by loading the conf
file settings into a hash, and then overwriting them with like named
command line options.
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
Logwatch-Devel mailing list
Logwatch-Devel at logwatch.org
More information about the Logwatch-Devel