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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
