logwatch-devel — Logwatch Development List

[Logwatch-devel] fail2ban and systemd-journald

[Monsieur Me <tel...@ya...>]

Hello,
I recently tried to migrate logwatch's configuration that monitors service fail2ban from syslog files to systemd-journald. My configuration changes took effect, ie, logwatch-er now issues a "journalctl --unit=fail2ban.service --output=cat" command to read the logs, however the log parser no longer matches anything and reports all the log lines as "unmatched entries".
Upon further inspection, it seems that syslog and systemd-journald outputs are not identical and thus incompatible with the parser. In particular, syslog prints the loglevel {DEBUG, INFO, WARNING, ...} on each log line, whereas systemd-journald does not. The logwatcher parser anchors on these loglevel values to parse and extract the useful info from each line. 
Arguebly, systemd-journald could print the loglevel (or priority as it is known for journalctl)... or the parser could make the loglevel value optional. Would it be feasible to update the regexps to ignore the loglevel ?
Thank you,Codin

Re: [Logwatch-devel] Questions about archives

[Bjorn <bj...@us...>]

On 6/25/25 15:14, Orion Poplawski wrote:

>>
>> Admittedly both cases don't occur very often.  Can't think of a universal fix
>> - perhaps introduce a new variable in the corresponding conf/logfiles
>> configuration file?  It would suffice for the first scenario (service-specific
>> when logged in UTC timezone), which is the more likely one to be encountered.
> 
> But we are not comparing the timestamps in the logs at this point - we are
> comparing the times specified in the --range argument with the timestamps of
> the archived log files.

Not sure we differ in our interpretation.  Indeed, we are comparing the 
range with the timestamps in the log.  The issue is that we determine 
whether we should look inside the [archive] file by looking at its 
modified timestamp (using stat).

But I also think that two days is a bit conservative.  It can be more 
than one day, though.  For example:

- server is in British Summer Time
- logging service is using GMT
- cron job for logwatch is run daily just before midnight

In that case, to capture all log statements with 'yesterday' timestamps, 
you need not only the previous day's logs (as per file modification 
time), but an additional hour beyond that.

Similarly if a  logging server in the U.S. EST timezone is logging 
activity from a system on the West Coast, using PST timestamps, for example.

The rounding to an additional full day might have been because typically 
Logwatch is run once a day, and - with anacron, at least - its exact 
time can vary.

> I'm leaning towards add a --archivefudgefactor (or similar) option that
> defaults to 2 to be able to change this.

Not sure of the significance of '2'?  Is it merely a flag, or does it 
indicate 'two days'?

Ideally the option would be per service, but I think as an option for 
all services makes the implementation much simpler.

> '--archives 0' does nothing - the --archives option does not take arguments.

Ah, yes.  I do support the --noarchives option you propose.

Re: [Logwatch-devel] Questions about archives

[Orion P. <or...@nw...>]

On 6/24/25 19:05, Bjorn via Logwatch-devel wrote:
> On 6/24/25 17:58, Bjorn wrote:
> 
>> Admittedly both cases don't occur very often.  Can't think of a universal
>> fix - perhaps introduce a new variable in the corresponding conf/logfiles
>> configuration file?  It would suffice for the first scenario (service-
>> specific when logged in UTC timezone), which is the more likely one to be
>> encountered.
>>
>> Bjorn
>>
> 
> P.S.  Another solution is to run Logwatch with '--range all' and
> '--archives 0' before you rotate the log.  So the Logwatch period is not
> aligned to the specific date (like 'yesterday').  But it would capture all the
> logs, provided the 'logwatch' and 'logrotate' runs are synchronized.

'--archives 0' does nothing - the --archives option does not take arguments.

-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
Manager of IT Systems                      720-772-5637
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Logwatch-devel] Questions about archives

[Orion P. <or...@nw...>]

On 6/24/25 18:58, Bjorn via Logwatch-devel wrote:
> On 6/24/25 12:05, Orion Poplawski wrote:
>> logwatch man has:
>>
>>   --archives
>>      Each log-file-group has basic logfiles (i.e. /var/log/messages) as well
>> as  archives  (i.e.  /var/log/mes‐
>>      sages.?  or  /var/log/messages.?.gz).   When used with "--range all", this
>> option will make Logwatch search
>>      through the archives in addition to the regular logfiles.  For  other
>> values  of  --range,  Logwatch  will
>>      search the appropriate archived logs.
>>
>> Which seems to indicate that searching the archives is disabled by default.
>> But this is not the case:
>>
>> # Default config here...
>> ...
>> $Config{'archives'} = 1;
>>
>> It has apparently been this way for a long time - since at least 2010 when svn
>> starts.
>>
>> This probably needs to stay this way for now since it's been that way for so
>> long, but the problem (aside from incorrect documentation) is that there seems
>> to be no way to disable searching the archives.
>>
>> This seems to be a simple fix though:
>>
>> --- a/scripts/logwatch.pl
>> +++ b/scripts/logwatch.pl
>> @@ -204,7 +204,7 @@ my ($tmp_mailto, $tmp_savefile);
>>                "s|service=s@" => \@TempServiceList,
>>                "m|mailto=s"   => \$tmp_mailto,
>>                "filename=s"   => \$tmp_savefile,
>> -             "a|archives"   => \$Config{'archives'},
>> +             "a|archives!"  => \$Config{'archives'},
>>                "debug=s"      => \$Config{'debug'},
>>                "r|range=s"    => \$Config{'range'},
>>                "n|numeric"    => \$Config{'numeric'},
>>
>> allows specifying --noarchives.  I'll work on a PR to update that and some
>> docs.  It's not a big deal though I think, because in practice I think
>> archives need to always be processed in order to capture all of the relevant
>> logs.
>>
> 
> 
> Can't remember if the meaning of '--archives' changed over time, but is
> possible it happened when '--range' was expanded beyond the original (I
> think)  'yesterday,' 'today,' and 'all.'  But I think the man page more or
> less captures the current meaning:  it determines what '--range all' means:
> does it include only the current (as defined by 'LogFile') logs, or does it
> include the older logs (as defined by 'Archive') as well?
> 
> [Well, it does change the meaning of any '--range' value, actually.  But most
> people would expect the default of --archives to be true if whatever --range
> is selected is to capture all the appropriate log files.]

I don't think the man page captures that archives is set to true by default.

I've submitted a MR here https://sourceforge.net/p/logwatch/git/merge-requests/75/

>>
>> Next issue is how many archives get processed.  The code has:
>>
>>           # range is something else, and we need to get one
>>         # day ahead. A day has 86400 seconds.  (We double
>>         # that to deal with different timezones.)
>>         $CheckTime = $time_t[0] - 86400*2;
>>
>> I'm noticing this because I'm dealing with some very large log files that get
>> rotated daily.  Even processing an extra day can end up filling the disk with
>> the cache file that logwatch creates.  The doubling has been there for at
>> least the same amount of time.  But I'm really not sure it's necessary.  What
>> kind of different timezone thing could we be dealing with?
> 
> I think the reasoning there was that some services log in UTC timezone, but
> the filesystem uses the local timezone.  And Logwatch looks at the
> modification date as a quick check on whether the file should be examined.  A
> similar scenario would arise for remote logging (the log strings are generated
> in a remote timezone, but the log filesystem is in the local timezone of the
> log server).
> 
> Admittedly both cases don't occur very often.  Can't think of a universal fix
> - perhaps introduce a new variable in the corresponding conf/logfiles
> configuration file?  It would suffice for the first scenario (service-specific
> when logged in UTC timezone), which is the more likely one to be encountered.

But we are not comparing the timestamps in the logs at this point - we are
comparing the times specified in the --range argument with the timestamps of
the archived log files.

I'm leaning towards add a --archivefudgefactor (or similar) option that
defaults to 2 to be able to change this.


-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
Manager of IT Systems                      720-772-5637
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Logwatch-devel] Questions about archives

[Bjorn <bj...@us...>]

On 6/24/25 12:05, Orion Poplawski wrote:
> logwatch man has:
> 
>   --archives
>      Each log-file-group has basic logfiles (i.e. /var/log/messages) as well
> as  archives  (i.e.  /var/log/mes‐
>      sages.?  or  /var/log/messages.?.gz).   When used with "--range all", this
> option will make Logwatch search
>      through the archives in addition to the regular logfiles.  For  other
> values  of  --range,  Logwatch  will
>      search the appropriate archived logs.
> 
> Which seems to indicate that searching the archives is disabled by default.
> But this is not the case:
> 
> # Default config here...
> ...
> $Config{'archives'} = 1;
> 
> It has apparently been this way for a long time - since at least 2010 when svn
> starts.
> 
> This probably needs to stay this way for now since it's been that way for so
> long, but the problem (aside from incorrect documentation) is that there seems
> to be no way to disable searching the archives.
> 
> This seems to be a simple fix though:
> 
> --- a/scripts/logwatch.pl
> +++ b/scripts/logwatch.pl
> @@ -204,7 +204,7 @@ my ($tmp_mailto, $tmp_savefile);
>                "s|service=s@" => \@TempServiceList,
>                "m|mailto=s"   => \$tmp_mailto,
>                "filename=s"   => \$tmp_savefile,
> -             "a|archives"   => \$Config{'archives'},
> +             "a|archives!"  => \$Config{'archives'},
>                "debug=s"      => \$Config{'debug'},
>                "r|range=s"    => \$Config{'range'},
>                "n|numeric"    => \$Config{'numeric'},
> 
> allows specifying --noarchives.  I'll work on a PR to update that and some
> docs.  It's not a big deal though I think, because in practice I think
> archives need to always be processed in order to capture all of the relevant logs.
> 


Can't remember if the meaning of '--archives' changed over time, but is 
possible it happened when '--range' was expanded beyond the original (I 
think)  'yesterday,' 'today,' and 'all.'  But I think the man page more 
or less captures the current meaning:  it determines what '--range all' 
means: does it include only the current (as defined by 'LogFile') logs, 
or does it include the older logs (as defined by 'Archive') as well?

[Well, it does change the meaning of any '--range' value, actually.  But 
most people would expect the default of --archives to be true if 
whatever --range is selected is to capture all the appropriate log files.]



> 
> Next issue is how many archives get processed.  The code has:
> 
>           # range is something else, and we need to get one
>         # day ahead. A day has 86400 seconds.  (We double
>         # that to deal with different timezones.)
>         $CheckTime = $time_t[0] - 86400*2;
> 
> I'm noticing this because I'm dealing with some very large log files that get
> rotated daily.  Even processing an extra day can end up filling the disk with
> the cache file that logwatch creates.  The doubling has been there for at
> least the same amount of time.  But I'm really not sure it's necessary.  What
> kind of different timezone thing could we be dealing with?

I think the reasoning there was that some services log in UTC timezone, 
but the filesystem uses the local timezone.  And Logwatch looks at the 
modification date as a quick check on whether the file should be 
examined.  A similar scenario would arise for remote logging (the log 
strings are generated in a remote timezone, but the log filesystem is in 
the local timezone of the log server).

Admittedly both cases don't occur very often.  Can't think of a 
universal fix - perhaps introduce a new variable in the corresponding 
conf/logfiles configuration file?  It would suffice for the first 
scenario (service-specific when logged in UTC timezone), which is the 
more likely one to be encountered.

Bjorn

Re: [Logwatch-devel] Questions about archives

[Bjorn <bj...@us...>]

On 6/24/25 17:58, Bjorn wrote:

> Admittedly both cases don't occur very often.  Can't think of a 
> universal fix - perhaps introduce a new variable in the corresponding 
> conf/logfiles configuration file?  It would suffice for the first 
> scenario (service-specific when logged in UTC timezone), which is the 
> more likely one to be encountered.
> 
> Bjorn
> 

P.S.  Another solution is to run Logwatch with '--range all' and
'--archives 0' before you rotate the log.  So the Logwatch period is not 
aligned to the specific date (like 'yesterday').  But it would capture 
all the logs, provided the 'logwatch' and 'logrotate' runs are synchronized.

[Logwatch-devel] Questions about archives

[Orion P. <or...@nw...>]

logwatch man has:

 --archives
    Each log-file-group has basic logfiles (i.e. /var/log/messages) as well
as  archives  (i.e.  /var/log/mes‐
    sages.?  or  /var/log/messages.?.gz).   When used with "--range all", this
option will make Logwatch search
    through the archives in addition to the regular logfiles.  For  other
values  of  --range,  Logwatch  will
    search the appropriate archived logs.

Which seems to indicate that searching the archives is disabled by default.
But this is not the case:

# Default config here...
...
$Config{'archives'} = 1;

It has apparently been this way for a long time - since at least 2010 when svn
starts.

This probably needs to stay this way for now since it's been that way for so
long, but the problem (aside from incorrect documentation) is that there seems
to be no way to disable searching the archives.

This seems to be a simple fix though:

--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -204,7 +204,7 @@ my ($tmp_mailto, $tmp_savefile);
              "s|service=s@" => \@TempServiceList,
              "m|mailto=s"   => \$tmp_mailto,
              "filename=s"   => \$tmp_savefile,
-             "a|archives"   => \$Config{'archives'},
+             "a|archives!"  => \$Config{'archives'},
              "debug=s"      => \$Config{'debug'},
              "r|range=s"    => \$Config{'range'},
              "n|numeric"    => \$Config{'numeric'},

allows specifying --noarchives.  I'll work on a PR to update that and some
docs.  It's not a big deal though I think, because in practice I think
archives need to always be processed in order to capture all of the relevant logs.


Next issue is how many archives get processed.  The code has:

         # range is something else, and we need to get one
       # day ahead. A day has 86400 seconds.  (We double
       # that to deal with different timezones.)
       $CheckTime = $time_t[0] - 86400*2;

I'm noticing this because I'm dealing with some very large log files that get
rotated daily.  Even processing an extra day can end up filling the disk with
the cache file that logwatch creates.  The doubling has been there for at
least the same amount of time.  But I'm really not sure it's necessary.  What
kind of different timezone thing could we be dealing with?


-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
Manager of IT Systems                      720-772-5637
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [Logwatch-devel] Service config variable naming

[Bjorn <bj...@us...>]

On 10/2/24 17:24, Orion Poplawski wrote:
> We have some inconsistency with service config variable naming.  Many 
> prefix the variable name with the service, e.g. 
> "$vsftpd_ignore_unmatched" and others do not, e.g. qmail.conf:$threshold.
> 
> Do we want to establish a preference going forward?

I do favor using the service name prefix.  Long time ago I thought there 
as an issue with conflicting names, but I can't remember what it was. 
It might have been related to the global scope of the ENV variable.  As 
you mention, "going forward" is important, to keep backwards compatibility.

On an related topic, I also favor prefixing the service-specific 
variable names with a dollar sign ($).  The Logwatch-defined ones 
(Display, Title, LogFile, etc.) used for all scripts don't have the 
dollar sign.  Almost all the scripts follow this convention, but some do 
not (sssd.conf doesn't use the dollar sign prefix on service-specific 
variables).



Re: Add format utility subroutines

These routines would be helpful in developing new scripts (in ease and 
standardizing, as you said).  Although sometimes it is preferable to 
output in a tabular or aligned format, but that is very dependent on the 
keys/values displayed.

[Logwatch-devel] Service config variable naming

[Orion P. <or...@nw...>]

We have some inconsistency with service config variable naming.  Many 
prefix the variable name with the service, e.g. 
"$vsftpd_ignore_unmatched" and others do not, e.g. qmail.conf:$threshold.

Do we want to establish a preference going forward?


-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Logwatch-devel] script and conf to catch dnf-automatic output

[Clive L. <cl...@ci...>]

Hello developers,

    Due to the eol of centos 7 this year, I have migrated some of my
home lab services to centos stream 9. In this distribution, yum-cron
has been replaced by dnf-automatic, and logwatch does not capture
dnf-automatic output.

    Since the output is well summarized, I created a simple script and
configuration for logwatch to capture it. I am sharing these files
here for further testing, as I currently only have centos stream 9 and
logwatch 7.5.5.

    To test, simply copy these two files on gist

https://gist.github.com/evi1c/d02ed4a47478c098ba59dbc0663d0493

    to these locations accordingly

dnf-automatic.conf -> /etc/logwatch/conf/services/dnf-automatic.conf
dnf-automatic -> /etc/logwatch/scripts/services/dnf-automatic

Cheers,
clive

[Logwatch-devel] script and conf to catch dnf-automatic output

[Clive L. <cl...@ci...>]

Hello developers,

    Due to the eol of centos 7 this year, I have migrated some of my
home lab services to centos stream 9. In this distribution, yum-cron
has been replaced by dnf-automatic, and logwatch does not capture
dnf-automatic output.

    Since the output is well summarized, I created a simple script and
configuration for logwatch to capture it. I am sharing these files
here for further testing, as I currently only have centos stream 9 and
logwatch 7.5.5.

    To test, simply copy these two files accordingly:

dnf-automatic.conf.txt
-> /etc/logwatch/conf/services/dnf-automatic.conf

dnf-automatic.txt
-> /etc/logwatch/scripts/services/dnf-automatic

[Logwatch-devel] Logwatch mail not always sent

[Gestió S. <sys...@ua...>]

Hello,

Sometimes, I think when there is no "login" in the system, logwatch mail is not sent, but "cron" process has run OK (I can check this in /var/log/cron). Why? Can I force logwatch to send mails always?

Thanks.

Re: [Logwatch-devel] When the smartRAW temperature is enabled, it cannot be resolved.

[Bjorn <bj...@us...>]

 > On Debian 5.10.178-3

I assume Linux kernel 5.10.178-3.  What is the smartmontools version 
(smartctl -V | head -1)?

We did add support for Raw values last year (available in the current 
Logwatch 7.8-3), but it appears that you are using a custom declaration 
using the tempminmax format.  It is hard for Logwatch to accommodate 
custom log formats.  The standard -R option, which provides raw values, 
should work.

Interestingly, I believe that Logwatch does compute Min/Max values when 
smartd is invoked with the standard -R option, based on the smartd 
script/services/smartd code.



On 5/10/23 22:34, 于刚毅 wrote:
> On Debian 5.10.178-3, rows with RAW values cannot be matched.
> 
> The script   /usr/share/logwatch/scripts/services/smartd 。 It looks 
> like the regex at the 147 line position cannot be matched。
> 
> ----------------------------------------------------------
> # Normal recording
> May 11 07:00:21 yxhserver smartd[512]: Device: /dev/sdb [SAT], SMART 
> Usage Attribute: 194 Temperature_Celsius changed from 109 to 108
> 
> # when smart enable RAW temperture, This line cannot be matched
> May 11 11:14:53 yxhserver smartd[531]: Device: /dev/sda [SAT], SMART 
> Usage Attribute: 194 Temperature_Celsius changed from 60 [Raw 40 
> (Min/Max 0/54)] to 59 [Raw 41 (Min/Max 0/54)]
> 
> --------------------------------------------------------
> Errors :
> 
>   **Unmatched Entries**
>   Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius 
> changed from 59 [Raw 41 (Min/Max 0/54)] to 60 [Raw 40 (Min/Max 0/54)] : 
> 1 time(s)
>   Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius 
> changed from 60 [Raw 40 (Min/Max 0/54)] to 59 [Raw 41 (Min/Max 0/54)] : 
> 1 time(s)
>   Device: /dev/sda [SAT], no Attribute 231, ignoring -R 231 : 3 time(s)
>   Device: /dev/sdb [SAT], no Attribute 231, ignoring -R 231 : 3 time(s)
>   Executing test of <mail> to root ... : 2 time(s)
>   Test of <mail> to root: successful : 2 time(s)
> 
> -------------------------------------------------------
> 
> Thankyou for your greate job!
> 
> 
> 
> 
> 
> _______________________________________________
> Logwatch-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logwatch-devel

[Logwatch-devel] When the smartRAW temperature is enabled, it cannot be resolved.

[于刚毅 <ou....@16...>]

On Debian 5.10.178-3, rows with RAW values cannot be matched.



The script   /usr/share/logwatch/scripts/services/smartd 。 It looks like the regex at the 147 line position cannot be matched。


----------------------------------------------------------

# Normal recording

May 11 07:00:21 yxhserver smartd[512]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 109 to 108



# when smart enable RAW temperture, This line cannot be matched
May 11 11:14:53 yxhserver smartd[531]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 60 [Raw 40 (Min/Max 0/54)] to 59 [Raw 41 (Min/Max 0/54)]


--------------------------------------------------------
Errors :


 **Unmatched Entries**
 Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 59 [Raw 41 (Min/Max 0/54)] to 60 [Raw 40 (Min/Max 0/54)] : 1 time(s)
 Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 60 [Raw 40 (Min/Max 0/54)] to 59 [Raw 41 (Min/Max 0/54)] : 1 time(s)
 Device: /dev/sda [SAT], no Attribute 231, ignoring -R 231 : 3 time(s)
 Device: /dev/sdb [SAT], no Attribute 231, ignoring -R 231 : 3 time(s)
 Executing test of <mail> to root ... : 2 time(s)
 Test of <mail> to root: successful : 2 time(s)


-------------------------------------------------------


Thankyou for your greate job!

Re: [Logwatch-devel] Removing Unmatched Entries from logwatch

[Khodor B. <kh...@po...>]

Hi Frank,

I am using Logwatch 7.4.3 (04/27/16 from redhat repo,

I will be asking redhat about that ,

Thanks a lot for your reply and advice 


-----Original Message-----
From: Frank Crawford [mailto:fr...@cr...] 
Sent: Saturday, April 1, 2023 4:53 AM
To: Khodor Barakat <kh...@po...>; log...@li...
Subject: Re: [Logwatch-devel] Removing Unmatched Entries from logwatch

On Fri, 2023-03-31 at 17:31 +0000, Khodor Barakat wrote:
> Hi ,
>  
> I have upgraded my systems from redhat 7 to redhat 8 and after the 
> upgrade the output of logwatch is showing additional log entries that 
> didn’t show on redhat 7 ,

Two quick related questions, what version of logwatch is this for (see in the top of the report) and is this the version from the RedHat repository or from the Logwatch website?

If you are use the one shipped by RedHat, please log a bug report to them, as they don't seem to ever upgrade the version after their first ship for a release.

And then you can down load the RPM from the Logwatch website and  it should install with no issues.
> 
> how can I remove the following entries from logwatch report:
>  
> What is the best way to remove those unmatched entries
>  
> ·        From Postfix remove the unmatched entries of ssl negotiation 
> since I am using tls in my postfix configuration

I don't know if these are fixed in latest official version, as I don't use Postfix, but that module is regularly updated and if it isn't I'm pretty sure it will get handled quickly.

> 
> --------------------- Postfix Begin ------------------------
>  
>   282.378M  Bytes accepted                           296,095,186
>     1.085G  Bytes sent via SMTP                      1,165,358,661
>     1.384M  Bytes delivered                          1,450,907 
> ========   ==================================================
>        70   Accepted                                   100.00%
> --------   --------------------------------------------------
>        70   Total                                      100.00% 
> ========   ==================================================
>         4   Connections                                      4
>         4   Disconnections                                   4
>        73   Removed from queue                              73
>       20   Delivered                                       20
>       167   Sent via SMTP                                  167
>         3   Bounced (remote)                                 3
>        70   Warned                                          70
>         3   Notifications sent                               3
>        87   TLS connections (client)                        87
>  
>  
> **Unmatched Entries**
>         1   Mar 29 11:42:57 server1postfix/smtp[3128564]:
> mail.protection.outlook.com[104.47.75.164]:25: depth=0 verify=1 
> subject=/C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=mail.protection.outlook.com
>         1   Mar 29 14:32:02 server1postfix/smtp[3231872]:
> mail.protection.outlook.com[104.47.75.228]:25: depth=1 verify=1 
> subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
>         1   Mar 29 13:17:34 server1postfix/smtp[3185410]:
> mail.protection.outlook.com[8.31.233.62]:25: depth=0 verify=1 
> subject=/C=US/ST=Texas/L=Dallas/O=ZixCorp Systems, 
> Inc./CN=*.arsmtp.com
>         1   Mar 29 13:34:19 server1postfix/smtp[3195359]:
> mail.protection.outlook.com[104.47.75.164]:25: depth=1 verify=1 
> subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
>         1   Mar 29 11:31:42 server1postfix/smtp[3121738]:
> mail.protection.outlook.com[104.47.75.164]:25: depth=1 verify=1 
> subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
>  
> And so on …
> ---------------------- Postfix End -------------------------
>  
>  
> ·        From system remove session-*….scope

I know these are handled in the current release and have been for some time.  In fact it generates a report on them.
>  
> --------------------- Systemd Begin ------------------------
>  
>  
>  **Unmatched Entries**
>  
>     session-1083006.scope: Succeeded.: 1 Time(s)
>     session-1086439.scope: Succeeded.: 1 Time(s)
>     session-1086441.scope: Succeeded.: 1 Time(s)
>     session-1086442.scope: Succeeded.: 1 Time(s)
>     session-1086443.scope: Succeeded.: 1 Time(s)
>     session-1086444.scope: Succeeded.: 1 Time(s)
>     session-1086445.scope: Succeeded.: 1 Time(s)
>     session-1086446.scope: Succeeded.: 1 Time(s)
>     session-1086447.scope: Succeeded.: 1 Time(s)
> 
> 
> ---------------------- Systemd End -------------------------
>  
>  
> Any help would be highly appreciated

Regards
Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
> _______________________________________________
> Logwatch-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logwatch-devel

Re: [Logwatch-devel] Removing Unmatched Entries from logwatch

[Frank C. <fr...@cr...>]

On Fri, 2023-03-31 at 17:31 +0000, Khodor Barakat wrote:
> Hi ,
>  
> I have upgraded my systems from redhat 7 to redhat 8 and after the
> upgrade the output of logwatch is showing additional log entries that
> didn’t show on redhat 7 ,

Two quick related questions, what version of logwatch is this for (see
in the top of the report) and is this the version from the RedHat
repository or from the Logwatch website?

If you are use the one shipped by RedHat, please log a bug report to
them, as they don't seem to ever upgrade the version after their first
ship for a release.

And then you can down load the RPM from the Logwatch website and  it
should install with no issues.
> 
> how can I remove the following entries from logwatch report:
>  
> What is the best way to remove those unmatched entries
>  
> ·        From Postfix remove the unmatched entries of ssl negotiation
> since I am using tls in my postfix configuration

I don't know if these are fixed in latest official version, as I don't
use Postfix, but that module is regularly updated and if it isn't I'm
pretty sure it will get handled quickly.

> 
> --------------------- Postfix Begin ------------------------ 
>  
>   282.378M  Bytes accepted                           296,095,186
>     1.085G  Bytes sent via SMTP                      1,165,358,661
>     1.384M  Bytes delivered                          1,450,907
> ========   ==================================================
>        70   Accepted                                   100.00%
> --------   --------------------------------------------------
>        70   Total                                      100.00%
> ========   ==================================================
>         4   Connections                                      4
>         4   Disconnections                                   4
>        73   Removed from queue                              73
>       20   Delivered                                       20
>       167   Sent via SMTP                                  167
>         3   Bounced (remote)                                 3
>        70   Warned                                          70
>         3   Notifications sent                               3
>        87   TLS connections (client)                        87
>  
>  
> **Unmatched Entries**
>         1   Mar 29 11:42:57 server1postfix/smtp[3128564]:
> mail.protection.outlook.com[104.47.75.164]:25: depth=0 verify=1
> subject=/C=US/ST=Washington/L=Redmond/O=Microsoft
> Corporation/CN=mail.protection.outlook.com
>         1   Mar 29 14:32:02 server1postfix/smtp[3231872]:
> mail.protection.outlook.com[104.47.75.228]:25: depth=1 verify=1
> subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
>         1   Mar 29 13:17:34 server1postfix/smtp[3185410]:
> mail.protection.outlook.com[8.31.233.62]:25: depth=0 verify=1
> subject=/C=US/ST=Texas/L=Dallas/O=ZixCorp Systems,
> Inc./CN=*.arsmtp.com
>         1   Mar 29 13:34:19 server1postfix/smtp[3195359]:
> mail.protection.outlook.com[104.47.75.164]:25: depth=1 verify=1
> subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
>         1   Mar 29 11:31:42 server1postfix/smtp[3121738]:
> mail.protection.outlook.com[104.47.75.164]:25: depth=1 verify=1
> subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
>  
> And so on …
> ---------------------- Postfix End -------------------------
>  
>  
> ·        From system remove session-*….scope

I know these are handled in the current release and have been for some
time.  In fact it generates a report on them.
>  
> --------------------- Systemd Begin ------------------------
>  
>  
>  **Unmatched Entries**
>  
>     session-1083006.scope: Succeeded.: 1 Time(s)
>     session-1086439.scope: Succeeded.: 1 Time(s)
>     session-1086441.scope: Succeeded.: 1 Time(s)
>     session-1086442.scope: Succeeded.: 1 Time(s)
>     session-1086443.scope: Succeeded.: 1 Time(s)
>     session-1086444.scope: Succeeded.: 1 Time(s)
>     session-1086445.scope: Succeeded.: 1 Time(s)
>     session-1086446.scope: Succeeded.: 1 Time(s)
>     session-1086447.scope: Succeeded.: 1 Time(s)
> 
> 
> ---------------------- Systemd End -------------------------
>  
>  
> Any help would be highly appreciated 

Regards
Frank
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
> _______________________________________________
> Logwatch-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logwatch-devel

[Logwatch-devel] Removing Unmatched Entries from logwatch

[Khodor B. <kh...@po...>]

Hi ,


I have upgraded my systems from redhat 7 to redhat 8 and after the upgrade the output of logwatch is showing additional log entries that didn't show on redhat 7 ,

how can I remove the following entries from logwatch report:



What is the best way to remove those unmatched entries



*         From Postfix remove the unmatched entries of ssl negotiation since I am using tls in my postfix configuration

--------------------- Postfix Begin ------------------------



  282.378M  Bytes accepted                           296,095,186

    1.085G  Bytes sent via SMTP                      1,165,358,661

    1.384M  Bytes delivered                          1,450,907

========   ==================================================

       70   Accepted                                   100.00%

--------   --------------------------------------------------

       70   Total                                      100.00%

========   ==================================================

        4   Connections                                      4

        4   Disconnections                                   4

       73   Removed from queue                              73

      20   Delivered                                       20

      167   Sent via SMTP                                  167

        3   Bounced (remote)                                 3

       70   Warned                                          70

        3   Notifications sent                               3

       87   TLS connections (client)                        87





**Unmatched Entries**

        1   Mar 29 11:42:57 server1postfix/smtp[3128564]: mail.protection.outlook.com[104.47.75.164]:25: depth=0 verify=1 subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com

        1   Mar 29 14:32:02 server1postfix/smtp[3231872]: mail.protection.outlook.com[104.47.75.228]:25: depth=1 verify=1 subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1

        1   Mar 29 13:17:34 server1postfix/smtp[3185410]: mail.protection.outlook.com[8.31.233.62]:25: depth=0 verify=1 subject=/C=US/ST=Texas/L=Dallas/O=ZixCorp Systems, Inc./CN=*.arsmtp.com

        1   Mar 29 13:34:19 server1postfix/smtp[3195359]: mail.protection.outlook.com[104.47.75.164]:25: depth=1 verify=1 subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1

        1   Mar 29 11:31:42 server1postfix/smtp[3121738]: mail.protection.outlook.com[104.47.75.164]:25: depth=1 verify=1 subject=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1



And so on ...

---------------------- Postfix End -------------------------





*         From system remove session-*....scope



--------------------- Systemd Begin ------------------------





 **Unmatched Entries**



    session-1083006.scope: Succeeded.: 1 Time(s)

    session-1086439.scope: Succeeded.: 1 Time(s)

    session-1086441.scope: Succeeded.: 1 Time(s)

    session-1086442.scope: Succeeded.: 1 Time(s)

    session-1086443.scope: Succeeded.: 1 Time(s)

    session-1086444.scope: Succeeded.: 1 Time(s)

    session-1086445.scope: Succeeded.: 1 Time(s)

    session-1086446.scope: Succeeded.: 1 Time(s)

    session-1086447.scope: Succeeded.: 1 Time(s)



---------------------- Systemd End -------------------------





Any help would be highly appreciated

Re: [Logwatch-devel] Request: Add dropbear support

[Jakob A. <jak...@fa...>]

Hello Jason Pyeron,

I have opened a feature request:
https://sourceforge.net/p/logwatch/feature-requests/18/

If you need more information, feel free to contact me.

Also, thank you @Orion Poplawski for your attempt!

Best regards
Jakob

Am Samstag, dem 19.11.2022 um 07:06 -0500 schrieb Jason Pyeron:
> > -----Original Message-----
> > From: Orion Poplawski
> > Sent: Friday, October 21, 2022 11:02 AM
> > 
> > On 10/18/22 10:26, Jakob Albert wrote:
> > > Hello everyone,
> > > 
> > > as far as I can see it, there is currently no support for
> > > [dropbear], is there?
> 
> Jakob, Please open a feature request. -
> https://sourceforge.net/p/logwatch/feature-requests/new/ 
> 
> > > 
> > > I use dropbear as an SSH Server inside an Alpine Container.
> 
> Do either you have logs you are willing to submit for code coverage
> testing?
> 
> > > The following three lines are generated in `/var/log/messages`
> > > for each connection:
> > > ```
> > > authpriv.info dropbear[1571]: Child connection from
> > > 000.000.000.000:12345
> > > authpriv.notice dropbear[1571]: Pubkey auth succeeded for
> > > 'username' with ssh-ed25519
> > key SHA256:sshKeyHash from 000.000.000.000:12345
> > > authpriv.info dropbear[1571]: Exit (username) from
> > > <000.000.000.000:12345>: Disconnect
> > received
> > > ```
> <snip/>
> > > Jakob
> > 
> > FWIW - this is my locally hacked quick version of the first option
> > (new
> > service).  I suspect it has a lot of cruft in it still.
> > 
> 
> Orion, are you willing to have that patch merged?
> 
> v/r,
> 
> Jason Pyeron
> 

Re: [Logwatch-devel] Request: Add dropbear support

[Jason P. <jp...@pd...>]

> -----Original Message-----
> From: Orion Poplawski
> Sent: Friday, October 21, 2022 11:02 AM
> 
> On 10/18/22 10:26, Jakob Albert wrote:
> > Hello everyone,
> >
> > as far as I can see it, there is currently no support for [dropbear], is there?

Jakob, Please open a feature request. - https://sourceforge.net/p/logwatch/feature-requests/new/ 

> >
> > I use dropbear as an SSH Server inside an Alpine Container.

Do either you have logs you are willing to submit for code coverage testing?

> > The following three lines are generated in `/var/log/messages` for each connection:
> > ```
> > authpriv.info dropbear[1571]: Child connection from 000.000.000.000:12345
> > authpriv.notice dropbear[1571]: Pubkey auth succeeded for 'username' with ssh-ed25519
> key SHA256:sshKeyHash from 000.000.000.000:12345
> > authpriv.info dropbear[1571]: Exit (username) from <000.000.000.000:12345>: Disconnect
> received
> > ```
<snip/>
> > Jakob
> 
> FWIW - this is my locally hacked quick version of the first option (new
> service).  I suspect it has a lot of cruft in it still.
> 

Orion, are you willing to have that patch merged?

v/r,

Jason Pyeron

Re: [Logwatch-devel] request for peer review on feature 9 - XML

[Jason P. <jp...@pd...>]

> -----Original Message-----
> From: Jason Pyeron 
> Sent: Saturday, October 8, 2022 11:27 AM
> 
> I pushed, to the xml-from-master branch, 2 commits to support XML formatting [1].
> 
> This is a redo and rebasing of the XML feature I have been using.

Been over a month, no comments - merging.

v/r,

Jason Pyeron

Re: [Logwatch-devel] Request: Add dropbear support

[Orion P. <or...@nw...>]

On 10/18/22 10:26, Jakob Albert wrote:
> Hello everyone,
> 
> as far as I can see it, there is currently no support for [dropbear], is there?
> 
> I use dropbear as an SSH Server inside an Alpine Container.
> The following three lines are generated in `/var/log/messages` for each connection:
> ```
> authpriv.info dropbear[1571]: Child connection from 000.000.000.000:12345
> authpriv.notice dropbear[1571]: Pubkey auth succeeded for 'username' with ssh-ed25519 key SHA256:sshKeyHash from 000.000.000.000:12345
> authpriv.info dropbear[1571]: Exit (username) from <000.000.000.000:12345>: Disconnect received
> ```
> 
> where:
> - `000.000.000.000` is an IPv4 address
> - `12345` is a port
> - `username` is the user
> - `sshKeyHash` is the hash of the connecting SSH key
> 
> Could you please add support for [dropbear]?
> I see two possibilities for this:
> 
> 1. Adding a completely new service
> 2. Expanding the current SSHD service
> 
> I already tried the second option by:
> - Replacing the `OnlyService` in `default.conf/services/sshd.conf` with dropbear
> - Adding dropbear to `ignore_services` in `default.conf/services/secure.conf`
> - Adding an ignore rule for the disconnect in `scripts/services/sshd`:
> `($ThisLine =~ /Exit \(.*\) from <\d+\.\d+\.\d+\.\d+:\d+>: Disconnect received/)`
> 
> But I do not know how to correctly add a successful login to the output
> (and have currently disabled the normal sshd service in `sshd.conf`).
> The rest does work, but to be honest, I think that it makes much more sense
> to use a completely new service for dropbear - but again,
> I do not know how to correctly write a new service.
> 
> If you need further information, I will be happy to provide it.
> Also, there will probably be a lot more log messages that are possible,
> but those three are the only ones I have encountered so far.
> 
> 
> Thank you very much and best regards
> 
> Jakob

FWIW - this is my locally hacked quick version of the first option (new
service).  I suspect it has a lot of cruft in it still.

-- 
Orion Poplawski
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[Logwatch-devel] Request: Add dropbear support

[Jakob A. <jak...@fa...>]

Hello everyone,

as far as I can see it, there is currently no support for [dropbear], is there?

I use dropbear as an SSH Server inside an Alpine Container.
The following three lines are generated in `/var/log/messages` for each connection:
```
authpriv.info dropbear[1571]: Child connection from 000.000.000.000:12345
authpriv.notice dropbear[1571]: Pubkey auth succeeded for 'username' with ssh-ed25519 key SHA256:sshKeyHash from 000.000.000.000:12345
authpriv.info dropbear[1571]: Exit (username) from <000.000.000.000:12345>: Disconnect received
```

where:
- `000.000.000.000` is an IPv4 address
- `12345` is a port
- `username` is the user
- `sshKeyHash` is the hash of the connecting SSH key

Could you please add support for [dropbear]?
I see two possibilities for this:

1. Adding a completely new service
2. Expanding the current SSHD service

I already tried the second option by:
- Replacing the `OnlyService` in `default.conf/services/sshd.conf` with dropbear
- Adding dropbear to `ignore_services` in `default.conf/services/secure.conf`
- Adding an ignore rule for the disconnect in `scripts/services/sshd`:
`($ThisLine =~ /Exit \(.*\) from <\d+\.\d+\.\d+\.\d+:\d+>: Disconnect received/)`

But I do not know how to correctly add a successful login to the output
(and have currently disabled the normal sshd service in `sshd.conf`).
The rest does work, but to be honest, I think that it makes much more sense
to use a completely new service for dropbear - but again,
I do not know how to correctly write a new service.

If you need further information, I will be happy to provide it.
Also, there will probably be a lot more log messages that are possible,
but those three are the only ones I have encountered so far.


Thank you very much and best regards

Jakob


[dropbear]: https://matt.ucc.asn.au/dropbear/

[Logwatch-devel] request for peer review on feature 9 - XML

[Jason P. <jp...@pd...>]

I pushed, to the xml-from-master branch, 2 commits to support XML formatting [1].

This is a redo and rebasing of the XML feature I have been using.

My goals on this patch, besides supporting XML are:
 * Minimize the introduction of new modules
 * Gracefully handle services that are not (yet) XML aware
 * Make the diff as clean / streamlined as possible

Previously, I had leveraged XML libraries. These libraries force certain structure and constructs on their usage within the code and would likely cause the service maintainers grief and frustration.

I chose syslog-ng as the proof of concept as it was:
 * Last improved in 2016, so it is stable and not going to interrupt a developer
 * Middle of the road for output organization / complexity 

Why XML support? It has nothing to do with HTML - in any way. Every day people like me have hundreds of Logwatch emails in their inbox. These summaries are great, but after a certain quantity they themselves become unreadable. With XML formatting, these reports can very easily be aggregated, filtered, queried, and formatted.

This allows me to answer many questions easily. The top question I want to know what systems have not reported in the last 30 hours. My second most important visualization is on disk space data across all systems. The dashboard view makes life much easier.

Here is the git log -2
commit 4cc503d9c32abddf84972e4c42ba219e17ca1602 (HEAD -> xml-from-master, sf/xml-from-master)
Author: Jason Pyeron <jp...@pd...>
Date:   Sat Oct 8 10:00:38 2022 -0400

    [syslog-ng] add XML support

    TODO: prevent empty XML reports by embargoing output until some real output occurs

    [feature-requests:#9]

commit 377722f81e6adeebb44d01d82c9d16346fe2ed3f
Author: Jason Pyeron <jp...@pd...>
Date:   Sun Oct 2 09:22:27 2022 -0400

    [logwatch.pl] Add basic support for XML, services are free to define their own schema.

    This assumes none of the services are emitting XML when the XML prolog is missing
    and wraps the output in CDATA.

    The prolog, e.g. <?xml version="1.0" encoding="UTF-8" ?> must be provided by a
    service if it is supporting XML. No checks on version are intended at this time,
    but the output is assumed to be utf8, and check may be made against the encoding
    listed in the prolog. If a service reports in XML format, no additional processing
    is made.

    Care is needed with the ignore.conf, as it can match XML tags and result in
    non-compliance with a service's schema document.

    [feature-requests:#9]


1: https://sourceforge.net/p/logwatch/feature-requests/9/

-Jason

[Logwatch-devel] logwatch noise reduction patch

[Noel B. <no...@au...>]

Hi, 

Please find attached multi patch for services


-- 
Kind Regards,
Noel Butler
(b) https://blog.ausics.net


This Email, including attachments, may contain sensitive and/or legally privileged information, therefore does at all times remain confidential and subject to copyright protected under international law. You may not disseminate any part of this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.

[Logwatch-devel] Upcoming release needs testing

[Mike T. <mg...@st...>]

Just a call out to anyone on the list who has some spare time. We pushed a lot changes into git to prepare for use strict as the default going forward. If you can pull master and run some live logs against and raise any issues now that would be super helpful.

-Mike