On Tue, Mar 11, 2014 at 11:53 AM, Radu Gheorghe <radu.gheor...@sematext.com>wrote:
> Hi Rainer, > > This sounds very good, thank you. > > Will those changes also go to 8.2.0 or somewhere in 8.x? I'm on 8.1.6 > at the moment. > > Best regards, > Radu > > On Tue, Mar 11, 2014 at 11:05 AM, Rainer Gerhards > <rgerha...@hq.adiscon.com> wrote: > > On Tue, Mar 11, 2014 at 9:41 AM, Radu Gheorghe > > <radu.gheor...@sematext.com>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 > >> <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. > >> > > _______________________________________________ > > 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.
