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.
