From gordan at bobich.net  Mon Jul 26 17:57:51 2010
From: gordan at bobich.net (Gordan Bobic)
Date: Mon, 26 Jul 2010 16:57:51 +0100
Subject: [Csync2] csync2 without gnutls-openssl?
Message-ID: <1280159871.2668.30.camel@thinkpad>

It would appear that RHEL have, in their infinite wisdom, dropped
gnutls-openssl.so libraries from gnutls because there appears to be a
namespace clash somewhere:
https://bugzilla.redhat.com/show_bug.cgi?id=460310

RHEL6b2 has had these removed, and it seems the F13+ gnutls will be
having it removed, too.

Can csync2 developers suggest a reasonable long-term solution to this?
RH seem unwilling to consider unbreaking this:
https://bugzilla.redhat.com/show_bug.cgi?id=617558

Gordan


From dennis at schafroth.dk  Mon Jul 26 20:44:27 2010
From: dennis at schafroth.dk (Dennis Schafroth)
Date: Mon, 26 Jul 2010 20:44:27 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <1280159871.2668.30.camel@thinkpad>
References: <1280159871.2668.30.camel@thinkpad>
Message-ID: <B5E9C52B-EBA8-4735-BB38-C93319F80A1A@schafroth.dk>


I only know of the work-around to disable the usage with --disable-gnutls, but I guess, this isn't any good if you need secure connections.

cheers, 
Dennis 

On 26/07/2010, at 17.57, Gordan Bobic wrote:

> It would appear that RHEL have, in their infinite wisdom, dropped
> gnutls-openssl.so libraries from gnutls because there appears to be a
> namespace clash somewhere:
> https://bugzilla.redhat.com/show_bug.cgi?id=460310
> 
> RHEL6b2 has had these removed, and it seems the F13+ gnutls will be
> having it removed, too.
> 
> Can csync2 developers suggest a reasonable long-term solution to this?
> RH seem unwilling to consider unbreaking this:
> https://bugzilla.redhat.com/show_bug.cgi?id=617558
> 
> Gordan
> 
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2
> 


From gordan at bobich.net  Mon Jul 26 20:51:37 2010
From: gordan at bobich.net (Gordan Bobic)
Date: Mon, 26 Jul 2010 19:51:37 +0100
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <B5E9C52B-EBA8-4735-BB38-C93319F80A1A@schafroth.dk>
References: <1280159871.2668.30.camel@thinkpad>
	<B5E9C52B-EBA8-4735-BB38-C93319F80A1A@schafroth.dk>
Message-ID: <4C4DD939.6080404@bobich.net>

I don't really need secure connections, but I haven't been able to find 
any documentation on how to set up authentication without SSL. Can you 
point me in the right direction?

Gordan

Dennis Schafroth wrote:
> I only know of the work-around to disable the usage with --disable-gnutls, but I guess, this isn't any good if you need secure connections.
> 
> cheers, 
> Dennis 
> 
> On 26/07/2010, at 17.57, Gordan Bobic wrote:
> 
>> It would appear that RHEL have, in their infinite wisdom, dropped
>> gnutls-openssl.so libraries from gnutls because there appears to be a
>> namespace clash somewhere:
>> https://bugzilla.redhat.com/show_bug.cgi?id=460310
>>
>> RHEL6b2 has had these removed, and it seems the F13+ gnutls will be
>> having it removed, too.
>>
>> Can csync2 developers suggest a reasonable long-term solution to this?
>> RH seem unwilling to consider unbreaking this:
>> https://bugzilla.redhat.com/show_bug.cgi?id=617558
>>
>> Gordan
>>
>> _______________________________________________
>> Csync2 mailing list
>> Csync2 at lists.linbit.com
>> http://lists.linbit.com/mailman/listinfo/csync2
>>
> 


From Giampaolo at Tomassoni.biz  Mon Jul 26 23:17:43 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Mon, 26 Jul 2010 23:17:43 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <1280159871.2668.30.camel@thinkpad>
References: <1280159871.2668.30.camel@thinkpad>
Message-ID: <001801cb2d07$fd38a500$f7a9ef00$@biz>

> It would appear that RHEL have, in their infinite wisdom, dropped
> gnutls-openssl.so libraries from gnutls because there appears to be a
> namespace clash somewhere:
> https://bugzilla.redhat.com/show_bug.cgi?id=460310
> 
> RHEL6b2 has had these removed, and it seems the F13+ gnutls will be
> having it removed, too.
> 
> Can csync2 developers suggest a reasonable long-term solution to this?
> RH seem unwilling to consider unbreaking this:
> https://bugzilla.redhat.com/show_bug.cgi?id=617558

I dropped my own dirty patch to this ng some months ago (sometime aroung
november 2009), but it seems it didn't (yet) find its way to the csync2
official code.

You may eventually get a copy of the patch here:

	http://bugs.gentoo.org/attachment.cgi?id=210768

which is an attachment from Gentoo bug#274213
(http://bugs.gentoo.org/show_bug.cgi?id=274213).

The patch basically "discards" all the gnutls-openssl mess and gets straight
to gnutls native mode. This also *may* mean that one can expect some
interoperability issues after upgrade, because of a *possible* different
handling of the chain-of-trust in server and client certificates between
gnutls-openssl calls and gnutls ones. Anyway, I have no report of this at
the time.
 
Please note the patch is big because it also patches "configure" and
autoconf files. The "raw" patch is instead really small.

Giampaolo


> 
> Gordan
> 
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2


From tserong at novell.com  Tue Jul 27 03:35:59 2010
From: tserong at novell.com (Tim Serong)
Date: Mon, 26 Jul 2010 19:35:59 -0600
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <001801cb2d07$fd38a500$f7a9ef00$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
Message-ID: <4C4EC49F0200000A00019285@novprvlin0050.provo.novell.com>

On 7/27/2010 at 07:17 AM, "Giampaolo Tomassoni" <Giampaolo at Tomassoni.biz> wrote: 
> would appear that RHEL have, in their infinite wisdom, dropped 
> > gnutls-openssl.so libraries from gnutls because there appears to be a 
> > namespace clash somewhere: 
> > https://bugzilla.redhat.com/show_bug.cgi?id=460310 
> >  
> > RHEL6b2 has had these removed, and it seems the F13+ gnutls will be 
> > having it removed, too. 
> >  
> > Can csync2 developers suggest a reasonable long-term solution to this? 
> > RH seem unwilling to consider unbreaking this: 
> > https://bugzilla.redhat.com/show_bug.cgi?id=617558 
>  
> I dropped my own dirty patch to this ng some months ago (sometime aroung 
> november 2009), but it seems it didn't (yet) find its way to the csync2 
> official code. 
>  
> You may eventually get a copy of the patch here: 
>  
> 	http://bugs.gentoo.org/attachment.cgi?id=210768 
>  
> which is an attachment from Gentoo bug#274213 
> (http://bugs.gentoo.org/show_bug.cgi?id=274213). 
>  
> The patch basically "discards" all the gnutls-openssl mess and gets straight 
> to gnutls native mode. This also *may* mean that one can expect some 
> interoperability issues after upgrade, because of a *possible* different 
> handling of the chain-of-trust in server and client certificates between 
> gnutls-openssl calls and gnutls ones. Anyway, I have no report of this at 
> the time. 
>   
> Please note the patch is big because it also patches "configure" and 
> autoconf files. The "raw" patch is instead really small. 

This patch is in csync2 in openSUSE 11.3 (csync2-1.34-pure-gnutls-r2.patch):

https://build.opensuse.org/package/files?package=csync2&project=openSUSE:11.3

I assume it shouldn't be too difficult for someone to take this and push it
into FC.

HTH,

Tim


-- 
Tim Serong <tserong at novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.




From dennis at schafroth.dk  Tue Jul 27 08:31:47 2010
From: dennis at schafroth.dk (Dennis Schafroth)
Date: Tue, 27 Jul 2010 08:31:47 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <4C4DD939.6080404@bobich.net>
References: <1280159871.2668.30.camel@thinkpad>
	<B5E9C52B-EBA8-4735-BB38-C93319F80A1A@schafroth.dk>
	<4C4DD939.6080404@bobich.net>
Message-ID: <48DD3318-D601-4D94-9ABC-61C712418BC2@schafroth.dk>


My settup is as follow. Using the global configuration nossl, which means that nothing is encrypted on the wire. I am running behind a firewall and dont have (bad) users that could listen on  on the data:

nossl *.schafroth.dk *.schafroth.dk;

group server_config 
{
   host bluebox0.schafroth.dk applebook.schafroth.dk blackbox3.schafroth.dk;
   key /etc/csync2.key;
....

Authorization is done by the key file, that must be in place on all machines before running. 

cheers, 
;-Dennis

On 26/07/2010, at 20.51, Gordan Bobic wrote:

> I don't really need secure connections, but I haven't been able to find any documentation on how to set up authentication without SSL. Can you point me in the right direction?
> 
> Gordan
> 
> Dennis Schafroth wrote:
>> I only know of the work-around to disable the usage with --disable-gnutls, but I guess, this isn't any good if you need secure connections.
>> cheers, Dennis On 26/07/2010, at 17.57, Gordan Bobic wrote:
>>> It would appear that RHEL have, in their infinite wisdom, dropped
>>> gnutls-openssl.so libraries from gnutls because there appears to be a
>>> namespace clash somewhere:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=460310
>>> 
>>> RHEL6b2 has had these removed, and it seems the F13+ gnutls will be
>>> having it removed, too.
>>> 
>>> Can csync2 developers suggest a reasonable long-term solution to this?
>>> RH seem unwilling to consider unbreaking this:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=617558
>>> 
>>> Gordan
>>> 
>>> _______________________________________________
>>> Csync2 mailing list
>>> Csync2 at lists.linbit.com
>>> http://lists.linbit.com/mailman/listinfo/csync2
>>> 
> 
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2
> 


From Giampaolo at Tomassoni.biz  Tue Jul 27 09:48:48 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Tue, 27 Jul 2010 09:48:48 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <4C4EC49F0200000A00019285@novprvlin0050.provo.novell.com>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<4C4EC49F0200000A00019285@novprvlin0050.provo.novell.com>
Message-ID: <000301cb2d60$25f3b4f0$71db1ed0$@biz>

> This patch is in csync2 in openSUSE 11.3 (csync2-1.34-pure-gnutls-
> r2.patch):
> 
> https://build.opensuse.org/package/files?package=csync2&project=openSUS
> E:11.3
> 
> I assume it shouldn't be too difficult for someone to take this and
> push it
> into FC.
> 
> HTH,
> 
> Tim

It seems to me the very same patch, only in a different format.

So, it is fine to use this too.

Giampaolo


From tserong at novell.com  Tue Jul 27 09:59:39 2010
From: tserong at novell.com (Tim Serong)
Date: Tue, 27 Jul 2010 01:59:39 -0600
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <000301cb2d60$25f3b4f0$71db1ed0$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<4C4EC49F0200000A00019285@novprvlin0050.provo.novell.com>
	<000301cb2d60$25f3b4f0$71db1ed0$@biz>
Message-ID: <4C4F1E8B0200000A00019324@novprvlin0050.provo.novell.com>

On 7/27/2010 at 05:48 PM, "Giampaolo Tomassoni" <Giampaolo at Tomassoni.biz> wrote: 
> This patch is in csync2 in openSUSE 11.3 (csync2-1.34-pure-gnutls- 
> > r2.patch): 
> >  
> > https://build.opensuse.org/package/files?package=csync2&project=openSUS 
> > E:11.3 
> >  
> > I assume it shouldn't be too difficult for someone to take this and 
> > push it 
> > into FC. 
> >  
> > HTH, 
> >  
> > Tim 
>  
> It seems to me the very same patch, only in a different format. 

Yep, same patch (possibly I didn't state that clearly originally,
sorry :))

Regards,

Tim


-- 
Tim Serong <tserong at novell.com>
Senior Clustering Engineer, OPS Engineering, Novell Inc.




From lars.ellenberg at linbit.com  Tue Jul 27 14:26:01 2010
From: lars.ellenberg at linbit.com (Lars Ellenberg)
Date: Tue, 27 Jul 2010 14:26:01 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <001801cb2d07$fd38a500$f7a9ef00$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
Message-ID: <20100727122601.GC25769@barkeeper1-xen.linbit>

On Mon, Jul 26, 2010 at 11:17:43PM +0200, Giampaolo Tomassoni wrote:
> > It would appear that RHEL have, in their infinite wisdom, dropped
> > gnutls-openssl.so libraries from gnutls because there appears to be a
> > namespace clash somewhere:
> > https://bugzilla.redhat.com/show_bug.cgi?id=460310
> > 
> > RHEL6b2 has had these removed, and it seems the F13+ gnutls will be
> > having it removed, too.
> > 
> > Can csync2 developers suggest a reasonable long-term solution to this?
> > RH seem unwilling to consider unbreaking this:
> > https://bugzilla.redhat.com/show_bug.cgi?id=617558
> 
> I dropped my own dirty patch to this ng some months ago (sometime aroung
> november 2009), but it seems it didn't (yet) find its way to the csync2
> official code.

Did you post to this ML, too?

> You may eventually get a copy of the patch here:
> 
> 	http://bugs.gentoo.org/attachment.cgi?id=210768
> 
> which is an attachment from Gentoo bug#274213
> (http://bugs.gentoo.org/show_bug.cgi?id=274213).

I'll push it into csync2 svn.

> The patch basically "discards" all the gnutls-openssl mess and gets straight
> to gnutls native mode. This also *may* mean that one can expect some
> interoperability issues after upgrade, because of a *possible* different
> handling of the chain-of-trust in server and client certificates between
> gnutls-openssl calls and gnutls ones. Anyway, I have no report of this at
> the time.

Chain of trust is sort-of ignored, anyways, by csync2 :(

IIRC, on _first_ connect of two hosts, it is checked, don't know in what
depth, and the fingerprint of the cert is stored in some sqlite table.
Once that (fingerprint, hostname) tuple is there, the certificates are no
longer checked for anything but for matching that fingerprint, hostname.

BTW, we are toying around with an "ssh-tunnel mode".
Some preparation has been done, but it is not quite ready yet.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD? and LINBIT? are registered trademarks of LINBIT, Austria.

From Giampaolo at Tomassoni.biz  Tue Jul 27 15:34:34 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Tue, 27 Jul 2010 15:34:34 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <20100727122601.GC25769@barkeeper1-xen.linbit>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<20100727122601.GC25769@barkeeper1-xen.linbit>
Message-ID: <001b01cb2d90$73cf7f30$5b6e7d90$@biz>

> > I dropped my own dirty patch to this ng some months ago (sometime
> > aroung november 2009), but it seems it didn't (yet) find its way
> > to the csync2 official code.
> 
> Did you post to this ML, too?

Sorry, I meant the ML, of course. Yes, I did. However, it was not exactly
the version you may get from Gentoo or OpenSuSE, because some problems were
fixed in the meantime, thanks to some Gentoo folks.


> I'll push it into csync2 svn.

Great. Thank you.


> Chain of trust is sort-of ignored, anyways, by csync2 :(

You're right. However, the main problem here is that the server *and* the
client certificate must be issued by the same CA in order for a gnutls
server to get the peer's certificate. I didn't yet get any report about this
issue I *guess* because most people creates its own self-signed certificate
and then uses it in every node in its csync2 net. If both certificates are
the same, they are of course issued by the same CA and then the server
receives the client one.

Again, I *guess* this is because, during ssl setup in csycn2, gnutls is
configured to accept only the CA signing the server certificate itself.
However, I don't know if gnutls-openssl or even openssl avails some external
mean to trust a CA, such that even a client certificate issued by a
different CA then the one signing the server certificate would be accepted.
Nor I know if a gnutls-openssl or plain openssl server/client would transmit
the client certificate irrespective of its reputability.


> IIRC, on _first_ connect of two hosts, it is checked, don't know in
> what depth

Using gnutls, it needs to be signed by the same CA of the server certificate
(which means it can also be the very same self-signed certificate used by
the server). Donno if gnutls-openssl was loose in this.


> , and the fingerprint of the cert is stored in some sqlite
> table.

The fingerprint didn't seem enough when that code was written: it is the
*whole* client certificate to be stored in the db...


> Once that (fingerprint, hostname) tuple is there, the certificates are
> no longer checked for anything but for matching that fingerprint,
> hostname.

Right, apart "that fingerprint" is instead "that whole certificate".


> BTW, we are toying around with an "ssh-tunnel mode".
> Some preparation has been done, but it is not quite ready yet.

This is a good new, since something like this will finally throw all this
ssl mess away.


Giampaolo

> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.


From lars.ellenberg at linbit.com  Tue Jul 27 16:08:04 2010
From: lars.ellenberg at linbit.com (Lars Ellenberg)
Date: Tue, 27 Jul 2010 16:08:04 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <001b01cb2d90$73cf7f30$5b6e7d90$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<20100727122601.GC25769@barkeeper1-xen.linbit>
	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>
Message-ID: <20100727140804.GE25769@barkeeper1-xen.linbit>

On Tue, Jul 27, 2010 at 03:34:34PM +0200, Giampaolo Tomassoni wrote:
> > > I dropped my own dirty patch to this ng some months ago (sometime
> > > aroung november 2009), but it seems it didn't (yet) find its way
> > > to the csync2 official code.
> > 
> > Did you post to this ML, too?
> 
> Sorry, I meant the ML, of course. Yes, I did. However, it was not exactly
> the version you may get from Gentoo or OpenSuSE, because some problems were
> fixed in the meantime, thanks to some Gentoo folks.

Ah. Right. Found that thread.
Apparently it dropped from my todo list at that time.

> > I'll push it into csync2 svn.
> 
> Great. Thank you.

Please verify svn revision 422.

... hm ... should change that to git ... someday ...

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD? and LINBIT? are registered trademarks of LINBIT, Austria.

From Giampaolo at Tomassoni.biz  Wed Jul 28 00:28:54 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Wed, 28 Jul 2010 00:28:54 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <20100727140804.GE25769@barkeeper1-xen.linbit>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>	<20100727122601.GC25769@barkeeper1-xen.linbit>	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>
	<20100727140804.GE25769@barkeeper1-xen.linbit>
Message-ID: <002801cb2ddb$18f9e870$4aedb950$@biz>

> Please verify svn revision 422.

I had a quick look at it.

While the code seems fine to me, I was unable to successfully build the
configure script via the autogen.sh one. This script was reporting a
reference to the missing m4 function AM_PATH_LIBGNUTLS. I'm submitting a
patch which supplies the needed m4/libgnutls.m4 file and patches autogen.sh
accordingly.

Please note the m4/libgnutls.m4 file shipped with the patch is a modified
version of the one you may otherwise find in the 'net, since the latter is
unable to detect latest versions of libgnutls because they don't ship a
gnutls-config file anymore.

Also, the patch changes the AC_MSG_ERROR text from configure.ac issued when
a suitable libgnutls is missing in the hosting system. The old one was
misleading since it was suggesting to install gnutls-openssl too.


> ... hm ... should change that to git ... someday ...

:)


Giampaolo

> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csync2-head+libgnutlsm4.patch
Type: application/octet-stream
Size: 8190 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/csync2/attachments/20100728/45567dbf/attachment.obj>

From lars.ellenberg at linbit.com  Wed Jul 28 14:03:25 2010
From: lars.ellenberg at linbit.com (Lars Ellenberg)
Date: Wed, 28 Jul 2010 14:03:25 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <002801cb2ddb$18f9e870$4aedb950$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<20100727122601.GC25769@barkeeper1-xen.linbit>
	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>
	<20100727140804.GE25769@barkeeper1-xen.linbit>
	<002801cb2ddb$18f9e870$4aedb950$@biz>
Message-ID: <20100728120325.GB3895@barkeeper1-xen.linbit>

On Wed, Jul 28, 2010 at 12:28:54AM +0200, Giampaolo Tomassoni wrote:
> > Please verify svn revision 422.
> 
> I had a quick look at it.
> 
> While the code seems fine to me, I was unable to successfully build the
> configure script via the autogen.sh one. This script was reporting a
> reference to the missing m4 function AM_PATH_LIBGNUTLS. I'm submitting a
> patch which supplies the needed m4/libgnutls.m4 file and patches autogen.sh
> accordingly.

That is probably due to gnutls having changed to pkg-config.
Please rather patch configure.ac to use pkg-config than
go back to m4.


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD? and LINBIT? are registered trademarks of LINBIT, Austria.

From Giampaolo at Tomassoni.biz  Wed Jul 28 14:35:41 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Wed, 28 Jul 2010 14:35:41 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <20100728120325.GB3895@barkeeper1-xen.linbit>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>	<20100727122601.GC25769@barkeeper1-xen.linbit>	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>	<20100727140804.GE25769@barkeeper1-xen.linbit>	<002801cb2ddb$18f9e870$4aedb950$@biz>
	<20100728120325.GB3895@barkeeper1-xen.linbit>
Message-ID: <002c01cb2e51$649c1390$2dd43ab0$@biz>

> That is probably due to gnutls having changed to pkg-config.
> Please rather patch configure.ac to use pkg-config than
> go back to m4.

Lars, AM_PATH_LIBGNUTLS was completely undefined, so the
pkg-config/gnutls-config isn't that much relevant with respect to the
autogen.sh failure.

In the patch shipped with my previous message, the m4/libgnutls.m4 file was
exactly meant to define the missing macro. Besides, that macro attempts
finding libgnutls both via the old way (gnutls-config) and the new one
(pkg-config), thereby even allowing to link against a quaint version of that
library.

Do you perhaps mean you prefer to have the AM_PATH_LIBGNUTLS AC_DEFUN[]
stuff directly into configure.ac, instead of having it in the
m4/libgnutls.m4 file?

Giampaolo


> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.


From lars.ellenberg at linbit.com  Wed Jul 28 14:48:44 2010
From: lars.ellenberg at linbit.com (Lars Ellenberg)
Date: Wed, 28 Jul 2010 14:48:44 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <002c01cb2e51$649c1390$2dd43ab0$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<20100727122601.GC25769@barkeeper1-xen.linbit>
	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>
	<20100727140804.GE25769@barkeeper1-xen.linbit>
	<002801cb2ddb$18f9e870$4aedb950$@biz>
	<20100728120325.GB3895@barkeeper1-xen.linbit>
	<002c01cb2e51$649c1390$2dd43ab0$@biz>
Message-ID: <20100728124844.GD3895@barkeeper1-xen.linbit>

On Wed, Jul 28, 2010 at 02:35:41PM +0200, Giampaolo Tomassoni wrote:
> > That is probably due to gnutls having changed to pkg-config.
> > Please rather patch configure.ac to use pkg-config than
> > go back to m4.
> 
> Lars, AM_PATH_LIBGNUTLS was completely undefined, so the
> pkg-config/gnutls-config isn't that much relevant with respect to the
> autogen.sh failure.

Yes, it is undefined, because it should be (or used to be) in the dev
package of libgnutls, but no longer is, because they apparently decided
they had a better approach.

> In the patch shipped with my previous message, the m4/libgnutls.m4 file was
> exactly meant to define the missing macro.

Yes.
And your patch even fixes a build breakage.
So it is good.
Only it seems to be not what libgnutls upstream seems to want.
So I figured, if you already hacking there anyways, maybe just do it the
way gnutls upstream feels would be the right way.

> Do you perhaps mean you prefer to have the AM_PATH_LIBGNUTLS AC_DEFUN[]
> stuff directly into configure.ac, instead of having it in the
> m4/libgnutls.m4 file?

I don't care either way. But if gnutls still things this macro should be
how autofoo should be done, then they should package it themselves,
just as it used to be. Or we should do whatever they feel is the right
way to gnutls autofoo integration now.

It cannot possibly be their intention that any libgnutls user should
have its own private copy of libgnutls.m4.

Am I misunderstanding something?

Is this just a packaging error of libgnutls?

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD? and LINBIT? are registered trademarks of LINBIT, Austria.

From lars.ellenberg at linbit.com  Wed Jul 28 15:46:52 2010
From: lars.ellenberg at linbit.com (Lars Ellenberg)
Date: Wed, 28 Jul 2010 15:46:52 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <20100728124844.GD3895@barkeeper1-xen.linbit>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<20100727122601.GC25769@barkeeper1-xen.linbit>
	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>
	<20100727140804.GE25769@barkeeper1-xen.linbit>
	<002801cb2ddb$18f9e870$4aedb950$@biz>
	<20100728120325.GB3895@barkeeper1-xen.linbit>
	<002c01cb2e51$649c1390$2dd43ab0$@biz>
	<20100728124844.GD3895@barkeeper1-xen.linbit>
Message-ID: <20100728134652.GE3895@barkeeper1-xen.linbit>

On Wed, Jul 28, 2010 at 02:48:44PM +0200, Lars Ellenberg wrote:
> On Wed, Jul 28, 2010 at 02:35:41PM +0200, Giampaolo Tomassoni wrote:
> > > That is probably due to gnutls having changed to pkg-config.
> > > Please rather patch configure.ac to use pkg-config than
> > > go back to m4.
> > 
> > Lars, AM_PATH_LIBGNUTLS was completely undefined, so the
> > pkg-config/gnutls-config isn't that much relevant with respect to the
> > autogen.sh failure.
> 
> Yes, it is undefined, because it should be (or used to be) in the dev
> package of libgnutls, but no longer is, because they apparently decided
> they had a better approach.
> It cannot possibly be their intention that any libgnutls user should
> have its own private copy of libgnutls.m4.

And it is not.

Apparently for pkg-config things, the autofoo way is:

- AM_PATH_LIBGNUTLS
+ PKG_CHECK_MODULES

please confirm.

diff --git a/configure.ac b/configure.ac
index a3ef7ee..30f758c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -78,7 +78,7 @@ AC_ARG_ENABLE([gnutls],
 if test "$enable_gnutls" != no
 then
 	# Check for gnuTLS.
-	AM_PATH_LIBGNUTLS(1.0.0, , [ AC_MSG_ERROR([[gnutls not found; install gnutls, gnutls-openssl and libtasn1 packages for your system or run configure with --disable-gnutls]]) ])
+	PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= 2.0.4,,AC_MSG_ERROR([[gnutls not found; install gnutls and libtasn1 packages for your system or run configure with --disable-gnutls]]))
 
 	## This is a bloody hack for fedora core
 	CFLAGS="$CFLAGS $LIBGNUTLS_CFLAGS"

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD? and LINBIT? are registered trademarks of LINBIT, Austria.

From Giampaolo at Tomassoni.biz  Wed Jul 28 16:47:51 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Wed, 28 Jul 2010 16:47:51 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <20100728124844.GD3895@barkeeper1-xen.linbit>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>	<20100727122601.GC25769@barkeeper1-xen.linbit>	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>	<20100727140804.GE25769@barkeeper1-xen.linbit>	<002801cb2ddb$18f9e870$4aedb950$@biz>	<20100728120325.GB3895@barkeeper1-xen.linbit>	<002c01cb2e51$649c1390$2dd43ab0$@biz>
	<20100728124844.GD3895@barkeeper1-xen.linbit>
Message-ID: <003b01cb2e63$dac3b4d0$904b1e70$@biz>

> > Lars, AM_PATH_LIBGNUTLS was completely undefined, so the
> > pkg-config/gnutls-config isn't that much relevant with respect to the
> > autogen.sh failure.
> 
> Yes, it is undefined, because it should be (or used to be) in the dev
> package of libgnutls, but no longer is, because they apparently decided
> they had a better approach.

It seems to me they simply discontinued support of that m4 macro.


> > In the patch shipped with my previous message, the m4/libgnutls.m4
> file was
> > exactly meant to define the missing macro.
> 
> Yes.
> And your patch even fixes a build breakage.
> So it is good.
> Only it seems to be not what libgnutls upstream seems to want.
> So I figured, if you already hacking there anyways, maybe just do it
> the
> way gnutls upstream feels would be the right way.

I probably miss the why you think they like a somehow different way of
detecting their lib.

Do you have any reference, url or whatsoever about it?


> > Do you perhaps mean you prefer to have the AM_PATH_LIBGNUTLS
> AC_DEFUN[]
> > stuff directly into configure.ac, instead of having it in the
> > m4/libgnutls.m4 file?
> 
> I don't care either way. But if gnutls still things this macro should
> be
> how autofoo should be done, then they should package it themselves,
> just as it used to be. Or we should do whatever they feel is the right
> way to gnutls autofoo integration now.
> 
> It cannot possibly be their intention that any libgnutls user should
> have its own private copy of libgnutls.m4.
> 
> Am I misunderstanding something?

Well, I really don't know. I however see that most libraries don't ship
their own way of detecting themselves: most of the times m4 detection macros
have to be "shamelessly stolen" and/or handcrafted from some other package.

I guess the problem is that detection macros need often to be tuned for the
specific needs of the package using them, not only for the one offering the
feature.


> Is this just a packaging error of libgnutls?

I think they switched to pkg-config and they supposed that the "stock"
PKG_CHECK_MODULES was then enough to detect their package.

So, you may use the PKG_CHECK_MODULES macro offered by the pkg-config
package. Which means you have to put a copy of the pkg.m4 file into the m4/
dir of the csync2 package. Unfortunately, there possibly is people running
systems with a pre-2.8.x version of libgnutls, or even with no pkg-config
support. If you go straight with a pkg-config -only solution you're going to
cut 'em out.

Isn't it easier to ship the m4/libgnutls.m4 script, which covers both the
pkg-config and gnutls-config cases, instead of the m4/pkg.m4 one, which only
covers the first one?

Giampaolo


> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBDR and LINBITR are registered trademarks of LINBIT, Austria.


From lars.ellenberg at linbit.com  Wed Jul 28 18:58:50 2010
From: lars.ellenberg at linbit.com (Lars Ellenberg)
Date: Wed, 28 Jul 2010 18:58:50 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <003b01cb2e63$dac3b4d0$904b1e70$@biz>
References: <1280159871.2668.30.camel@thinkpad>
	<001801cb2d07$fd38a500$f7a9ef00$@biz>
	<20100727122601.GC25769@barkeeper1-xen.linbit>
	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>
	<20100727140804.GE25769@barkeeper1-xen.linbit>
	<002801cb2ddb$18f9e870$4aedb950$@biz>
	<20100728120325.GB3895@barkeeper1-xen.linbit>
	<002c01cb2e51$649c1390$2dd43ab0$@biz>
	<20100728124844.GD3895@barkeeper1-xen.linbit>
	<003b01cb2e63$dac3b4d0$904b1e70$@biz>
Message-ID: <20100728165850.GG3895@barkeeper1-xen.linbit>

On Wed, Jul 28, 2010 at 04:47:51PM +0200, Giampaolo Tomassoni wrote:
> > > Lars, AM_PATH_LIBGNUTLS was completely undefined, so the
> > > pkg-config/gnutls-config isn't that much relevant with respect to the
> > > autogen.sh failure.
> > 
> > Yes, it is undefined, because it should be (or used to be) in the dev
> > package of libgnutls, but no longer is, because they apparently decided
> > they had a better approach.
> 
> It seems to me they simply discontinued support of that m4 macro.

That's what I meant.
They ship a .pc since at least 1.4.
They dropped the .m4 with 2.8 (or so).

> I think they switched to pkg-config and they supposed that the "stock"
> PKG_CHECK_MODULES was then enough to detect their package.

It is.

> So, you may use the PKG_CHECK_MODULES macro offered by the pkg-config
> package. Which means you have to put a copy of the pkg.m4 file into the m4/
> dir of the csync2 package.

No, I would not. Nothing of that is in version control.
In release tarball, configure would be provided (all macros expanded).

If someone insists on building from scratch using autofoo,
he is supposed to have an autofoo capable environment, where pkg.m4
would reside in /usr/share/aclocal/pkg.m4 (or where ever it belongs).

> Unfortunately, there possibly is people running
> systems with a pre-2.8.x version of libgnutls,

pre 1.4 ?

> or even with no pkg-config support.

Is that so.

> If you go straight with a pkg-config -only solution you're going to
> cut 'em out.

I don't really care for debian potato anymore.

> Isn't it easier to ship the m4/libgnutls.m4 script, which covers both
> the pkg-config and gnutls-config cases, instead of the m4/pkg.m4 one,
> which only covers the first one?

Isn't it easier to rely on whatever libgnutls-dev ships
for integration with autofoo.

I don't like to include compatibility cruft just because we can,
or adding new files to version control if a one-line diff would be
sufficient.

Anyways, if you insist, how about:

diff --git a/configure.ac b/configure.ac
index a3ef7ee..3aa600c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -78,7 +78,14 @@ AC_ARG_ENABLE([gnutls],
 if test "$enable_gnutls" != no
 then
 	# Check for gnuTLS.
-	AM_PATH_LIBGNUTLS(1.0.0, , [ AC_MSG_ERROR([[gnutls not found; install gnutls, gnutls-openssl and libtasn1 packages for your system or run configure with --disable-gnutls]]) ])
+	PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= 1.0.0,, [
+		ifdef([AM_PATH_LIBGNUTLS],
+			[AM_PATH_LIBGNUTLS(1.0.0, , AC_MSG_ERROR([[gnutls not found; install gnutls and libtasn1 packages for your system or run configure with --disable-gnutls]]))],
+			[AC_MSG_ERROR([
+***  Neither pkg-config nor older .m4 macros found for libgnutls.
+***  Install libgnutls development packages and rerun autogen.sh,
+***  or --disable-gnutls])])
+	])
 
 	## This is a bloody hack for fedora core
 	CFLAGS="$CFLAGS $LIBGNUTLS_CFLAGS"

From Giampaolo at Tomassoni.biz  Thu Jul 29 01:06:44 2010
From: Giampaolo at Tomassoni.biz (Giampaolo Tomassoni)
Date: Thu, 29 Jul 2010 01:06:44 +0200
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <20100728165850.GG3895@barkeeper1-xen.linbit>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>	<20100727122601.GC25769@barkeeper1-xen.linbit>	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>	<20100727140804.GE25769@barkeeper1-xen.linbit>	<002801cb2ddb$18f9e870$4aedb950$@biz>	<20100728120325.GB3895@barkeeper1-xen.linbit>	<002c01cb2e51$649c1390$2dd43ab0$@biz>	<20100728124844.GD3895@barkeeper1-xen.linbit>	<003b01cb2e63$dac3b4d0$904b1e70$@biz>
	<20100728165850.GG3895@barkeeper1-xen.linbit>
Message-ID: <000401cb2ea9$8c6a2b70$a53e8250$@biz>

> Isn't it easier to rely on whatever libgnutls-dev ships
> for integration with autofoo.
> 
> I don't like to include compatibility cruft just because we can,
> or adding new files to version control if a one-line diff would be
> sufficient.
> 
> Anyways, if you insist, how about:
> 
> diff --git a/configure.ac b/configure.ac
> index a3ef7ee..3aa600c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -78,7 +78,14 @@ AC_ARG_ENABLE([gnutls],
>  if test "$enable_gnutls" != no
>  then
>  	# Check for gnuTLS.
> -	AM_PATH_LIBGNUTLS(1.0.0, , [ AC_MSG_ERROR([[gnutls not found;
> install gnutls, gnutls-openssl and libtasn1 packages for your system or
> run configure with --disable-gnutls]]) ])
> +	PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= 1.0.0,, [
> +		ifdef([AM_PATH_LIBGNUTLS],
> +			[AM_PATH_LIBGNUTLS(1.0.0, , AC_MSG_ERROR([[gnutls
not
> found; install gnutls and libtasn1 packages for your system or run
> configure with --disable-gnutls]]))],
> +			[AC_MSG_ERROR([
> +***  Neither pkg-config nor older .m4 macros found for libgnutls.
> +***  Install libgnutls development packages and rerun autogen.sh,
> +***  or --disable-gnutls])])
> +	])

This is fine to me: most of the stuff in the libgnutls.m4 I dropped to this
list was from the gnutls project. Nevertheless, I too believe it was a bit
pedantic in checking libgnutls usability...

Your solution seems clever to me.

I don't agree with you to not have a copy of m4/pkg.m4 and/or
m4/libgnutls.m4. But I don't even agree with the gnutls project shipping
macros named AM_PATH_LIBGNUTLS (the AM_ prefix is misleading: it is not a
macro supplied by automake...). So, after all this is not important as long
as csync2 comes out with a working "configure" script: it is a matter of
taste at best...

+1 for me

Giampaolo


>  	## This is a bloody hack for fedora core
>  	CFLAGS="$CFLAGS $LIBGNUTLS_CFLAGS"


From mic at npgx.com.au  Thu Jul 29 02:31:30 2010
From: mic at npgx.com.au (Michael Mansour)
Date: Thu, 29 Jul 2010 11:31:30 +1100
Subject: [Csync2] csync2 without gnutls-openssl?
In-Reply-To: <000401cb2ea9$8c6a2b70$a53e8250$@biz>
References: <1280159871.2668.30.camel@thinkpad>	<001801cb2d07$fd38a500$f7a9ef00$@biz>	<20100727122601.GC25769@barkeeper1-xen.linbit>	<001b01cb2d90$73cf7f30$5b6e7d90$@biz>	<20100727140804.GE25769@barkeeper1-xen.linbit>	<002801cb2ddb$18f9e870$4aedb950$@biz>	<20100728120325.GB3895@barkeeper1-xen.linbit>	<002c01cb2e51$649c1390$2dd43ab0$@biz>	<20100728124844.GD3895@barkeeper1-xen.linbit>	<003b01cb2e63$dac3b4d0$904b1e70$@biz>
	<20100728165850.GG3895@barkeeper1-xen.linbit>
	<000401cb2ea9$8c6a2b70$a53e8250$@biz>
Message-ID: <20100729002752.M28644@npgx.com.au>

Hi,

Can someone produce (or has someone produced) RHEL 5-compatible csync2 RPM's
with these patches?

That has been one of the hardest things for me over the years to maintain with
csync2. I make my own RPM's but since RH have performed their updates some of
the csync2 clusters have broken (segmentation faults) and I've tried to fix
them, but can't.

Having a repository storing csync2 RPM's somewhere in the world, whether that
be with openssl or not, would be a nice to have.

Regards,

Michael.

> > Isn't it easier to rely on whatever libgnutls-dev ships
> > for integration with autofoo.
> > 
> > I don't like to include compatibility cruft just because we can,
> > or adding new files to version control if a one-line diff would be
> > sufficient.
> > 
> > Anyways, if you insist, how about:
> > 
> > diff --git a/configure.ac b/configure.ac
> > index a3ef7ee..3aa600c 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -78,7 +78,14 @@ AC_ARG_ENABLE([gnutls],
> >  if test "$enable_gnutls" != no
> >  then
> >  	# Check for gnuTLS.
> > -	AM_PATH_LIBGNUTLS(1.0.0, , [ AC_MSG_ERROR([[gnutls not found;
> > install gnutls, gnutls-openssl and libtasn1 packages for your system or
> > run configure with --disable-gnutls]]) ])
> > +	PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= 1.0.0,, [
> > +		ifdef([AM_PATH_LIBGNUTLS],
> > +			[AM_PATH_LIBGNUTLS(1.0.0, , AC_MSG_ERROR([[gnutls
> not
> > found; install gnutls and libtasn1 packages for your system or run
> > configure with --disable-gnutls]]))],
> > +			[AC_MSG_ERROR([
> > +***  Neither pkg-config nor older .m4 macros found for libgnutls.
> > +***  Install libgnutls development packages and rerun autogen.sh,
> > +***  or --disable-gnutls])])
> > +	])
> 
> This is fine to me: most of the stuff in the libgnutls.m4 I dropped 
> to this list was from the gnutls project. Nevertheless, I too 
> believe it was a bit pedantic in checking libgnutls usability...
> 
> Your solution seems clever to me.
> 
> I don't agree with you to not have a copy of m4/pkg.m4 and/or
> m4/libgnutls.m4. But I don't even agree with the gnutls project shipping
> macros named AM_PATH_LIBGNUTLS (the AM_ prefix is misleading: it is 
> not a macro supplied by automake...). So, after all this is not 
> important as long as csync2 comes out with a working "configure" 
> script: it is a matter of taste at best...
> 
> +1 for me
> 
> Giampaolo
> 
> >  	## This is a bloody hack for fedora core
> >  	CFLAGS="$CFLAGS $LIBGNUTLS_CFLAGS"
> 
> _______________________________________________
> Csync2 mailing list
> Csync2 at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/csync2
------- End of Original Message -------


