Re: [Suspected Junk Mail] Re: bin/58558: syslog.conf(5) man page example does not work.

[xover2391%hush.com@localhost]

On 8/7/2024 at 7:10 AM, "RVP" <rvp%SDF.ORG@localhost> wrote:
>
>The following reply was made to PR bin/58558; it has been noted by 
>GNATS.
>
>From: RVP <rvp%SDF.ORG@localhost>
>To: gnats-bugs%netbsd.org@localhost
>Cc: 
>Subject: Re: bin/58558: syslog.conf(5) man page example does not 
>work.
>Date: Wed, 7 Aug 2024 07:08:09 +0000 (UTC)
>
> On Wed, 7 Aug 2024, xover2391%hush.com@localhost wrote:
> 
> > # Save non-local log messages from all programs to a separate 
>file.
> > !*
> > -@
> > *.*                                     /var/log/foreign
> >
> 
> There is PR #47529 which _looks_ almost like this PR, except, 
>close reading
> of syslog.conf(5) suggests that the duplicate copies should be 
>expected with
> the config. file you've shown. Ie. by default, messages will 
>"cascade" to
> multiple files unless stopped by other rules or using the `-U' 
>flag to syslogd.
> 
> Here's a syslog.conf which does work for separating outputs from 
>other hosts
> to a different file (works around PR #47529 too):
> 
> ```
> #	$NetBSD: syslog.conf,v 1.9 2004/07/23 03:45:42 mycroft Exp $
> 
> +@
> *.err;kern.*;auth.notice;authpriv.none;mail.crit	/dev/console
> *.info;auth,authpriv,cron,ftp,kern,lpr,mail.none	/var/log/messages
> kern.debug						/var/log/messages
> 
> # The authpriv log file should be restricted access; these
> # messages shouldn't go to terminals or publically-readable
> # files.
> auth,authpriv.info					/var/log/authlog
> 
> cron.info						/var/log/cron
> ftp.info						/var/log/xferlog
> lpr.info						/var/log/lpd-errs
> mail.info						/var/log/maillog
> #uucp.info						/var/spool/uucp/ERRORS
> 
> *.emerg							*
> #*.notice						root
> 
> !*
> +192.168.68.171,qemu
> *.*							/var/log/host1.log
> ```
> 
> The only additions from the default syslog.conf file are the:
> 
> +@
> 
> and:
> 
> !*
> +192.168.68.171,qemu
> *.*							/var/log/host1.log
> 
> The `+@' hostname-spec causes the rules following it to be 
>applied _only_ to
> the local host. This duplicates the functionality of the default 
>config. file.
> 
> The other block then sends all output from the named host(s) to a 
>separate
> file.
> 
> But, for this to work (I've just tested this), the remote host 
>has to send
> well formed syslog data to the syslogd program on NetBSD. In my 
>test the remote
> host ("qemu") was also NetBSD and the messages in 
>`/var/log/host1.log' look
> like this:
> 
> ```
> <auth.info>Aug  7 06:29:02 qemu sshd[327]: Server listening on :: 
>port 22.
> <auth.info>Aug  7 06:29:02 qemu sshd[327]: Server listening on 
>0.0.0.0 port 22.
> <user.debug>Aug  7 06:29:02 qemu sshd: bl_init: connect failed 
>for `/var/run/blacklistd.sock' (No such file or directory)
> <mail.info>Aug  7 06:29:02 qemu postfix/postfix-script[466]: 
>starting the Postfix mail system
> <mail.info>Aug  7 06:29:02 qemu postfix/master[479]: daemon 
>started -- version 3.8.4, configuration /etc/postfix
> <auth.notice>Aug  7 06:29:36 qemu login: ROOT LOGIN (root) on tty 
>constty
> <cron.info>Aug  7 06:30:43 qemu cron[549]: (root) CMD START 
>(/usr/libexec/atrun)
> <cron.info>Aug  7 06:30:43 qemu cron[537]: (root) CMD FINISH 
>(/usr/libexec/atrun)
> ```
> 
> The message you posted on netbsd-users@ looks malformed:
> 
> ```
> <user.info>Aug  7 10:40:08 Aug -:  7 10:40:08 192.168.1.200-1 
>USER_MGR[44365908]: user_mgr_util.c(1588) 5098 %% HTTP Session 30 
>started for user admin connected from 192.168.1.210
> ```
> 
> Don't know if it's a bug in syslogd which's responsible or it's 
>the sender who's
> responsible.
> 
> Can you do a tcpdump like this and show the output?
> 
> ```
> root# tcpdump -Alnt -i <IF> host 192.168.1.200 and udp dst port 
>syslog
> ```
> 
> -RVP

I appreciate the pointer to PR# 47529. I did perform a Query PR prior to doing a Send PR, but not knowing what to search for, all I did was to put a single keyword "syslogd" in the relevant search field. Very few of the results returned were directly related to syslogd, and I didn't inspect each and every one of them. I mainly looked for the dates to have been within the last two years or so.

I'm happy to defer to your knowledge on whether a syslog message is malformed, and I'd put money on it being the remote device (the HP switch, which is running some kind of embedded Linux from HP, of course) that's responsible. Yes, I can do a tcpdump like what you've shown, when I'm on-site next week. Thanks for the suggestion.