Hi,
Just for future generations. It was my mistake. In the rsyslog chain of forwarding there was a mix of UDP and TCP. The destination listened on a different protocol. So I saw the messages, they just weren't coming through because rsyslog listened on another protocol. Sorry for the late update. Thanks for the details though, it helped me troubleshoot rsylog better. -- Kees de Jong | Supercomputing | https://www.surf.nl/en/about-surf OpenPGP fingerprint: 0x0E45C98AB51428E6 On Mon, 2024-03-25 at 13:36 -0700, David Lang wrote: > Ok, the fact that you are getting other logs remotely does eliminate > the > permission/network problems. > > That just means that the filters you are applying to find the bash > logs are not > matching the log contents. > > To figure this out, you need to figure out what is actually being > sent (since > it's not what you think is being sent or it would match your > filters). To figure > this out, we need to figure out exactly what is being sent. > > The best way to do this is to configure the reciving syslog server to > log all > logs using the template RSYSLOG_DebugFormat, a line like the > following would do > it > > /var/log/debuglog;RSYSLOG_DebugFormat > > then find a sample of the log message you are looking for in this > log, and you > should then be able to see both the rawmsg of exactly what is > arriving, and the > various properties showing how it was parsed apart. At that point you > should be > able to adjust your filters to match the log message. > > You can also dump the log message via tcpdump and analyse that, but > that > requires manually figuring out how the log is being parsed. > > I don't believe that you have shown a sample of what the log message > looks like > (if you did, I apologize for missing it, please re-post it) > > when the problem isn't network/permissions, >90% of the time the > problem is that > the log isn't being parsed the way you think it is, so the filter > doesn't match. > > David Lang > > On Mon, 25 Mar 2024, Kees de Jong via rsyslog wrote: > > > Hi David, > > > > > > > > SELinux is disabled on all hosts. Other logs do get through from > > remote > > hosts and are stored on a local disk. In this test setup I only > > enabled > > the config for Bash history. I did this to exclude any > > configuration > > that might intercept or drop the Bash history logs. > > > > But when I include the other configs again, they log just fine > > locally. > > So I think we can exclude systemd or a firewall in that case. Also, > > when I use netcat, I can send over messages over those ports and > > see > > them also with tcpdump. > > > > > on the receiving system, log the messages with the template > > RSYSLOG_DebugFormat and give us a sample message. > > > > What exactly do you mean by this? Could you please elaborate on > > that? > > At the moment no messages are logged for the Bash history. How can > > I > > use this template to enhance the debugging? Thanks! > > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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.
