Thanks! And thanks for the clarifications! If I can help with anything (tests, etc), let me know.
On Mon, Mar 10, 2014 at 6:08 PM, Rainer Gerhards <rgerha...@hq.adiscon.com> wrote: > I now track this issue here: > > https://github.com/rsyslog/librelp/issues/1 > > Rainer > > > On Mon, Mar 10, 2014 at 4:49 PM, Rainer Gerhards > <rgerha...@hq.adiscon.com>wrote: > >> On Mon, Mar 10, 2014 at 1:23 PM, Radu Gheorghe <radu.gheor...@sematext.com >> > wrote: >> >>> Hi Rainer, >>> >>> Thanks for your answer. I see what you're saying and I agree. >>> >>> I'm [trying to] focus on a solution, so it sounds like, for my >>> particular case (I want TCP+TLS and RELP), the solution would be to >>> disable RELP+TLS? How can we do this: >>> a) at ./configure time? I guess you can do the code change you were >>> talking about previously, to disable TLS if the GnuTLS version found >>> is too old? >>> >> >> it acutally must be done in librelp, with some support for clients like >> rsyslog. >> >> >>> b) in the packages? I guess we'll have a rsyslog-relp and a >>> rsyslog-relp-tls package? >>> >>> >> no, simply because we cannot have relp with TLS on those platforms. So >> there is one librelp package, and the API must be extended to tell clients >> whether or not it supports TLS. I'll have a look at this soon. >> >> >>> Another question that I have, which doesn't concern me right now, but >>> still: how will one be able to listen for both TCP+TLS and RELP+TLS, >>> since the two seem to require different GnuTLS versions? >> >> >> NO! The problem is GnuTLS, which has broken it's API or ABI. So >> ./configure must be run when the version of GnuTLS that you want to use is >> installed. That's not an rsyslog-exclusive problem, I guess most other >> programs will see the same issue. >> >> >>> The only >>> workaround I can think of is to have two daemons, and use different >>> LD_LIBRARY_PATH variables when launching them, which point to the two >>> versions of GnuTLS installed. >>> >>> Or maybe I'm doing something wrong. Maybe rsyslog is able to run both >>> in some circumstances, and I didn't figure out how. Is there any info >>> I can provide or anything I can do to solve the mistery? >>> >>> >> build rsyslog from source AFTER you have moved to the new GnuTLS and all >> will work well. >> >> Rainer >> >> >>> Thanks a lot for looking into this! >>> >>> Best regards, >>> Radu >>> >>> On Mon, Mar 10, 2014 at 1:00 PM, Rainer Gerhards >>> <rgerha...@hq.adiscon.com> wrote: >>> > 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. >>> > >>> > Rainer >>> > >>> >> >>> >> I'll answer to your comments inline: >>> >> >>> >> On Fri, Mar 7, 2014 at 6:08 PM, Rainer Gerhards >>> >> <rgerha...@hq.adiscon.com> wrote: >>> >> > On Fri, Mar 7, 2014 at 2:34 PM, Radu Gheorghe < >>> >> radu.gheor...@sematext.com>wrote: >>> >> [...] >>> >> >> ####possible solutions#### >>> >> >> I think there's a bunch of things that can be improved. I'm writing >>> >> >> this from the user's point of view, because I don't know the >>> >> >> implementation details and what's technically possible: >>> >> >> - imrelp.so shouldn't depend on GnuTLS. IMO people that don't need >>> TLS >>> >> >> shouldn't have this problem. Incidentally, this will also be a >>> >> >> workaround for me, because it means I can live with the system's >>> >> >> GnuTLS for lmnsd_gtls.so and use plain RELP. >>> >> >> >>> >> > >>> >> > well, we could do a configure check and statically disable the code >>> when >>> >> > gnutls is too old. Anything more fancy requires a code contributions >>> if I >>> >> > look at the current backlog. >>> >> > >>> >> >>> >> +1. I think this would be a good workaround for now. >>> >> >>> >> > >>> >> >> - ideally, TCP+TLS should work with the new GnuTLS version >>> >> > >>> >> > >>> >> > That's a new problem, they seem to have removed an API. TCP+TLS used >>> to >>> >> > work with any GnutTLS version. I routinely build both TCP/TLs + RELP >>> on >>> >> the >>> >> > same system. Will look into it... >>> >> > >>> >> >>> >> Thanks a lot! If you have any insight about this, please share :) >>> >> >>> >> > >>> >> >> and imrelp >>> >> >> should work with the old version >>> >> >> >>> >> > >>> >> > That's technically problematic and requires downgrading of the >>> feature >>> >> set. >>> >> > If I receive a code contribution, I am willing to consider that >>> path. I >>> >> > won't do anything in that regard myself. >>> >> >>> >> I thought the situation is something like this, that's why I said >>> >> "ideally"... >>> >> >>> >> > >>> >> > >>> >> >> - if the above is not possible, then I assume a certain version of >>> >> >> GnuTLS is required. So it should be included/added in the rsyslog >>> >> >> packages and installed in a separate location. I'm saying a separate >>> >> >> location is needed so it doesn't interfere with the system (maybe >>> >> >> there's some other software in the system that requires and older >>> >> >> version, and rsyslog's upgrade breaks it) >>> >> >> >>> >> >> >>> >> > I *really* don't like this idea, as this would mean we need to take >>> care >>> >> of >>> >> > duplicating the rest of the distro packaning. Where to stop? GnutTLS? >>> >> > Json-C, ...? In any case, there are also insufficient resources to do >>> >> that. >>> >> > >>> >> >>> >> I'm not sure if there's a "supported platforms" list anywhere, but I >>> >> think everyone expects rsyslog to work with at least the latest stable >>> >> versions of major distributions (RHEL, Debian, Ubuntu, etc). It sounds >>> >> like there are three options: >>> >> 1. support all the GnuTLS versions coming with those distributions. It >>> >> sounds like it won't work, because of what you said above >>> >> 2. provide (or find?) a package that would upgrade the distro's GnuTLS >>> >> to provide what rsyslog needs. I guess it's the easiest approach, >>> >> although it might break other apps that need GnuTLS and aren't >>> >> forward-compatible >>> >> 3. provide a package that would install the needed GnuTLS version in a >>> >> separate location. We don't have to do it for all dependencies, only >>> >> for those who turn out to be problematic. >>> >> >>> >> What's it going to be? 1) seems to be out because it's difficuly, 3) >>> >> is a bit too hacky. So that leaves us with 2)? Or do you see other >>> >> options? >>> >> >>> >> Still, with either 2) or 3), I think we still have to see how to make >>> >> TCP work with newer GnuTLS versions. Or maybe there's something wrong >>> >> with the packages. Can I help with anything to solve this, or should I >>> >> wait for you to look into the issue? >>> >> >>> >> Best regards, >>> >> Radu >>> >> _______________________________________________ >>> >> 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. >>> >>> >>> >>> -- >>> Performance Monitoring * Log Analytics * Search Analytics >>> Solr & Elasticsearch Support * http://sematext.com/ >>> _______________________________________________ >>> 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. -- Performance Monitoring * Log Analytics * Search Analytics Solr & Elasticsearch Support * http://sematext.com/ _______________________________________________ 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.
