What is the future of logwatch?
Hey List,
In the org that i work for, we use logwatch for log monitoring. Since
puppet is too new to have a module in logwatch, i've had the 'joy'
recently of attempting to write a functional module. In doing so, i
have a number of issues i would like to bring up about logwatch in
Fedora (and RHEL/CentOS).
To begin with, like a good netizen, i sent a message to the mailing
list upstream. So far i've heard no reply. There's the chance that it
got caught in my spam filter, but i've gotten one message from the ML
already. It feels like upstream is dead. There has also been no
release since 2007. Since it still 'just works' i won't bring out the
fire and brimstone and demand it be removed, but i would like to know,
how are we going to support this?
This question is important in the context of the issues i had
programming for logwatch. A well programmed tool maintains orthogonal
features in an orthogonal way. I ran into some serious bugs while
trying to develop a robust module. Logwatch has two modes, one for a
machine with a single set of logs, and one for generating reports for
a machine with multiple logs, namely your centralised logging box. The
snippets of code that filter the logs you want to analyse allow you to
control for the date range and the machine the logged event was
generated on. When trying to code for the puppet logs, my code
ultimately only worked on the single nodes, but crapped out on our
logging box. After debugging the issue, it's obvious that it's doing
some prefiltering per host that is occluding all the puppet logs, when
the 'splithosts' feature is enabled. Extending and maintaining this
package is going to be difficult without a willing maintainer. If this
is just something that needs a bug report, i would appreciate if the
package maintainer, according to zodbot Karel Klíč, could speak up on
this.
If no one is willing to maintain logwatch, i would like to ask why is
it enabled by default? For most environments, logwatch is
ignored/disabled in lieu of other solutions. People who use logwatch
seriously are already aware of its presence and will enable it when
disabled. They are also generaly experts, and from my experience been
around the sysadmin block quite a few times. For the non-expert user,
discussions of target audience aside, either they know about logwatch,
and perhaps keep an eye on it, or will never find it. I refer to the
fact that the only way to know about logwatch on a running system is
that innocous "you've got mail in /var/spool/mail/root' message. Then
you have to know to open up your mbox, which in my case means
installing mutt which is not installed by default, and read it, and
then know it's logwatch, and realize what it's there for. There are
'expert tips' i've seen that remind newbs to check logwatch on their
own machines, but if this is something important, it should be more
obvious, and if it's not so important, why is it enabled by default?
I'm not going to bike shed, so i'm not going to ask for any particular
action. We don't have the time in our organisation to take up
maintenance of logwatch, so we clearly are going to look for another
solution. Still, i would like to ask the persons who made the decision
to enable this by default, is it still relevant? Or is it something
that's in danger of becoming cruft? Am i missing a certain perspective
on why it's enabled by default?
-Yaakov
DISCLAIMER: I will not entertain bike shedding on this thread. It
sounds so simple that everyone could imagine having one's own opinion
on it. If you waste everyone's time with a 'me too', or anything that
tries to convert a mailing list discussion into a survey, i will be
unhappy. And you know don't want to find out what that means.
For every message sent to a ML, it requires a person 10 seconds
approximately to read and/or ignore it. Considering the number of
people subscribed here, you will waste a considerable number of man
hours with a useless reply, so before you hit send, take 10 seconds to
decide if you want to reply. Please.