Customised logwatch
146 views
Skip to first unread message
Andrew Milner
Jul 22, 2019, 12:45:06 AM7/22/19
to weewx-user
Is there a way to include logwatch additions which are preserved when weewx is updated??
I find that I always have to update the logwatch script to ignore
ftpgenerator: ftp'd
raw: deleted
historygenerator.pyc: Generated
messages when I update weewx. I used to just keep a backup of the script, but then got caught out when weewx changed a load of messages and so I needed the latest weewx supplied script and then updated the new one.
Just gone from 3.8.2 to 3.9.2 and of course the problem is back - logwatch is using the new weewx script and I had to do the custom ignores again.
Is there a better way of handling this??
Rick M0LEP
Jul 22, 2019, 2:56:36 AM7/22/19
to weewx...@googlegroups.com
On Mon 22 Jul Andrew Milner wrote:
> Is there a better way of handling this??
I don't edit logwatch filters that come with packages unless absolutely
> Is there a better way of handling this??
necessary, but put my own additional filters into a different file in
the appropriate directory (typically with a name prefixed with local- to
make them easy to find). That way they don't get clobbered by an
upgrade, though they may need editing if a new version formats its
messages differently...
--
73, Rick, M0LEP
Andrew Milner
Jul 22, 2019, 3:59:10 AM7/22/19
to weewx-user
that was my problem Rick - having to edit the weewx logwatch script to not include the weewx extensions - raw, historygenerator and for some reason ftpgenerator (not sure where that one came from anyway!!), so that my daily weewx logwatch file from the weewx standard package is not filled with these additional weewx messages. Or are you saying that I should prevent the additional messages going into the log in the first place?? No, I want the log to be complete so they need to be in there I just dont want logwatch spitting them out again!!
Rick M0LEP
Jul 22, 2019, 5:31:13 AM7/22/19
to weewx...@googlegroups.com
I think I was confusing logwatch and logcheck; logcheck has directories
for various categories of messages including "ignore" of which I make
much use, while logwatch has scripts it runs for each service, which
means it can do rather more with the messages, but makes it a bit less
easily tailored...
On Mon 22 Jul Andrew Milner wrote:
> that was my problem Rick - having to edit the weewx logwatch script to not
> include the weewx extensions - raw, historygenerator and for some reason
> ftpgenerator (not sure where that one came from anyway!!), so that my daily
> weewx logwatch file from the weewx standard package is not filled with
> these additional weewx messages. Or are you saying that I should prevent
> the additional messages going into the log in the first place?? No, I want
> the log to be complete so they need to be in there I just dont want
> logwatch spitting them out again!!
--
73, Rick, M0LEP
for various categories of messages including "ignore" of which I make
much use, while logwatch has scripts it runs for each service, which
means it can do rather more with the messages, but makes it a bit less
easily tailored...
On Mon 22 Jul Andrew Milner wrote:
> that was my problem Rick - having to edit the weewx logwatch script to not
> include the weewx extensions - raw, historygenerator and for some reason
> ftpgenerator (not sure where that one came from anyway!!), so that my daily
> weewx logwatch file from the weewx standard package is not filled with
> these additional weewx messages. Or are you saying that I should prevent
> the additional messages going into the log in the first place?? No, I want
> the log to be complete so they need to be in there I just dont want
> logwatch spitting them out again!!
73, Rick, M0LEP
Andrew Milner
Jul 25, 2019, 9:10:20 AM7/25/19
to weewx-user
Just a bump .... any other suggestions/ideas or is it possible for other wiki based drivers and extensions to be included in the default weewx logwatch ignore list somehow?? maybe some form of customisation file which could be actioned/included - but how??
vince
Jul 25, 2019, 2:11:56 PM7/25/19
to weewx-user
On Thursday, July 25, 2019 at 6:10:20 AM UTC-7, Andrew Milner wrote:
Just a bump .... any other suggestions/ideas or is it possible for other wiki based drivers and extensions to be included in the default weewx logwatch ignore list somehow?? maybe some form of customisation file which could be actioned/included - but how??
Uncertain what you're asking here. There are limitations on how much weewx should touch optional other stuff you can hook it up to. For example, do you run syslog, rsyslog, syslog-ng, or multiples ? At some point the admin has to do the steps to admin their box to get the result 'they' want it to have. The admin gets the last word, but that means sometimes they need to do a little more work too.
gjr80
Jul 25, 2019, 2:49:39 PM7/25/19
to weewx-user
The logwatch script needs to be modularised so that users can easily extend the basic logwatch script functionality to cater for extensions and other customisations the user may have installed. The current top to bottom ‘if..elif..else’ structure does not lend itself to being easily extended in a manner that survives upgrades etc.
We are aware of the issue but it will probably take until we find the roundtoit before we get around to it.
Gary
We are aware of the issue but it will probably take until we find the roundtoit before we get around to it.
Gary
Andrew Milner
Jul 25, 2019, 10:19:24 PM7/25/19
to weewx-user
Hope the tuit surfaces soon!!! You summarised the issue perfectly.
vince
Jul 26, 2019, 10:52:02 AM7/26/19
to weewx-user
On Thursday, July 25, 2019 at 11:49:39 AM UTC-7, gjr80 wrote:
The current top to bottom ‘if..elif..else’ structure does not lend itself to being easily extended in a manner that survives upgrades etc.
Agree - if you keep the file in weewx's directory namespace that is.
Doesn't logwatch typically search a configurable set of locations ? Why not just stash a (modified) copy someplace outside a directory weewx would overwrite on a version update ?
Or am I missing something ?
(just curious - I don't use logwatch for my sites)
Andrew Milner
Jul 26, 2019, 1:01:47 PM7/26/19
to weewx-user
because logwatch is updated as weewx is updated if messages are altered - so if weewx provides an updated version the stashed away copy with the customisation becomes unusable basically.
vince
Jul 26, 2019, 1:45:04 PM7/26/19
to weewx-user
On Friday, July 26, 2019 at 10:01:47 AM UTC-7, Andrew Milner wrote:
because logwatch is updated as weewx is updated if messages are altered - so if weewx provides an updated version the stashed away copy with the customisation becomes unusable basically.
Again - confused here.
Does weewx install something logwatch-related so that logwatch does something different than before weewx was present ?
I'm not aware of that.
Looked to me like the setup.py just sticks files into the /home/weewx/utils directory like lots of other things it we can use as-is, or not use, or hack on, or not hack on, at our discretion.
gjr80
Jul 26, 2019, 3:35:34 PM7/26/19
to weewx-user
I’m sorry but I don’t understand the confusion here. WeeWX ships with 3 logwatch files; 2 config files and a script. The script is what analyses the WeeWX log and produces the WeeWX logwatch report. The WeeWX installer does not ‘install’ the WeeWX logwatch files, rather the user must install them separately as per the wiki. The suggested approach is to create symlinks (in the relevant logwatch directories) to the supplied files.
Of course you can make a copy of the script elsewhere, modify it to suit your needs and then link to that file instead (this is what I do). Problem is if there is a change to the core WeeWX logging, and the WeeWX logwatch script is changed accordingly, then those logwatch script changes will not flow through to the copied/modified script being used. The other approach is to create another separate script, a link for which can be placed in the appropriate logwatch directory. Works fine but you will now have a second logwatch report being produced, it will not be part of the logwatch report produced by the logwatch script shipped with WeeWX. Have never been a sysadmin but I don’t think either approach is appropriate or acceptable.
This is very similar to customising some WeeWX function. You can modify the core code on your install and it will certainly work as you want, though you now have an orphan that will likely fail post upgrade. Alternatively, you can create a custom service, driver or whatever, place it in the user directory and call it appropriately from weewx.conf and it will coexist quite happily with WeeWX into the future even across upgrades.
Gary
Of course you can make a copy of the script elsewhere, modify it to suit your needs and then link to that file instead (this is what I do). Problem is if there is a change to the core WeeWX logging, and the WeeWX logwatch script is changed accordingly, then those logwatch script changes will not flow through to the copied/modified script being used. The other approach is to create another separate script, a link for which can be placed in the appropriate logwatch directory. Works fine but you will now have a second logwatch report being produced, it will not be part of the logwatch report produced by the logwatch script shipped with WeeWX. Have never been a sysadmin but I don’t think either approach is appropriate or acceptable.
This is very similar to customising some WeeWX function. You can modify the core code on your install and it will certainly work as you want, though you now have an orphan that will likely fail post upgrade. Alternatively, you can create a custom service, driver or whatever, place it in the user directory and call it appropriately from weewx.conf and it will coexist quite happily with WeeWX into the future even across upgrades.
Gary
vince
Jul 26, 2019, 4:24:44 PM7/26/19
to weewx-user
On Friday, July 26, 2019 at 12:35:34 PM UTC-7, gjr80 wrote:
The WeeWX installer does not ‘install’ the WeeWX logwatch files, rather the user must install them separately as per the wiki. The suggested approach is to create symlinks (in the relevant logwatch directories) to the supplied files.
Agree - if you want to install the utility once and thereafter run it unedited then you get free upgrades essentially afterward if the copy that comes with weewx changes. Same for the systemd or init.d startup files or anything else that needs to hook into the os as either a mandatory thing or optional user-installed utility.
Of course you can make a copy of the script elsewhere, modify it to suit your needs and then link to that file instead (this is what I do). Problem is if there is a change to the core WeeWX logging, and the WeeWX logwatch script is changed accordingly, then those logwatch script changes will not flow through to the copied/modified script being used.
Of course. If you choose to edit it you are taking the responsibility to own your edited copy and handle any breakage if weewx moves under your feet, so to speak, in a future release.
The other approach is to create another separate script, a link for which can be placed in the appropriate logwatch directory. Works fine but you will now have a second logwatch report being produced, it will not be part of the logwatch report produced by the logwatch script shipped with WeeWX. Have never been a sysadmin but I don’t think either approach is appropriate or acceptable.
I've been a sysadmin for 30+ years and would say there are a variety of appropriate/acceptable approaches especially when logging is involved.
Personally I like componentization and the ability to turn stuff on+off as well as the ability to add new things. That's why I like .d directories so much (or sites-enabled if you think webservers etc.).
The risk I think I'm trying to bring up is there seems to be a natural tension between making weewx infinitely extensible+configurable vs. keeping it 'wee'. My opinion is this particular one's original request violates the 'keep it wee' mindset perhaps, maybe, depending on implementation.
It's kinda like crontabs. You violate 'wee' if you just edit the system crontab. You are nice and componentized if you use crontabs (directory) and drop in pieces as components you can easily add/supersede/delete into what happens as an aggregated whole.
If logwatch could be made to work that way, seems worth thinking about trying to do when getroundtoit happens.
Leon Shaner
Jul 26, 2019, 9:14:04 PM7/26/19
to weewx...@googlegroups.com
The Linux logrotate always works for anything I need. It's very flexible. I have an example on my weewx clone on GitHub in the watchdog util branch:
https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog
Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPhone)--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/99093fab-14af-4c1e-adf9-6d79599f460f%40googlegroups.com.
Andrew Milner
Jul 26, 2019, 9:47:04 PM7/26/19
to weewx-user
Leon - the thread was about logwatch not logrotate.
On Saturday, 27 July 2019 04:14:04 UTC+3, Leon Shaner wrote:
The Linux logrotate always works for anything I need. It's very flexible. I have an example on my weewx clone on GitHub in the watchdog util branch:
https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdogRegards,Leon--Leon Shaner :: Dearborn, Michigan (iPhone)
The logwatch script needs to be modularised so that users can easily extend the basic logwatch script functionality to cater for extensions and other customisations the user may have installed. The current top to bottom ‘if..elif..else’ structure does not lend itself to being easily extended in a manner that survives upgrades etc.
We are aware of the issue but it will probably take until we find the roundtoit before we get around to it.
Gary
--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages