2018-04-24 13:38 GMT+02:00 putcha narayana <[email protected]>:
> 😊 wasn't me. so that makes 2 of us asking for same lol. > > > i think, using global variable would have kept the export and backtick > options out of the rsyslogd. But i am sure the support was provided after > careful consideration and requests from others. > Actually, I still don't understand why this is helpful. After all, that means you need to *edit* the rsyslog configuration. That's actually what your script does when it modifies the local variables. So you need to mess up with the config in any case. With the backticks approach, all is done outside of the actual config, and actually this was the design goal - keep the config read only, so you can ship a standard config for your application and have an external file that just adds the special bits. I would really like to understand why you think global constants (there are NOT variable, right?) would make sense. Maybe we are overlooking something... > > the link https://www.rsyslog.com/doc/master/rainerscript/ > constant_strings.html is missing info on when to us them. > > https://github.com/rsyslog/rsyslog-docker/tree/master/appliance/alpine > provides > one example. > > may be having references from action and other places where it can be used > could help. or a short explanation in the constant_strings section about > usage and examples will help too. > > > i felt that gap that each section is missing that short list of examples. > i bet not all scenarios can be covered with examples but a short list of > plausible alternatives can help to a great extent. > Your contribution is happily accepted at https://github.com/rsyslog/rsyslog-doc - really, not kidding. There is so much to do, we depend on contributions (especially on the doc, as e.g. from my perspective I really don't come up with the questions new users might have)... Rainer > ------------------------------ > *From:* Rainer Gerhards <[email protected]> > *Sent:* Tuesday, April 24, 2018 11:11 AM > *To:* putcha narayana > *Cc:* rsyslog-users; David Lang > *Subject:* Re: [rsyslog] Urgent, need help with correct usage of local > variables in an action > > You can also have a look here - came in co-incidentely (or was it you? > ;-)): https://unix.stackexchange.com/questions/439286/how-to- > set-and-use-constants-in-rsyslog-rainerscript/ > > > <https://unix.stackexchange.com/questions/439286/how-to-set-and-use-constants-in-rsyslog-rainerscript/> > How to set and use constants in rsyslog (RainerScript)? > <https://unix.stackexchange.com/questions/439286/how-to-set-and-use-constants-in-rsyslog-rainerscript/> > unix.stackexchange.com > I'm writing an application which includes an rsyslog configuration which > gets placed in /etc/rsyslog.d/. Certain logmessages should be redirected to > a named pipe, like so: template (name="my_fmt"... > > > > > Rainer > > 2018-04-24 12:56 GMT+02:00 Rainer Gerhards <[email protected]>: > > Looking at your script, I wonder why you make it so complicated. You > > replace the local variable via sed anyway. Why not simply replacing > > the name inside the action target? > > > > Rainer > > > > 2018-04-24 10:47 GMT+02:00 putcha narayana <[email protected]>: > >> Hello Rainer, > >> > >> > >> I shared an example of the mechanism i planned to employ. I understand > that > >> my mechanism cannot be achieved with the current rsyslogd. There is no > hard > >> and fast rule to only use the mechanism i shared. > >> > >> > >> I will be happy to employ an alternate working mechanism. Now that my > end > >> goal is clear, please share some example for the alternate methods, i > will > >> employ them. > >> > >> > >> Appreciate your help. > >> > >> > >> Thanks and Regards > >> > >> Lak. > >> > >> > >> ________________________________ > >> From: Rainer Gerhards <[email protected]> > >> Sent: Tuesday, April 24, 2018 8:43 AM > >> To: putcha narayana > >> Cc: rsyslog-users; David Lang > >> > >> Subject: Re: [rsyslog] Urgent, need help with correct usage of local > >> variables in an action > >> > >> Well, there are ways to do this, just not like you want ;-) > >> > >> Environment variables and files is the way to go. > >> > >> Rainer > >> > >> Sent from phone, thus brief. > >> > >> putcha narayana <[email protected]> schrieb am Di., 24. Apr. > 2018, > >> 10:32: > >> > >> I believe it will be a good useful feature to allow users to define > >> local/global variables so that update in individual conf file or one > place > >> update of global variables will enable configuring the external server > IP > >> and Port. > >> > >> > >> I plan to use a static IP in the .66-MgmtMsgsLogging.conf. > >> > >> When IP and Port are updated then using the script i will replace them. > >> > >> When enable option is given then the comment in front of action will be > >> removed. > >> > >> To disable add the # back. > >> > >> > >> #action(type="omfwd" Target="10.10.10.10" Port="0" Protocol="udp" > >> Template="ForwardFormat") > >> #action(type="omfwd" Target="11.11.11.11" Port="0" Protocol="udp" > >> Template="ForwardFormat") > >> > >> > >> Thanks and Regards > >> > >> Lak. > >> > >> > >> > >> > >> > >> ________________________________ > >> From: Rainer Gerhards <[email protected]> > >> Sent: Tuesday, April 24, 2018 8:23 AM > >> To: rsyslog-users > >> Cc: David Lang; putcha narayana > >> Subject: Re: [rsyslog] Urgent, need help with correct usage of local > >> variables in an action > >> > >> Of you insist on using local variables, the answer is: no, this does not > >> work. > >> > >> Rainer > >> > >> Sent from phone, thus brief. > >> > >> putcha narayana via rsyslog <[email protected]> schrieb am > Di., 24. > >> Apr. 2018, 10:08: > >> > >> Hi, > >> > >> > >> I am not requesting for script to update the config file. I have already > >> implemented that. I have attached the shell script and a sample config > file. > >> > >> > >> I am seeking help w.r.t the config file with a provision to use local > >> variables so that they can be updated/configurable by user. > >> > >> > >> Thanks and Regards > >> > >> Lak. > >> > >> > >> ________________________________ > >> From: David Lang <[email protected]> > >> Sent: Tuesday, April 24, 2018 6:59 AM > >> To: putcha narayana > >> Cc: David Lang; putcha narayana via rsyslog > >> Subject: Re: [rsyslog] Urgent, need help with correct usage of local > >> variables in an action > >> > >> This cannot be done inside rsyslog, you would need to use some external > >> software > >> (puppet, chef, salt, ansible, or even just sed) to change the config > file > >> and > >> then start/restart rsyslog > >> > >> On Tue, 24 Apr 2018, putcha narayana wrote: > >> > >>> Date: Tue, 24 Apr 2018 06:47:03 +0000 > >>> From: putcha narayana <[email protected]> > >>> To: David Lang <[email protected]>, > >>> putcha narayana via rsyslog <[email protected]> > >>> Subject: Re: [rsyslog] Urgent, > >>> need help with correct usage of local variables in an action > >>> > >>> Hi, > >>> > >>> > >>> In our design we have a GUI where operator can configure the IP and > Port > >>> of the remote syslog server. Operator can enable or disable streaming > to the > >>> configured IP and Port using a flag. > >>> > >>> > >>> In the backend we will consume the configuration made by the operator > and > >>> prepare the required configuration file to stream logs to the > configured > >>> remote syslog server (Identified by IP and Port). > >>> > >>> > >>> 1) In the design i chose, I plan to have initial config files prefixed > >>> with '.' so that those config files will not be read by rsyslogd. > >>> > >>> Example config file is enclosed below. > >>> > >>> 2) When operator configures the IP, Port, then a script will be > invoked in > >>> the background which will update the initial set of lines that define > the > >>> local variables. Say set $.IPADDRESS1 = ""; will be updated as set > >>> $.IPADDRESS1 = "10.10.100.200"; > >>> > >>> 3) Config file updated will be saved without the '.' prefix. restarting > >>> rsyslod will/should apply the configuration (i.e., stream logs to > remote > >>> syslog server 10.10.100.200. > >>> > >>> > >>> Example config file with 2 remote syslog servers for illustration > purpose: > >>> > >>> set $.IPADDRESS1 = ""; > >>> set $.IPADDRESS2 = ""; > >>> set $.PORTNUMBER1 = ""; > >>> set $.PORTNUMBER2 = ""; > >>> > >>> if ($syslogseverity-text == 'info') > >>> then > >>> { > >>> action(type="omfwd" Target="$.IPADDRESS1" Port="$.PORTNUMBER1" > >>> Protocol="udp" Template="ForwardFormat") > >>> action(type="omfwd" Target="$.IPADDRESS2" Port="$.PORTNUMBER2" > >>> Protocol="udp" Template="ForwardFormat") > >>> stop > >>> } > >>> > >>> > >>> Please guide me if the same can be achieved using alternate mechanisms. > >>> > >>> > >>> thanks and regards > >>> > >>> Lak. > >>> > >>> > >>> > >>> ________________________________ > >>> From: David Lang <[email protected]> > >>> Sent: Tuesday, April 24, 2018 5:36 AM > >>> To: putcha narayana via rsyslog > >>> Cc: Rainer Gerhards; putcha narayana > >>> Subject: Re: [rsyslog] Urgent, need help with correct usage of local > >>> variables in an action > >>> > >>> target and port cannot be variables, variables can only be used where > they > >>> are > >>> explicitly allowed (almost entirely in templates) > >>> > >>> let's back up a bit and ask what you are trying to do rather than why > this > >>> specific approach doesn't work. > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://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 http://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.
