> -----Original Message----- > From: rsyslog-boun...@lists.adiscon.com [mailto:rsyslog- > boun...@lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, March 10, 2014 12:01 PM > To: rsyslog-users > Subject: Re: [rsyslog] GnuTLS for imtcp vs imrelp (was: could not load module > imrelp.so) > > On Mon, Mar 10, 2014 at 11:01 AM, Radu Gheorghe > <radu.gheor...@sematext.com>wrote: > > > Hi guys, thanks a lot for your replies! > > > > @Asaaf: I know installing a newer GnuTLS version will help make RELP > > work. The problem is, it breaks my TCP+TLS setup. > > > > @Rainer: If there's something wrong with my build, then the bug is in > > the packages, because I'm using the 8.1.6 RPMs. Maybe Andre can give > > some insight? > > > > This is also the answer to your text below. The packages are correct, but this > is a good example why I don't like to duplicate the distro maintainers job (for > "external packages"). > > The rsyslog RPM is perfect, BUT you have installed a new version of GnuTLS > AND the new GnuTLS seems to be not backwards-compatible. So the new > version breaks any app that expects the older version. This is rsyslog, but if > you look further, I'd guess that most packages that rely on GnuTLS will be > broken after this upgrade. > > The reason is that usually the configure script is used to detect the > environment, and then the build assumes this environment and uses the > proper code path (using conditional compilation). Usually, this is not a > problem, as APIs remain stable. With GnuTLS, this unfortunately seems not > to be the case (I judge based on your report), because it looks like an existing > API is no longer supported by newer versions of the lib. IMHO that's a bad > thing to do, but if it is that way, you cannot get around it other by re-building > packages like rsyslog (starting with ./configure, as usual). > > If we go now ahead and package GnuTLS as a system lib and ship it, we will > break many other packages. This is what the distro maintainers keep track of, > seeing such things and re-building all associated packages. Definitely not > something we want to do (not the mention we don't have the resources > even if we would want to). > > Shipping it is a integrated component is also very ugly. Just think of the > security incident, we would need to keep track of all those things. > > So I need to conclude that on a platform, no matter how recent it is, that > does not support the necessary core software stack, we need to disable > functionality. I agree that disabling RELP is too much, but the only decent > solution I see is to disable the RELP TLS feature. If someone wants it, he or > she can still install the required packages from source. We do have > instructions on how to do that, it's still inconvenient, but again, everything > else I strongly think is far beyond the scope of the rsyslog project.
My tests rebuilding newer GNUTLS Version have shown lots of missing dependencies which need to be built as well. I would agree to disable the RELP SSL feature on EHEL 5/6 instead of building a newer GNUTLS package. Best regards, Andre _______________________________________________ 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.
