Activity for Bjorn
-
Bjorn posted a comment on discussion Open Discussion
What do you get when you execute mdadm --misc --detail /dev/md/system_raid10?
-
[mdadm] Check if hash of 'good devices' is undefined or empty.
-
Looks like the script does not find any 'sync' entries on mdadm output. But Logwatch shouldn't crash. Try the attached patch.
-
OpenSSH 9.8 support
-
Thanks for the patch; in repository.
-
[sshd,secure] Added support for OpenSSH 9.8 (sshd-session, port number), per tomop.
-
I don't use either Debian 12 nor journalctl (hopefully someone who does has more insight into the issues you mention), but I thought I could address some of the Logwatch-specific items you mention: * Indeed Logwatch predates journalctl by many years. In 2016 the scripts/shared/journalctl script was added to Logwatch to process logs generated by journalctl. But I don't think the Logwatch journalctl script is in widespread use. * There was a recent discussion that might help. * The LogFile = statement...
-
[logwatch.spec, logwatch.pl] Preparing for release 7.11
-
[journalctl] Added additional comments on usage.
-
Thanks for the insight into the cat piping. After some experimentation, I could reduce it to: in /etc/logwatch/conf/services/sshd.conf Title = "SSHD" LogFile = none *JournalCtl = "--no-pager -u sshd" *RemoveHeaders Note that it does not reference a logfile in /etc/logwatch/conf/logfiles/. When used like this, it does not attempt to concatenate logfiles. If you prefer to reference a configuration in the logfiles directory, then Peter's approach of using LogFile = LogFile = /dev/null in the appropriate...
-
Peter, thanks for your suggested logfile entries. Some comments: On the original report, from James, I think the unit name passed to journalctl should be "sshd" rather than "ssh." The services/sshd.conf file should also have a "Title" variable - Logwatch expects it. On Peter's solution, the transport/facility/priority options for journalctl vary were added over time, and so not all journalctl versions/distributions allow those specific entries. I see that the LogFile = /dev/null does make a difference....
-
[journalctl] Added comments on usage
-
patch: Parse LMTP and UTF8 encoding
-
Thanks for the patch; incorporated in repository.
-
patch: courier pop3d 5.2.6 "LOGIN" line changed and no longer matches
-
Thanks for the patch. Previously incorporated in version 7.9, so just updating the status.
-
[amavis] Add support for parsing LMTP and UTF8 encoding in amavis service,
-
[fail2ban] Added support for IP lookups. Enabled in scripts/services/fail2ban.
-
add missing config variable for emails
-
Update disk space reporting to exclude overlay file systems on Linux by default
-
[sendmail] Sendmail 8.18.1 introduces new collect errors due to bare CR/LF.
-
[dovecot] Adding imap(.*) to the services handled by the dovecot script.
-
[pop3] Handle additional LOGIN info introduced in pop3d 5.2.6, per Matthew M. Ogilvie
-
[clam-update] Updated documentation if it appears freshclam has not run.
-
[sendmail] Fixing bug where email that generates a return receipt occurs
-
[logwatch.spec,logwatch.pl] Added version 7.10 info.
-
There have been no updates to clam-update between versions 7.7 and 7.9 (You can see the file history in git, in Sourceforge.) There are some changes in the repository (to be included in version 7.10). As mentioned in the text you quoted, you can check a number of things: Did freshclam run? Check the freshclam log, usually at /var/log/clamav/freshclam.log. Or maybe /var/log/freshclam.log or /var/log/clam-update. If there are no recent logs, Logwatch has nothing to analyze. If you use a different log...
-
[logwatch.conf,logwatch.pl] Documented default Config variables, including Subject, as suggested by David Fernández.
-
Hi David, Indeed, you can set the Subject string to act as the subject line when the --output mail switch is set. But I believe you can only set it without variables (so, no $Hostname, as proposed) because the strings used do not get passed as variables, and thus not substituted when used within logwatch.pl. Another option is to use the --subject switch. For example, to get the same as the default behavior, you can use --subject "Logwatch for $(hostname) ($(uname -s))" from the calling command line...
-
[iptables] Added iptables.log as valid log file (and iptables.log-* for archive).
-
The issue with custom settings for specific distributions is that it becomes difficult to maintain, and in some cases they are incompatible with the existing or default configurations. If the /var/log/iptables.log file is the default, and the patch to the script works, then it sounds fairly simple. So let us know if those two changes made it work. If further configuration customization for Artix is required, it may be necessary to use the dist.conf feature: when installed, Logwatch creates the directories...
-
I am not familiar with Ufw, but it looks like a front-end to iptables. From what I gather, it includes the string [UFW BLOCK] in the log statements, but otherwise appears to be similar to the native iptables log statements. So try adding the attached patch to the iptables script to account for the [UFW BLOCK] string in the log statements. Also, by default iptables uses the ulogd daemon to log statements, and the default location is /var/log/ulogd. You can add your filename, as an entry of LogFile...
-
(Or in the conf/logwatch.conf file.)
-
Do you have the string *JournalCtl (perhaps with different upper/lower letter case) in any of your conf/logfile files?
-
So I think there are several items at play here: * The $ignore_outdatedvariable was intended to only suppress the "outdated version" warnings. That is, the ClamAV version itself, not the database (freshclam) version. * The reason why your warnings were previously suppressed was because of a different bug, which is what the commit intended to solve. With the previous code, if there are any entries that falls out of the date 'range' after the desired date range is processed, the hashes %Errors and...
-
[clam-update] Fixed bug where WARNINGS and ERRORS were dropped
-
Dovecot failed logins broke in v7.9.
-
Thanks for the patch.
-
[fail2ban] Remove superfluous ] from BAN-time increases
-
[dovecot] Fix to log connections closed with auth failure, by Reio Remma.
-
Thanks for the patch, but it seems to end prematurely. Can you confirm and re-post the correct one?
-
[sendmail] Better matching of Unrecognized Commands in the OtherList hash.
-
Moved to Feature Request. Although we don't have a sample of the desired log statements, I do believe that it is due to the logformat parser (see variables $logformat, $parse_string and $parse_field, among others) not handling all possible format string types (prefixed by '%'). That is further complicated by the ability to specify variables (referred to as VARNAME in the mod_log_config documentation), whose contents can be any arbitrary format, and thus necessitating a very complex parser.
-
Ticket moved from /p/logwatch/bugs/108/
-
Moved to Feature Request. As previously mentioned, the code is not set up to handle custom log formats.
-
Ticket moved from /p/logwatch/support-requests/5/
-
To Noel: I think some of the mismatches is because of the custom login_log_format_elements, as you indicated. If you or someone feels like writing a parser of custom log fields, there is an example in the http script, using the $logformat, $parse_string, and $parse_field variables. The subsequent reply with the postfix errors from another user have been deleted, as the question was re-posted to the discussion email.
-
I understand the addition of the (Increase\s)? pattern match, but why the if ( $Increase ) {$Service .= " increase"} code? The concern is that the service name is used in several other hashes to keep track of all bans/unbans/rebans/flushes. If we really wanted to keep track of Increase Bans, perhaps we can use the ReBan $Action. That is, replace the one occurrence of Restore Ban by Restore Ban|Increase Ban as shown in the attached patch. The 'Increase' is a type of re-banning. (There is no Increase...
-
Sys-CPU is not available on CPAN
-
postfix detail level working incorrect
-
journald integration issues
-
fail2ban report missing in summary
-
postfix script doesn't recognize SPF fail - not authorized
-
Patch incorporated in 7.9, allowing enhanced codes for those log statements.
-
fail2ban report missing in summary
-
It does work for me, on a different Linux release, so I can't comment on Debian 12. A couple of things to check: I assume the "Detail = 2" you set is in /etc/logwatch/conf/services/fail2ban.conf? loglevel and logtarget are properly declared in fail2ban (such as in /etc/fail2ban/fail2ban.conf or .local)? Logwatch assumes the default log file /var/log/fail2ban.log unless declared differently in /etc/logwatch/conf/logfiles/fail2ban.conf. And finally, check that the fail2ban.log file is logging ban/unban...
-
[dovecot] Disconnects may occur because of inactivity, but other reason still
-
[postfix] Removed extra parenthesis.
-
[zz-sys] Better printing and syntax.
-
[zz-sys] No longer using obsolete Sys::CPU and Sys::MemInfo Perl modules.
-
[postfix] Added detection of enhanced SMTP status for SPF Fail.
-
Merge branch 'master' of ssh://git.code.sf.net/p/logwatch/git
-
[dovecot] Added logging of failed authentications, by Reio Remma.
-
Thanks for posting the bug. There doesn't appear to be a universal way of obtaining this CPU/Memory information across different Linux/Unix platforms. Perhaps that's why the referenced Perl modules were discontinued. I have created a new version, which is attached. It queries the /proc filesystem, which I believe to be common across all Linux (and many Unix, but not all) variants. Let me know if this script helps. Since the current zz-sys script does not appear to work for any recent Perl release,...
-
Ticket moved from /p/logwatch/patches/80/
-
Got it - I thought those error messages were as an originating email sender, not as a receiving email server. The postfix script does process some SPF log statements, but apparently not the ones you posted. Looking through the postfix script code, it appears to not expect the "5.7.23" enhance code. Is that a customization? I don't use Postfix, so don't know what the standard behavior is, nor can I test it. But it seems that the attached patch might fix it. But let us know how the "5.7.23" got added,....
-
RPM does not install on Ubuntu 22.04
-
Out of memory events not in output
-
Thanks for the files. I am not familiar with psad, but I do have some comments: I assume you're willing to post this under the MIT/X-Consortium license. The relevant header can be found in the script files. For example, you can execute head -25 scripts/services/named to obtain a standard version of it. Change the year and copyright holder, and prepend it to the scripts/services/psad script. Is the file location of $psadstatus hard-coded in the psad source? It is preferable to make it a configurable...
-
Add output for Dovecot failed logins.
-
Thanks for the patch.
-
I believe the current dropbear script (in Logwatch 7.8-3) handles the dropbear SSH statements you posted.
-
Patch to add a plugin for snort
-
Thanks for submitting the files.
-
[snort] Added files for snort (network intrusion detection), by Darold Gilles.
-
HTML formatting doesn't support email clients with dark backgrounds
-
This is a very old bug. The link listed has also not worked for a very long time. And this appears to be a feature request, not a bug. In addition, I feel that Logwatch is not the best place to remedy this. It seems that the best place to modify this is in the software that invokes Logwatch to display it as they prefer. The alternative is to write Javascript that will check the background color, and choose the appropriate foreground/background colors for that environment. This Javascript could then...
-
This does not appear to be a Logwatch issue. Rather, it is signalling a configuration error that needs to be fixed in the email server. My concern about processing it in Logwatch is that it would essentially bury this error.
-
fail2ban report missing in summary
-
logwatch-7.8-2.noarch is intended for a different operating system.
-
Fixed in 7.8-3.
-
What I think you are asking for is a global variable to use journalctl, rather than specifying it on each service. But there are two difficulties: First, to address the solution of searching for 'none' in the FileList: some services that use LogFile = none do so because they really don't have any log files, not because their output can be obtained through journalctl (such as all the zz-* services). Second, the servicename used by journalctl is not necessarily the same one used by Logwatch. And Logwatch...
-
Postfix seems to use a different scheme for the detail levels. Each section uses its own detail level. See the [default.]conf/services/postfix.conf file. It is described in more detail under the "Level Limiters" heading.
-
Thanks for the patch. Incorporated with some modifications.
-
Email - RFC 5322 compliant, duplicate "To" headers
-
[logwatch.pl] Corrected delineation of "To:" headers, by submitter Mr. Lazy.
-
[sendmail] Better handling of "Unmatched entries" and TLS errors.
-
Can you give the new https://sourceforge.net/projects/logwatch/files/logwatch-7.8/logwatch-7.8-3.noarch.rpm/download a try?
-
Logwatch 7.8-3 update for linux noarch version
-
Ignore new log entries for postfix-3.7.x
-
Thanks for the patch.
-
Typo in extreme-networks for Logwatch 7.7
-
Thanks for submitting the patch.
-
Typo in OOM regex
-
Thanks for submitting the bug.
-
[kernel] Correct filter on killed process, by Artur Jaroschek
-
[extreme-networks] Fixed incorrect syntax on 'use' statement, by Bryce Harrington
-
ReadConfigFile damages case-sensitive values, specifically Pre_Ignore
-
Interesting question. Here are some considerations, and my thoughts on it: I believe that currently, all of the logwatch files are distributed through the logwatch package, and not through the service being monitored (pnp4nagios, in your case), which I'll call the service package. But there are several drawbacks to this arrangement: Chief among them is that the end users don't have the same level of understanding of the service package as the developers. Open-source service packages makes it possible,...
-
[postfix] Additional filtering, by Vladimir Elisseev.
1 >