Bug 163487 - syslog.conf filtering syntax broken in 9.0-RC3 (was working in 8.2)
Summary: syslog.conf filtering syntax broken in 9.0-RC3 (was working in 8.2)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Mark Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-20 19:10 UTC by tom
Modified: 2018-05-29 18:49 UTC (History)
0 users

See Also:


Attachments
syslogd_domain_trimming.patch.txt (1.29 KB, text/plain; charset=us-ascii)
2012-06-07 05:33 UTC, Mark Johnston
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description tom 2011-12-20 19:10:08 UTC
	When specifying multiple hostnames on a filter line in /etc/syslog.conf, syslogd seems to not correctly log syslog messages sent from the listed hosts (or at least the first-listed). As an example, here is a snippet of the syslog.conf file as configured (and working) on FreeBSD 8.2 i386.

=== syslog.conf snip ===

+shawshank-1.ply.claimlynx.com,shawshank-2.ply.claimlynx.com
!wan_checker
*.*                                             /var/log/wan_checker.log
+*
!*

=== end snip ===

I recently rebuilt this host, using 9.0-RC3 amd64 (fwiw, PC-BSD install media). I restored the syslog.conf file directly from backups, but with 9.0, messages that correspond to this combination of host/prog filters are never logged to the file. When running syslogd manually with debugging, I get the following output. It appears that the message is received from the remote host, but not written to the log file.

=== debug output ===

cvthname(10.0.0.252)
validate: dgram from IP 10.0.0.252, port 514, name shawshank-1.ply.claimlynx.com;
accepted in rule 0.
logmsg: pri 206, flags 0, from shawshank-1, msg Dec 20 12:57:38 wan_checker[35617]: WAN checking loop wakes up at Tue Dec 20 12:57:38 2011

=== end debug ====

Fix: 

By rewriting syslog.conf to avoid multiple host filters, syslogd seems to content to do the right thing. The configuration snippet from the Description has been rewritten like so.

=== syslog.conf snip ===

!wan_checker
+shawshank-2.ply.claimlynx.com
*.*                                             /var/log/wan_checker.log
+*
+shawshank-1.ply.claimlynx.com
*.*                                             /var/log/wan_checker.log
+*
!*

=== end snip ===

This results in a successful write to the log file

=== debug output ===

cvthname(10.0.0.252)
validate: dgram from IP 10.0.0.252, port 514, name shawshank-1.ply.claimlynx.com;
accepted in rule 0.
logmsg: pri 206, flags 0, from shawshank-1, msg Dec 20 13:04:20 wan_checker[35617]: WAN checking loop wakes up at Tue Dec 20 13:04:20 2011
Logging to FILE /var/log/wan_checker.log

=== end debug ===
How-To-Repeat: 
Add multiple hostnames to a filter, per the syntax in syslog.conf(5).
Comment 1 Mark Johnston 2012-06-02 05:55:38 UTC
Hm, it's not really clear to me how this could have worked on FreeBSD
8.2 - the problem's been around for a while, based on a quick look
through the history of syslogd.c.

There's a bug in the way that domain info gets trimmed off the host
filters. When syslogd sees a line like

+shawshank-1.ply.claimlynx.com

it trims it to "shawshank-1" and uses that string to match incoming
messages - you can see in the debug output that the incoming message
comes with a hostname of "shawshank-1" rather than the FQDN.

syslogd uses trimdomain(3) to get a hostname out of the host filter, and
in your case it passes

"shawshank-1.ply.claimlynx.com,shawshank-2.ply.claimlynx.com"

to trimdomain(3), which has no effect. Then when the message from
"shawshank-1" comes it, it doesn't get matched against either of the
FQDNs and thus isn't logged.

You can try to verify this by changing your filter to

+shawshank-1,shawshank-2

I haven't actually tried to reproduce this - it's based on a reading of
the syslogd code. I'll post a patch soon.

Thanks,
-Mark
Comment 2 Mark Johnston 2012-06-07 05:33:16 UTC
I've attached a small patch which fixes the issue described above.
Basically, rather than calling trimdomain(3) on the entire host filter
string (which won't do anything if the filter contains multiple hosts),
this change has syslogd call trimdomain(3) on each host and then copy it
to f->f_host.

Would you be able to test this?

Thanks,
-Mark
Comment 3 tom 2012-06-07 14:04:07 UTC
Mark,

I will get this tested, may not be until next week though.

Thanks!

On Wed, Jun 6, 2012 at 11:33 PM, Mark Johnston <markjdb@gmail.com> wrote:

> I've attached a small patch which fixes the issue described above.
> Basically, rather than calling trimdomain(3) on the entire host filter
> string (which won't do anything if the filter contains multiple hosts),
> this change has syslogd call trimdomain(3) on each host and then copy it
> to f->f_host.
>
> Would you be able to test this?
>
> Thanks,
> -Mark
>



-- 
Thomas Johnson
ClaimLynx, Inc.
952-593-5969 x2302
Comment 4 Mark Johnston 2012-09-09 00:28:11 UTC
Didn't notice that this reply didn't get added to the PR.

----- Forwarded message from Thomas Johnson <tom@claimlynx.com> -----

Date: Thu, 21 Jun 2012 09:52:43 -0500
From: Thomas Johnson <tom@claimlynx.com>
To: Mark Johnston <markjdb@gmail.com>
Subject: Re: bin/163487: syslog.conf filtering syntax broken in 9.0-RC3 (was working in 8.2)

Mark, tested your patch and it appears to resolve the problem. Sorry for
the delay, it's been a busy couple of weeks, culminating in a Monday
morning crash of the host I wanted to test the fix on. Thanks for looking
into this!

-Tom

On Wed, Jun 6, 2012 at 11:33 PM, Mark Johnston <markjdb@gmail.com> wrote:

> I've attached a small patch which fixes the issue described above.
> Basically, rather than calling trimdomain(3) on the entire host filter
> string (which won't do anything if the filter contains multiple hosts),
> this change has syslogd call trimdomain(3) on each host and then copy it
> to f->f_host.
>
> Would you be able to test this?
>
> Thanks,
> -Mark
>



-- 
Thomas Johnson
ClaimLynx, Inc.
952-593-5969 x2302

----- End forwarded message -----
Comment 5 Mark Johnston freebsd_committer freebsd_triage 2012-12-20 01:56:35 UTC
Responsible Changed
From-To: freebsd-bugs->markj

I'll take it.
Comment 6 Mark Johnston freebsd_committer freebsd_triage 2012-12-20 01:58:53 UTC
State Changed
From-To: open->analyzed

The patch I posted here some time ago isn't very good, but I understand 
the problem.
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:41:25 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 8 tom 2018-05-29 18:49:23 UTC
I can't speak to the continued existence of any bug, but I no longer have any technical need for a fix.