Re: Ideas for splithost, hostname, multiemail in Logwatch 8.0

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.

Comments;

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

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


I've got some additional comments, but they belong in a separate
discussion, so I'll post my own email to the mailing list.

Cheers
   Ross

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Tom Metro
Sent: Monday, July 16, 2007 2:29 PM
To: L-logwatch-devel
Subject: Re: [Logwatch-Devel] Ideas for splithost, hostname, multiemail
in Logwatch 8.0

MrC wrote:
> It think *how* the reports are split should be distinct from *where*
the 
> reports go (email, file, screen), and distinct from email address 
> specification.

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

I'd vote for this as well.


> I would suggest a more common, vanilla approach:
> --nosplithost
> 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.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Logwatch-Devel mailing list
[email protected]
http://www2.list.logwatch.org:81/mailman/listinfo/logwatch-devel