Re: [arch-general] Recent logwatch update may need a news item?
Hi, On 20/09/19 6:51 pm, Eli Schwartz via arch-general wrote: On 9/19/19 8:29 PM, Amish via arch-general wrote: Thanks but why would one parse logs to log it back to logs? I'm not sure what this statement means, but there is no "parsing", and the only "logs" are the systemd ones. Just emailing the logs doesn't constitute re-logging it to a new log. ??? (read below) The default behaviour of earlier version of logwatch was to send email to root. (via cron) The default behavior of earlier versions of the logwatch archlinux package, yes. What about the default behavior of logwatch itself? Also, like, the vast majority of system logs aren't automatically emailed to root by the software itself. I guess the vast majority of logs in a systemd-based distro aren't emailed at all (because unlike cron, systemd does not do this by default). Umm, I am not sure if you are using logwatch? It seems that you are not. So I guess if the timer was meant to be drop in replacement for cron then it should e-mail too. Who said it was supposed to be a drop-in replacement for cron? The impression I got from looking at https://bugs.archlinux.org/task/56357 is that the timer was supposed to be a "migration from cron installs to the upstream systemd service". Only the maintainer would be able to tell what his intention was. Because current upstream .service file is more or less useless. It parses the logs (journal) and sends the output (which is logwatch report) to systemd which in turn puts the logwatch report to journal! What is the point of sending log reports (back) to journal? I will report to upstream to fix this soon, when I get time. I really don't see why you think archlinux should be opinionated and modify upstream service files. I hear your argument that the package should have a post_upgrade message. If something is buggy. That should be fixed. Ofcourse first attempt should be made to fix at upstream which I will do. But Logwatch has history of not releasing new version for long. (it took 2 and half years between 7.4.3 to 7.5.0) So if logwatch does not fix service file for long then may be maintainer can look at it. Regard, Amish.
Re: [arch-general] Recent logwatch update may need a news item?
On 9/19/19 8:29 PM, Amish via arch-general wrote: > Thanks but why would one parse logs to log it back to logs? I'm not sure what this statement means, but there is no "parsing", and the only "logs" are the systemd ones. Just emailing the logs doesn't constitute re-logging it to a new log. > The default behaviour of earlier version of logwatch was to send email > to root. (via cron) The default behavior of earlier versions of the logwatch archlinux package, yes. What about the default behavior of logwatch itself? Also, like, the vast majority of system logs aren't automatically emailed to root by the software itself. I guess the vast majority of logs in a systemd-based distro aren't emailed at all (because unlike cron, systemd does not do this by default). > So I guess if the timer was meant to be drop in replacement for cron > then it should e-mail too. Who said it was supposed to be a drop-in replacement for cron? The impression I got from looking at https://bugs.archlinux.org/task/56357 is that the timer was supposed to be a "migration from cron installs to the upstream systemd service". I really don't see why you think archlinux should be opinionated and modify upstream service files. I hear your argument that the package should have a post_upgrade message. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Recent logwatch update may need a news item?
Hello, ** Amish via arch-general [2019-09-20 05:59:11 +0530]: > On 19/09/19 10:44 pm, Eli Schwartz via arch-general wrote: >> On September 19, 2019 1:00:26 PM EDT, Amish via arch-general >> wrote: >>> those users who use logwatch that they need to take following actions: >>> >>> 1) pacman -Syu >>> >>> 2) cat /usr/lib/systemd/system/logwatch.service.d/local.conf >>> [Service] >>> ExecStart= >>> ExecStart=/usr/bin/logwatch --output mail >>> >>> 3) systemctl daemon-reload >>> 4) systemctl --now enable logwatch.timer Thank you for your message about changed behaviour of logwatch. I'm using it to mail logs from different host to one address. >> I guess it's entirely possible that users were logging without using >> mail at all. There are guides for generically forwarding systemd logs >> via email, though. > Thanks but why would one parse logs to log it back to logs? > The default behaviour of earlier version of logwatch was to send email to > root. (via cron) > So I guess if the timer was meant to be drop in replacement for cron then it > should e-mail too. So just look at the source: https://sourceforge.net/p/logwatch/git/ci/master/tree/scheduler/logwatch.cron https://sourceforge.net/p/logwatch/git/ci/master/tree/scheduler/logwatch.service and you will see that it is not Archlinux issue, it is logwatch one. They simply drop output to mail for service. I'm lack of time right now but if I were you I open a ticket to ask why service isn't 100% functional as cron job. > Amish. --- WBR, Vladimir Lomov -- I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. -- Professor Lowd, English, Ohio University signature.asc Description: PGP signature
Re: [arch-general] Recent logwatch update may need a news item?
On 19/09/19 10:44 pm, Eli Schwartz via arch-general wrote: On September 19, 2019 1:00:26 PM EDT, Amish via arch-general wrote: those users who use logwatch that they need to take following actions: 1) pacman -Syu 2) cat /usr/lib/systemd/system/logwatch.service.d/local.conf [Service] ExecStart= ExecStart=/usr/bin/logwatch --output mail 3) systemctl daemon-reload 4) systemctl --now enable logwatch.timer I guess it's entirely possible that users were logging without using mail at all. There are guides for generically forwarding systemd logs via email, though. Thanks but why would one parse logs to log it back to logs? The default behaviour of earlier version of logwatch was to send email to root. (via cron) So I guess if the timer was meant to be drop in replacement for cron then it should e-mail too. Amish.
Re: [arch-general] Recent logwatch update may need a news item?
On September 19, 2019 1:00:26 PM EDT, Amish via arch-general wrote: > Hello, > > Recently logwatch package was updated. > > The cron file (from cron.daily) was removed and replaced with > systemd.timer. > > But logwatch.timer is not activated automatically, which means the > users > who use logwatch will stop getting daily "auditing" emails and may not > > realize this for some days that emails from logwatch have stopped > coming. > > This requires manual intervention to activate logwatch.timer. > > Since keeping an eye on logs is very important thing to do, this > should > be put as NEWS item. (in my opinion). Your opinion is all nice and well, but what's wrong with a package post_upgrade notice? NEWS items for breaking changes are done when the breaking change needs to be resolved in order to successfully execute Pacman and upgrade the package at all. > > Additionally, current logwatch.service calls "/usr/sbin/logwatch" > alone. > Which means by default it sends output to systemd journal. (whereas > cron > based timer used to send an email to root which could be an alias to > real email address) > > To preserve the existing behaviour, the ExecStart line should be > changed > to ExecStart=/usr/bin/logwatch --output mail" > > Even if this is not made a news item, this email is also sent to alert > > those users who use logwatch that they need to take following actions: > > 1) pacman -Syu > > 2) cat /usr/lib/systemd/system/logwatch.service.d/local.conf > [Service] > ExecStart= > ExecStart=/usr/bin/logwatch --output mail > > 3) systemctl daemon-reload > 4) systemctl --now enable logwatch.timer I guess it's entirely possible that users were logging without using mail at all. There are guides for generically forwarding systemd logs via email, though. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: PGP signature
