El mié, 21 may 2025 a las 0:01, J Harri (<harr...@yahoo.com>) escribió: > > I did not write the config, but I'm the lucky maintainer. I thought those > lines insured only local1.notice,info,debug would be sent to the remote host, > and that the template insured the expected format for the log line entry.
Actually what they do is sent those messages (like wallmsg) to the user Server3Template. This however, is in almost all cases not the intended behaviour. The old version didn't care, the new version now emits the warning messages so that you know what actually happens. In those rare cases where it was really intended, rsyslog recommends to use the explicit syntax, so it can be sure it is your intent. > > I commented them out, and there was no difference in logging. Yup - I guess you have no such user ;-) > Then I replaced: > > *.* @@10.16.130.0:514 > > with: > > local1.=notice @@10.16.130.0:514 > local1.=info @@10.16.130.0:514 > local1.=debug @@10.16.130.0:514 > > And this results in the desired behavior. > But this is (as far as I have reviewed) not what the old config did. > I tried removing the template stuff in the new config for AL2023 local, but > it made no difference. > > So since the old config works, I suppose this is OK moving forward from AL1 > to AL2023. I would like to know why the reworked config for AL2023 local did > not work, since for new configs I'd like to use the latest script syntax. If I read the first post correct (it is a bit hard to read for me TBH), you initially send all messages to the old config *.* @@10.16.130.0:514 whereas in the new config you only send faciliy local1 message, not those of the other 23 facilities. HTH Rainer > > On Tuesday, May 20, 2025 at 03:56:09 PM CDT, Rainer Gerhards > <rgerha...@hq.adiscon.com> wrote: > > > The reason seems to be that the old config has errors, which better error > having in the new version detects. > > I have no idea what the real intent of these 6 lines is: > > local1.=notice Server3Template > > local1.=info Server3Template > > local1.=debug Server3Template > > Can you explain what you think they do? > > Rainer > Sent from phone, thus brief. > > J Harri via rsyslog <rsyslog@lists.adiscon.com> schrieb am Di., 20. Mai 2025, > 22:31: > > If I use the old config on the AL2023 local host, logging to the AL2023 > remote host works as expected. When the old config is used, starting rsyslog > results in output about an action and error, the first of which is: > May 20 20:15:47 ip-10-16-1-119.us-west-2.compute.internal rsyslogd[31120]: > action 'Server3Template' treated as ':omusrmsg:Server3Template' - please use > ':omusrmsg:Server3Template' syntax instead, 'Server3Template' will not be > supported in the future [v8.2204.0-3.amzn2023.0.4 try > https://www.rsyslog.com/e/2184 ] > May 20 20:15:47 ip-10-16-1-119.us-west-2.compute.internal rsyslogd[31120]: > error during parsing file /etc/rsyslog.d/99-forward-to-remote.conf, on or > before line 3: warnings occurred in file > '/etc/rsyslog.d/99-forward-to-remote.conf' around line 3 > [v8.2204.0-3.amzn2023.0.4 try https://www.rsyslog.com/e/2207 ] > rsyslogd -N1 produces the same errors, but remote logging still works as > expected. If the suggested change is made to the config, then the error > output goes away. rsyslogd -N1 produced no errors for the other configs (AL1 > local and AL2023 remote). > Shouldn't the new syntax work for remote logging via rsyslog v8? Is this a > bug? Should an issue be opened in github for the rsyslog repro? I have a > script that will spin-up a test bed to reproduce, which I could include in > the github issue ticket. > On Thursday, May 15, 2025 at 03:14:45 AM CDT, David Lang <da...@lang.hm> > wrote: > > you should be able to use the old configs unchanged. We work really hard to > maintain backwards compatibility for just this reason > > it's discouraged to use the old syntax for new configs (especially for things > like queues where you have several lines of $foo before the action that they > affect) > > I don't spot anything obviously wrong with your new version, but do rsyslog > -N1 > to get a syntax check. > > I suspect that the new OS builds have different firewall rules in place that > are > blocking 514 TCP > > David Lang > > P.S. with the new filter syntax, you can have multiple statements inside the > {} > so instead of a filter followed by & stop (which is implementing the prior > filter), just add the stop commaand inside the {} and it makes it easier for > people to read > > On Wed, 14 May 2025, J Harri via rsyslog wrote: > > > Date: Wed, 14 May 2025 19:33:16 +0000 (UTC) > > From: J Harri via rsyslog <rsyslog@lists.adiscon.com> > > To: "rsyslog@lists.adiscon.com" <rsyslog@lists.adiscon.com> > > Cc: J Harri <harr...@yahoo.com> > > Subject: [rsyslog] Cannot Migrate From rsyslog v5 on AL1 to rsyslog v8 on > > AL2023 > > > > > > We are migrating AWS AL1 servers (EOL) to AWS AL2023, with both instance > > types using rsyslog. All servers use remote logging, except for the remote > > server receiving the logs. Migration of the servers generating the logs > > will take some time, so some servers will remain on AL1 for a bit, while > > others are ready for AL2023 migration. Both the AL1 and AL2023 servers need > > to be configured for remote logging during the migration period. > > > > > > The AL1 servers are running rsyslog v5: > > > > > > $ rsyslogd -v > > > > rsyslogd 5.8.10, compiled with: > > > > FEATURE_REGEXP: Yes > > > > FEATURE_LARGEFILE: No > > > > GSSAPI Kerberos 5 support: Yes > > > > FEATURE_DEBUG (debug build, slow code): No > > > > 32bit Atomic operations supported: Yes > > > > 64bit Atomic operations supported: Yes > > > > Runtime Instrumentation (slow code): No > > > > > > The AL2023 servers are running rsyslog v8: > > > > > > $ rsyslogd -v > > > > rsyslogd 8.2204.0-3.amzn2023.0.4 (aka 2022.04) compiled with: > > > > PLATFORM: x86_64-amazon-linux-gnu > > > > PLATFORM (lsb_release -d): > > > > FEATURE_REGEXP: Yes > > > > GSSAPI Kerberos 5 support: No > > > > FEATURE_DEBUG (debug build, slow code): No > > > > 32bit Atomic operations supported: Yes > > > > 64bit Atomic operations supported: Yes > > > > memory allocator: system default > > > > Runtime Instrumentation (slow code): No > > > > uuid support: Yes > > > > systemd support: Yes > > > > Config file: /etc/rsyslog.conf > > > > PID file: /var/run/rsyslogd.pid > > > > Number of Bits in RainerScript integers: 64 > > > > > > The remote host for logging has been migrated to AL2023, and logging from > > AL1 hosts works as expected. The drop-in rsyslog conf file for the remote > > host worked unchanged when migrated from AL1 to AL2023, and contains rules: > > > > > > if re_match($programname, 's[0-9]+_misc') and $syslogseverity == 5 and $msg > > startswith ' NBA' \ > > > > then /var/log/remotelog/nba/server > > > > & stop > > > > if re_match($programname, 's[0-9]+_misc') and $syslogseverity == 6 and $msg > > startswith ' NBA' \ > > > > then /var/log/remotelog/nba/connections > > > > & stop > > > > > > The drop-in rsyslog config file on the local AL1 host is: > > > > > > local1.none /var/log/messages > > > > $template Server3Template,"%timestamp% %hostname% %syslogtag% %msg%\n" > > > > local1.=notice Server3Template > > > > local1.=info Server3Template > > > > local1.=debug Server3Template > > > > $WorkDirectory /var/lib/rsyslog # where to place spool files > > > > $ActionQueueFileName fwdRule1 # unique name prefix for spool files > > > > $ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) > > > > $ActionQueueSaveOnShutdown on # save messages to disk on shutdown > > > > $ActionQueueType LinkedList # run asynchronously > > > > $ActionResumeRetryCount -1 # infinite retries if host is down > > > > *.* @@10.16.130.0:514 > > > > > > The above configuration was tested with the following commands on the local > > AL1 host: > > > > > > $ logger -t s4_misc -p local1.notice "NBA-US from AL1 notice" > > > > $ logger -t s4_misc -p local1.info "NBA-US from AL1 info" > > > > > > Which results in a single entry in /var/log/remotelog/nba/server on the > > remote host for local1.notice: > > > > > > May 13 19:36:50 ip-172-16-3-0 s4_misc: NBA-US from AL1 notice > > > > > > And also results in a single entry in /var/log/remotelog/nba/connections on > > the remote host for local1.info: > > > > > > May 13 19:38:54 ip-172-16-3-0 s4_misc: NBA-US from AL1 info > > > > > > The migrated drop-in file on the local AL2023 host is: > > > > > > $template Server4Template,"%timestamp% %hostname% %syslogtag% %msg%\n" > > > > local1.* action(type="omfwd" > > > > queue.filename="fwdRule1" # unique name prefix for spool files > > > > queue.maxdiskspace="1g" # 1gb space limit (use as much as possible) > > > > queue.saveonshutdown="on" # save messages to disk on shutdown > > > > queue.type="LinkedList" # run asynchronously > > > > action.resumeRetryCount="-1" # infinite retries if host is down > > > > template="Server4Template" > > > > target="10.16.130.0" > > > > port="514" > > > > protocol="tcp" > > > > ) > > > > > > The above configuration was tested with the following commands on the local > > AL2023 host: > > > > > > $ logger -t s4_misc -p local1.notice "NBA-US from AL2023 notice" > > > > $ logger -t s4_misc -p local1.info "NBA-US from AL2023 info" > > > > > > Which results in a both entries in /var/log/remotelog/nba/server on the > > remote host for local1.notice and for local1.info: > > > > > > May 13 19:59:48 ip-10-24-7-0 s4_misc[54120]: NBA-US from AL2023 notice > > > > May 13 20:04:02 ip-10-24-7-0 s4_misc[54993]: NBA-US from AL2023 info > > > > > > and the local1.info entry does not get logged in > > /var/log/remotelog/nba/connections for the AL2023 local host, unlike the > > logging from AL1. We want the local1.info entries for the AL2023 hosts to > > go to the same file as the AL1 hosts. > > > > > > We tried changing the filter rules on the remote host to use the new syntax: > > > > > > if re_match($programname, 's[0-9]+_misc') and $syslogseverity == 5 and $msg > > startswith ' NBA' then { > > > > action(type="omfile" file="/var/log/remotelog/nba/server") > > > > } > > > > & stop > > > > if re_match($programname, 's[0-9]+_misc') and $syslogseverity == 6 and $msg > > startswith ' NBA' the { > > > > action(type="omfile" file="/var/log/remotelog/nba/connections") > > > > } > > > > & stop > > > > > > The above change made no difference to the remote log output for the local > > AL2023 host. After making the above change, no remote log output from the > > local AL1 host was saved at all on the remote host (i.e. AL1 remote logging > > stopped working). > > > > > > How can we configure the servers so remote logging for the AL2023 servers > > works like the AL1 servers, where local1.notice and local1.info are saved > > in different files on the remote AL2023 host? > > > > > > _______________________________________________ > > rsyslog mailing list > > https://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com/professional-services/ > > What's up with rsyslog? Follow https://twitter.com/rgerhards > > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > > LIKE THAT. > _______________________________________________ > rsyslog mailing list > https://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
