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 <[email protected]>wrote: > On Mon, Mar 10, 2014 at 1:23 PM, Radu Gheorghe <[email protected] > > 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 >> <[email protected]> wrote: >> > On Mon, Mar 10, 2014 at 11:01 AM, Radu Gheorghe >> > <[email protected]>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 >> >> <[email protected]> wrote: >> >> > On Fri, Mar 7, 2014 at 2:34 PM, Radu Gheorghe < >> >> [email protected]>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.
