github issues is a vital option. Mailing list is another. Both work. Rainer
El mié, 21 may 2025 a las 18:22, J Harri (<[email protected]>) escribió: > > Correct, the config behavior changed to only send a subset of local1 to the > remote host. The change was supposed to be the intended behavior all along. > The prior config is wrong and no one noticed, probably because the filter on > the remote host discarded the extra log messages. > > Sorry my email is hard to read. When I sent it, the text looked OK, but what > I see in the mail-list is messed up. I suspect this is from me cutting and > pasting text I wrote in a separate editor while waiting for approval to post > to the mail list. > > It would be nice if the mail list for rsyslog was entirely converted to > github issues. Other projects have done this, where they have different issue > lists for questions verses bugs. I find the markdown helpful in formatting > snippets, etc. > > I appear to be getting emails from the rsyslog mail list OK. However I didn't > save my password and the 'Remind' submit does not result in me receiving the > email reminder. I checked spam. > > Thank you for your input! > > On Wednesday, May 21, 2025 at 05:54:23 AM CDT, Rainer Gerhards > <[email protected]> wrote: > > > El mié, 21 may 2025 a las 0:01, J Harri (<[email protected]>) 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 > > <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > > > To: "[email protected]" <[email protected]> > > > Cc: J Harri <[email protected]> > > > 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.
