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? 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.
