[rsyslog] imfile buffer overflow master-candidate
I've found a buffer overflow in imfile in the master-candidate branch. To reproduce, make an imfile config that uses a relative path rather than absolute to a file: ``` module(load="imfile" PollingInterval="10") input( type="imfile" tag="crash" File="crashme" ) *.* /var/log/syslog ``` This results in: ``` 3146.392981790:main thread: deletestateonfiledelete: (unset) 3146.392987727:main thread: addmetadata: (unset) 3146.392993638:main thread: addceetag: (unset) 3146.392999527:main thread: statefile: (unset) *** buffer overflow detected ***: rsyslogd terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] rsyslogd(inputProcessCnf+0x99)[0x4147a9] rsyslogd(cnfDoObj+0x90)[0x414ba0] rsyslogd(yyparse+0xbae)[0x45435e] rsyslogd(load+0xc35)[0x414145] rsyslogd(initAll+0x5ef)[0x448e2f] rsyslogd(main+0x30)[0x40dfe0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] rsyslogd[0x40e35a] ``` I don't have time to dig into it today but wanted to go ahead and report it. If I correctly use an absolute path to the file (I used a relative by mistake when testing and found this), things work as expected. If I get some time tomorrow to dig into it I will! Cheers, Brian ___ 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.
Re: [rsyslog] imfile buffer overflow master-candidate
A little more info: Program received signal SIGABRT, Aborted. 0x769efcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) backtrace #0 0x769efcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x769f30d8 in __GI_abort () at abort.c:89 #2 0x76a2c394 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x76b3852b "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x76ac3c9c in __GI___fortify_fail (msg=, msg@entry=0x76b384c2 "buffer overflow detected") at fortify_fail.c:37 #4 0x76ac2b60 in __GI___chk_fail () at chk_fail.c:28 #5 0x763a02cd in memcpy (__len=18446744073709551615, __src=, __dest=0x7fffd040) at /usr/include/x86_64-linux-gnu/bits/string3.h:51 #6 checkInstance (inst=0x6b0210) at imfile.c:727 #7 0x763a054d in newInpInst (lst=) at imfile.c:1066 #8 0x004147a9 in inputProcessCnf (o=o@entry=0x6adc60) at rsconf.c:354 #9 0x00414ba0 in cnfDoObj (o=0x6adc60) at rsconf.c:427 #10 0x0045435e in yyparse () at grammar.y:129 #11 0x00414145 in load (cnf=0x695cd0 , confFile=0x470309 "/etc/rsyslog.conf") at rsconf.c:1286 #12 0x00448e2f in initAll (argc=argc@entry=1, argv=argv@entry=0x7fffe688) at rsyslogd.c:1252 #13 0x0040dfe0 in main (argc=1, argv=0x7fffe688) at rsyslogd.c:1640 (gdb) frame 13 #13 0x0040dfe0 in main (argc=1, argv=0x7fffe688) at rsyslogd.c:1640 1640initAll(argc, argv); (gdb) print argc $1 = 1 (gdb) print argv $2 = (char **) 0x7fffe688 On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox wrote: > I've found a buffer overflow in imfile in the master-candidate branch. To > reproduce, make an imfile config that uses a relative path rather than > absolute to a file: > > ``` > module(load="imfile" PollingInterval="10") > > input( > type="imfile" > tag="crash" > File="crashme" > ) > > *.* /var/log/syslog > ``` > > This results in: > > ``` > 3146.392981790:main thread: deletestateonfiledelete: (unset) > 3146.392987727:main thread: addmetadata: (unset) > 3146.392993638:main thread: addceetag: (unset) > 3146.392999527:main thread: statefile: (unset) > *** buffer overflow detected ***: rsyslogd terminated > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] > /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] > /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] > /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] > rsyslogd(inputProcessCnf+0x99)[0x4147a9] > rsyslogd(cnfDoObj+0x90)[0x414ba0] > rsyslogd(yyparse+0xbae)[0x45435e] > rsyslogd(load+0xc35)[0x414145] > rsyslogd(initAll+0x5ef)[0x448e2f] > rsyslogd(main+0x30)[0x40dfe0] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] > rsyslogd[0x40e35a] > ``` > > I don't have time to dig into it today but wanted to go ahead and report > it. If I correctly use an absolute path to the file (I used a relative by > mistake when testing and found this), things work as expected. > > If I get some time tomorrow to dig into it I will! > > Cheers, > Brian > > ___ 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.
Re: [rsyslog] imfile buffer overflow master-candidate
line 727 in imfile.c : memcpy(dirn, inst->pszFileName, i); /* do not copy slash */ On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox wrote: > I've found a buffer overflow in imfile in the master-candidate branch. To > reproduce, make an imfile config that uses a relative path rather than > absolute to a file: > > ``` > module(load="imfile" PollingInterval="10") > > input( > type="imfile" > tag="crash" > File="crashme" > ) > > *.* /var/log/syslog > ``` > > This results in: > > ``` > 3146.392981790:main thread: deletestateonfiledelete: (unset) > 3146.392987727:main thread: addmetadata: (unset) > 3146.392993638:main thread: addceetag: (unset) > 3146.392999527:main thread: statefile: (unset) > *** buffer overflow detected ***: rsyslogd terminated > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] > /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] > /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] > /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] > /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] > rsyslogd(inputProcessCnf+0x99)[0x4147a9] > rsyslogd(cnfDoObj+0x90)[0x414ba0] > rsyslogd(yyparse+0xbae)[0x45435e] > rsyslogd(load+0xc35)[0x414145] > rsyslogd(initAll+0x5ef)[0x448e2f] > rsyslogd(main+0x30)[0x40dfe0] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] > rsyslogd[0x40e35a] > ``` > > I don't have time to dig into it today but wanted to go ahead and report > it. If I correctly use an absolute path to the file (I used a relative by > mistake when testing and found this), things work as expected. > > If I get some time tomorrow to dig into it I will! > > Cheers, > Brian > > ___ 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.
Re: [rsyslog] imfile buffer overflow master-candidate
https://github.com/rsyslog/rsyslog/blob/b5649a98107a8e6b7042e103f17bb16e907504f2/plugins/imfile/imfile.c#L686 Looks like getBasename should perhaps return a -1 if it doesn't find a slash - and then we can "do the right thing" based on that. I'll see if I can sneak in time for a fix today or tomorrow. Cheers, Brian On Thu, Mar 3, 2016 at 9:04 AM, Brian Knox wrote: > line 727 in imfile.c : > > memcpy(dirn, inst->pszFileName, i); /* do not copy slash */ > > > On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox wrote: > >> I've found a buffer overflow in imfile in the master-candidate branch. >> To reproduce, make an imfile config that uses a relative path rather than >> absolute to a file: >> >> ``` >> module(load="imfile" PollingInterval="10") >> >> input( >> type="imfile" >> tag="crash" >> File="crashme" >> ) >> >> *.* /var/log/syslog >> ``` >> >> This results in: >> >> ``` >> 3146.392981790:main thread: deletestateonfiledelete: (unset) >> 3146.392987727:main thread: addmetadata: (unset) >> 3146.392993638:main thread: addceetag: (unset) >> 3146.392999527:main thread: statefile: (unset) >> *** buffer overflow detected ***: rsyslogd terminated >> === Backtrace: = >> /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] >> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] >> /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] >> /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] >> /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] >> rsyslogd(inputProcessCnf+0x99)[0x4147a9] >> rsyslogd(cnfDoObj+0x90)[0x414ba0] >> rsyslogd(yyparse+0xbae)[0x45435e] >> rsyslogd(load+0xc35)[0x414145] >> rsyslogd(initAll+0x5ef)[0x448e2f] >> rsyslogd(main+0x30)[0x40dfe0] >> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] >> rsyslogd[0x40e35a] >> ``` >> >> I don't have time to dig into it today but wanted to go ahead and report >> it. If I correctly use an absolute path to the file (I used a relative by >> mistake when testing and found this), things work as expected. >> >> If I get some time tomorrow to dig into it I will! >> >> Cheers, >> Brian >> >> > ___ 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.
Re: [rsyslog] imfile buffer overflow master-candidate
Here we go - https://github.com/rsyslog/rsyslog/pull/840 On Thu, Mar 3, 2016 at 9:15 AM, Brian Knox wrote: > > https://github.com/rsyslog/rsyslog/blob/b5649a98107a8e6b7042e103f17bb16e907504f2/plugins/imfile/imfile.c#L686 > > Looks like getBasename should perhaps return a -1 if it doesn't find a > slash - and then we can "do the right thing" based on that. I'll see if I > can sneak in time for a fix today or tomorrow. > > Cheers, > Brian > > On Thu, Mar 3, 2016 at 9:04 AM, Brian Knox wrote: > >> line 727 in imfile.c : >> >> memcpy(dirn, inst->pszFileName, i); /* do not copy slash */ >> >> >> On Thu, Mar 3, 2016 at 8:53 AM, Brian Knox >> wrote: >> >>> I've found a buffer overflow in imfile in the master-candidate branch. >>> To reproduce, make an imfile config that uses a relative path rather than >>> absolute to a file: >>> >>> ``` >>> module(load="imfile" PollingInterval="10") >>> >>> input( >>> type="imfile" >>> tag="crash" >>> File="crashme" >>> ) >>> >>> *.* /var/log/syslog >>> ``` >>> >>> This results in: >>> >>> ``` >>> 3146.392981790:main thread: deletestateonfiledelete: (unset) >>> 3146.392987727:main thread: addmetadata: (unset) >>> 3146.392993638:main thread: addceetag: (unset) >>> 3146.392999527:main thread: statefile: (unset) >>> *** buffer overflow detected ***: rsyslogd terminated >>> === Backtrace: = >>> /lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f286982b38f] >>> /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f28698c2c9c] >>> /lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f28698c1b60] >>> /usr/local/lib/rsyslog/imfile.so(+0x22cd)[0x7f286919f2cd] >>> /usr/local/lib/rsyslog/imfile.so(+0x254d)[0x7f286919f54d] >>> rsyslogd(inputProcessCnf+0x99)[0x4147a9] >>> rsyslogd(cnfDoObj+0x90)[0x414ba0] >>> rsyslogd(yyparse+0xbae)[0x45435e] >>> rsyslogd(load+0xc35)[0x414145] >>> rsyslogd(initAll+0x5ef)[0x448e2f] >>> rsyslogd(main+0x30)[0x40dfe0] >>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f28697d9ec5] >>> rsyslogd[0x40e35a] >>> ``` >>> >>> I don't have time to dig into it today but wanted to go ahead and report >>> it. If I correctly use an absolute path to the file (I used a relative by >>> mistake when testing and found this), things work as expected. >>> >>> If I get some time tomorrow to dig into it I will! >>> >>> Cheers, >>> Brian >>> >>> >> > ___ 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] Forwarding to multiple syslog servers and HA
Hi folks! I'm looking at setting up some systems, where rsyslog is reading logs from disk and forwarding them to two centralise servers at the same time. I have a question around a specific failure scenario: If one of the two central servers goes down, how does rsyslog behave? Does it keep sending to the other server? Is the tracking and queuing for each destination independent, or are logs sent serially to each destination and one server being down would block delivery to other remote destinations? I was thinking about using the omfwd module (so no RELP, until I can get the upstream syslog servers converted to rsyslog, too). Does that seem reasonable? Thanks! ___ 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.
Re: [rsyslog] Forwarding to multiple syslog servers and HA
On Thu, 3 Mar 2016, Avleen Vig wrote: Hi folks! I'm looking at setting up some systems, where rsyslog is reading logs from disk and forwarding them to two centralise servers at the same time. I have a question around a specific failure scenario: If one of the two central servers goes down, how does rsyslog behave? Does it keep sending to the other server? Is the tracking and queuing for each destination independent, or are logs sent serially to each destination and one server being down would block delivery to other remote destinations? this all depends on how you have things configured. the default is not to have separate queues for different outputs, but that's something you can configure. If you use UDP, you don't know if the log is getting to the destination or not. If you use TCP, and the network queues fill up, processing will stop until it clears (if you have a separate queue for that output, only processing on that queue will stop, if you share a queue with some other output, processing for that other output will stop as well. each queue has a worker thread that loops through all outputs for that queue, trying to deliver to them in turn. If one blocks that worker has the choice (configurable) to either block, or throw away the log for that output and continue to the next one. by default rsyslog has one main queue. you can configure additional queues for either actions or rulesets. It's strongly recommended that you use a current version and the new syntax when configuring queues. It makes it MUCH clearer what is happening. David Lang ___ 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.
Re: [rsyslog] Forwarding to multiple syslog servers and HA
On Thu, Mar 3, 2016 at 6:30 PM David Lang wrote: > On Thu, 3 Mar 2016, Avleen Vig wrote: > > > Hi folks! > > > > I'm looking at setting up some systems, where rsyslog is reading logs > from > > disk and forwarding them to two centralise servers at the same time. > > > > I have a question around a specific failure scenario: > > If one of the two central servers goes down, how does rsyslog behave? > > Does it keep sending to the other server? > > Is the tracking and queuing for each destination independent, or are > logs > > sent serially to each destination and one server being down would block > > delivery to other remote destinations? > > this all depends on how you have things configured. > > the default is not to have separate queues for different outputs, but > that's > something you can configure. > > If you use UDP, you don't know if the log is getting to the destination or > not. > > If you use TCP, and the network queues fill up, processing will stop until > it > clears (if you have a separate queue for that output, only processing on > that > queue will stop, if you share a queue with some other output, processing > for > that other output will stop as well. > > > each queue has a worker thread that loops through all outputs for that > queue, > trying to deliver to them in turn. If one blocks that worker has the choice > (configurable) to either block, or throw away the log for that output and > continue to the next one. > > by default rsyslog has one main queue. you can configure additional queues > for > either actions or rulesets. > > It's strongly recommended that you use a current version and the new > syntax when > configuring queues. It makes it MUCH clearer what is happening. > Thanks David! That's actually exactly what I needed to know. When you say "current version", do you mean 8.x? RHEL ships with 7.4.7, if that's current enough. If not, I'll grab 8.16. Thanks again! ___ 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.
Re: [rsyslog] Forwarding to multiple syslog servers and HA
On Fri, 4 Mar 2016, Avleen Vig wrote: Subject: Re: [rsyslog] Forwarding to multiple syslog servers and HA On Thu, Mar 3, 2016 at 6:30 PM David Lang wrote: On Thu, 3 Mar 2016, Avleen Vig wrote: Hi folks! I'm looking at setting up some systems, where rsyslog is reading logs from disk and forwarding them to two centralise servers at the same time. I have a question around a specific failure scenario: If one of the two central servers goes down, how does rsyslog behave? Does it keep sending to the other server? Is the tracking and queuing for each destination independent, or are logs sent serially to each destination and one server being down would block delivery to other remote destinations? this all depends on how you have things configured. the default is not to have separate queues for different outputs, but that's something you can configure. If you use UDP, you don't know if the log is getting to the destination or not. If you use TCP, and the network queues fill up, processing will stop until it clears (if you have a separate queue for that output, only processing on that queue will stop, if you share a queue with some other output, processing for that other output will stop as well. each queue has a worker thread that loops through all outputs for that queue, trying to deliver to them in turn. If one blocks that worker has the choice (configurable) to either block, or throw away the log for that output and continue to the next one. by default rsyslog has one main queue. you can configure additional queues for either actions or rulesets. It's strongly recommended that you use a current version and the new syntax when configuring queues. It makes it MUCH clearer what is happening. Thanks David! That's actually exactly what I needed to know. When you say "current version", do you mean 8.x? RHEL ships with 7.4.7, if that's current enough. If not, I'll grab 8.16. 7.4.7 is new enough to have the new syntax, but there are a LOT of fixes and new features by 8.16 (8.17 is due to be released tuesday). For end nodes that just need to send logs in to your central server, 7.4.7 is probably good enough (although if you trip over any bugs on it, just go to a current version). But on your log relays and central servers, or anywhere that you start doing more complex stuff, just go to the current version. When you ask questions here, we are always going to be thinking in terms of the most current version. Bugs get fixed in the most current version and only some get backported by the distro to the older versions. David Lang ___ 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.
Re: [rsyslog] Forwarding to multiple syslog servers and HA
On Thu, Mar 3, 2016, 19:40 David Lang wrote: > On Fri, 4 Mar 2016, Avleen Vig wrote: > > > Subject: Re: [rsyslog] Forwarding to multiple syslog servers and HA > > > > On Thu, Mar 3, 2016 at 6:30 PM David Lang wrote: > > > >> On Thu, 3 Mar 2016, Avleen Vig wrote: > >> > >>> Hi folks! > >>> > >>> I'm looking at setting up some systems, where rsyslog is reading logs > >> from > >>> disk and forwarding them to two centralise servers at the same time. > >>> > >>> I have a question around a specific failure scenario: > >>> If one of the two central servers goes down, how does rsyslog behave? > >>> Does it keep sending to the other server? > >>> Is the tracking and queuing for each destination independent, or are > >> logs > >>> sent serially to each destination and one server being down would block > >>> delivery to other remote destinations? > >> > >> this all depends on how you have things configured. > >> > >> the default is not to have separate queues for different outputs, but > >> that's > >> something you can configure. > >> > >> If you use UDP, you don't know if the log is getting to the destination > or > >> not. > >> > >> If you use TCP, and the network queues fill up, processing will stop > until > >> it > >> clears (if you have a separate queue for that output, only processing on > >> that > >> queue will stop, if you share a queue with some other output, processing > >> for > >> that other output will stop as well. > >> > >> > >> each queue has a worker thread that loops through all outputs for that > >> queue, > >> trying to deliver to them in turn. If one blocks that worker has the > choice > >> (configurable) to either block, or throw away the log for that output > and > >> continue to the next one. > >> > >> by default rsyslog has one main queue. you can configure additional > queues > >> for > >> either actions or rulesets. > >> > >> It's strongly recommended that you use a current version and the new > >> syntax when > >> configuring queues. It makes it MUCH clearer what is happening. > >> > > > > Thanks David! > > That's actually exactly what I needed to know. > > > > When you say "current version", do you mean 8.x? > > RHEL ships with 7.4.7, if that's current enough. If not, I'll grab 8.16. > > 7.4.7 is new enough to have the new syntax, but there are a LOT of fixes > and new > features by 8.16 (8.17 is due to be released tuesday). > > For end nodes that just need to send logs in to your central server, 7.4.7 > is > probably good enough (although if you trip over any bugs on it, just go to > a > current version). > > But on your log relays and central servers, or anywhere that you start > doing > more complex stuff, just go to the current version. When you ask questions > here, > we are always going to be thinking in terms of the most current version. > Bugs > get fixed in the most current version and only some get backported by the > distro > to the older versions. > Perfect. Many thanks again! David Lang > ___ > 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.
