Hi, Let me see if I get this right: rsyslog doesn't read files from /var/log/DefaultConfig.log ?
Is something continuously writing to that file? Because imfile normally tails files, it doesn't read from the beginning. I have a feeling I don't quite understand what you're trying to do (end to end). Best regards, Radu -- Elasticsearch/OpenSearch & Solr Consulting, Production Support & Training Sematext Cloud - Full Stack Observability https://sematext.com/ <http://sematext.com/> On Thu, Nov 9, 2023 at 1:27 PM Lennon, Sean (UK) via rsyslog < rsyslog@lists.adiscon.com> wrote: > > > > > This email may contain proprietary information of BAE Systems and/or third > parties. > > I've had a quick play, firstly I used a sender config (in /etc/rsyslogd/) > like this to store the generated messages whilst in the un-configured state: > ######################### > # Un-configured - default > ######################### > # Store all local6 messages whilst un-configured for later use > local6.* /var/log/DefaultConfig.log > > I've then sent some test messages through to rsyslog and I've observed > them being stored in the log file. > > Next, I switched configs to the one below, but only the messages via imtcp > came through, none of the stored messages were observed, I've obviously > failed to understand something, can someone shed some light on it please? > > ######################### > # Configured > ######################### > module(load="omrelp") > module(load="imfile") > module(load="imtcp") > > # Receive local6 messages directly from bespoke software > input(type="imtcp" > port="514" > ruleset="local6" > ) > > # Pickup any messages previously stored whilst un-configured > input(type="imfile" > File="/var/log/DefaultConfig.log" > Tag="DefaultConfig.log" > ruleset="local6" > ) > > # Send any local6 (imtcp or imfile) messages via RELP/TLS to the receiver. > ruleset(name="local6") { > action(type="omrelp" > target="192.168.0.201" > port="20514" > tls="on" > tls.CaCert.....etc. > ) > } > > Cheers, > > Sean. > > -----Original Message----- > From: rsyslog <rsyslog-boun...@lists.adiscon.com> On Behalf Of Lennon, > Sean (UK) via rsyslog > Sent: 07 November 2023 10:52 > To: rsyslog-users <rsyslog@lists.adiscon.com> > Cc: Lennon, Sean (UK) <sean.lenn...@baesystems.com> > Subject: [rsyslog] Capturing messages before RELP connection established. > > ----------------------------- PHISHING ALERT > ----------------------------- This email has been sent from an account > outside of the BAE Systems network. > > Please treat the email with caution, especially if you are requested to > click on a link or open an attachment. > For further information on how to spot and report a phishing email please > access the Global Intranet, then select <Functions> / <IT>. > > > ------------------------------------------------------------------------------------ > > This email may contain proprietary information of BAE Systems and/or third > parties. > > Hi All, > > I have a setup with two servers communication via RELP/TLS, one a sender > the other a receiver. However, during start up the sender will not be > aware of the identity of the receiver. This will be established at a later > point with the relevant relp.conf (in /etc/rsyslog.d) being created for the > sender and the service being restarted. This > > Until the identity of the receiver is known I would like to capture the > desired messages at the sender and then send those messages to the receiver > when RELP/TLS is fully establish. Can I establish RELP on the sender > without a known destination - will RELP remember the buffered messages > after a restart? If not then I assume that I will have to send messages to > an interim log file. In that case how can I get the sender to hoover up > those stored messages and push them through RELP? > > Thanks in advance. > > Sean. > > ******************************************************************** > This email and any attachments are confidential to the intended recipient > and may also be privileged. If you are not the intended recipient please > delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > BAE Systems may process information about you that may be subject to data > protection laws. For more information about how we use your personal > information, how we protect your information, our legal basis for using > your information, your rights and who you can contact, please refer to our > Privacy Notice at www.baesystems.com/en/privacy > _______________________________________________ > 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.
