Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Jun 2018 21:11:06 +0200
From:      Ed Schouten <ed@nuxi.nl>
To:        Michael Grimm <trashcan@ellael.org>
Cc:        FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,  Mailing List FreeBSD Ports <freebsd-ports@freebsd.org>, "ed@FreeBSD.org" <ed@freebsd.org>, theis@gmx.at,  Gleb Smirnoff <glebius@freebsd.org>
Subject:   Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)
Message-ID:  <CABh_MKkdObTmbNXnKrudyHjkd8s3aukUUC=Vee%2BRShJepWpwNg@mail.gmail.com>
In-Reply-To: <697FFEFE-6AFB-45CE-ADCD-4DB10286E68B@ellael.org>
References:  <590A1B87-464D-455C-A03D-9908EB7AF286@ellael.org> <20180622155922.GA61217@plan-b.pwste.edu.pl> <697FFEFE-6AFB-45CE-ADCD-4DB10286E68B@ellael.org>

next in thread | previous in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
Hi Marek,

[ +glebius ]

Thanks for reporting this!

2018-06-22 18:54 GMT+02:00 Michael Grimm <trashcan@ellael.org>:
>> Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
>> %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
>> changed state to down
>
> Ah, yes! Haven't thought about running syslogd in debugging mode:
>
>         Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: INFO […]

This is interesting. As fail2ban uses Python's logging framework, I
managed to reproduce this with the following script:

#!/usr/bin/env python3
import logging.handlers
logging.basicConfig(handlers=[
    logging.handlers.SysLogHandler(
        '/var/run/log', facility=logging.handlers.SysLogHandler.LOG_LOCAL7)
])
logging.warning('Hi')

This will write the following message to syslogd:

sendto(3,"<188>WARNING:root:Hi\0",21,0,NULL,0)   = 21 (0x15)

This message gets rejected by syslogd, due to the change made in
r326573, which later got adjusted by me and subsequently MFCed:

https://svnweb.freebsd.org/base?view=revision&revision=326573

Gleb, what are your thoughts on the attached patch? It alters syslogd
to let the 'legacy' RFC 3164 parser also accept messages without a
timestamp. The time on the syslogd server will be used instead.

Michael, Marek, could you please give this patch a try? Thanks!

-- 
Ed Schouten <ed@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands

[-- Attachment #2 --]
Index: usr.sbin/syslogd/syslogd.c
===================================================================
--- usr.sbin/syslogd/syslogd.c	(revision 335314)
+++ usr.sbin/syslogd/syslogd.c	(working copy)
@@ -1172,45 +1172,43 @@
 	size_t i, msglen;
 	char line[MAXLINE + 1];
 
-	/* Parse the timestamp provided by the remote side. */
-	if (strptime(msg, RFC3164_DATEFMT, &tm_parsed) !=
-	    msg + RFC3164_DATELEN || msg[RFC3164_DATELEN] != ' ') {
-		dprintf("Failed to parse TIMESTAMP from %s: %s\n", from, msg);
-		return;
-	}
-	msg += RFC3164_DATELEN + 1;
+	/* Parse the timestamp provided by the remote side, if any. */
+	timestamp = NULL;
+	if (strptime(msg, RFC3164_DATEFMT, &tm_parsed) ==
+	    msg + RFC3164_DATELEN && msg[RFC3164_DATELEN] == ' ') {
+		msg += RFC3164_DATELEN + 1;
+		if (!RemoteAddDate) {
+			struct tm tm_now;
+			time_t t_now;
+			int year;
 
-	if (!RemoteAddDate) {
-		struct tm tm_now;
-		time_t t_now;
-		int year;
-
-		/*
-		 * As the timestamp does not contain the year number,
-		 * daylight saving time information, nor a time zone,
-		 * attempt to infer it. Due to clock skews, the
-		 * timestamp may even be part of the next year. Use the
-		 * last year for which the timestamp is at most one week
-		 * in the future.
-		 *
-		 * This loop can only run for at most three iterations
-		 * before terminating.
-		 */
-		t_now = time(NULL);
-		localtime_r(&t_now, &tm_now);
-		for (year = tm_now.tm_year + 1;; --year) {
-			assert(year >= tm_now.tm_year - 1);
-			timestamp_remote.tm = tm_parsed;
-			timestamp_remote.tm.tm_year = year;
-			timestamp_remote.tm.tm_isdst = -1;
-			timestamp_remote.usec = 0;
-			if (mktime(&timestamp_remote.tm) <
-			    t_now + 7 * 24 * 60 * 60)
-				break;
+			/*
+			 * As the timestamp does not contain the year
+			 * number, daylight saving time information, nor
+			 * a time zone, attempt to infer it. Due to
+			 * clock skews, the timestamp may even be part
+			 * of the next year. Use the last year for which
+			 * the timestamp is at most one week in the
+			 * future.
+			 *
+			 * This loop can only run for at most three
+			 * iterations before terminating.
+			 */
+			t_now = time(NULL);
+			localtime_r(&t_now, &tm_now);
+			for (year = tm_now.tm_year + 1;; --year) {
+				assert(year >= tm_now.tm_year - 1);
+				timestamp_remote.tm = tm_parsed;
+				timestamp_remote.tm.tm_year = year;
+				timestamp_remote.tm.tm_isdst = -1;
+				timestamp_remote.usec = 0;
+				if (mktime(&timestamp_remote.tm) <
+				    t_now + 7 * 24 * 60 * 60)
+					break;
+			}
+			timestamp = &timestamp_remote;
 		}
-		timestamp = &timestamp_remote;
-	} else
-		timestamp = NULL;
+	}
 
 	/*
 	 * A single space character MUST also follow the HOSTNAME field.

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABh_MKkdObTmbNXnKrudyHjkd8s3aukUUC=Vee%2BRShJepWpwNg>