On Tue, Mar 11, 2014 at 9:41 AM, Radu Gheorghe <[email protected]>wrote:
> Thanks! And thanks for the clarifications! > > If I can help with anything (tests, etc), let me know. > > Indeed, this would be very useful. I have changed librelp to be able to work without TLS and modified rsyslog so that it emits proper error messsages are emitted if relp is tried to be used with a non-tls librelp. Andre is just building some experimental packages. I took the liberty to ask him to mail you these RPMs. It would be great if you could give them a try. If they work ok, I'll finally do the rsyslog 7.6.1 release. Rainer > On Mon, Mar 10, 2014 at 6:08 PM, Rainer Gerhards > <[email protected]> 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 > > <[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. > > > > -- > 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.
