<div dir="ltr">The man page for gnutls_handshake certainly suggests it should handle a non-blocking socket.  I'd been wondering if somehow time_t was unsigned and rearranged some of the timeout calculations accordingly, but that hasn't changed behavior.  It looks to me like it is pacemaker_remoted that is choosing to drop the connection.<div>
<br></div><div style>But I have noticed that sometimes the remote resource fails before the VM has completely started up.  It might be helpful to have some sort of helper script that VirtualDomain resources can use in their monitor functions to verify that pacemaker_remoted is running, before the remote resource's connection timeout clock even starts running.  (But making the timeout longer doesn't help with the handshaking problem that happens later on.)</div>
<div style><br></div><div style>There have been a few segfaults of crmd during my testing of this, so perhaps there is a memory smash somewhere.  (A couple times the failure was at remote_lrmd_ra.c:186, and a resource cleanup on the remote resource sometimes triggers this.)</div>
<div style><br></div><div style>> I doubt this will make a difference, but here's the key I use during testing,</div><div style>> lrmd:ce9db0bc3cec583d3b3bf38b0ac9ff91</div><div style><br></div><div style>Wait, I thought you were creating a binary authkey file and not using a username with PSK authentication?</div>
<div style><br></div><div style>/Lindsay</div><div class="gmail_extra"><div><br></div><br><div class="gmail_quote">On Thu, May 16, 2013 at 6:47 PM, David Vossel <span dir="ltr"><<a href="mailto:dvossel@redhat.com" target="_blank">dvossel@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">----- Original Message -----<br>

> From: "Lindsay Todd" <<a href="mailto:rltodd.ml1@gmail.com">rltodd.ml1@gmail.com</a>><br>
> To: "The Pacemaker cluster resource manager" <<a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a>><br>
> Sent: Thursday, May 16, 2013 3:44:09 PM<br>
> Subject: [Pacemaker] pacemaker-remote tls handshaking<br>
><br>
> I've built pacemaker 1.1.10rc2 and am trying to get the pacemaker-remote<br>
> features working on my Scientific Linux 6.4 system. It almost works...<br>
><br>
> The /etc/pacemaker/authkey file is on all the cluster nodes, as well as my<br>
> test VM (readable to all users, and checksums are the same everywhere). I<br>
> can connect via telnet to port 3121 of the VM.<br>
><br>
> I even see the ghost node<br>
> appear for my VM when I use either 'crm status' or 'pcs status'. (Aside:<br>
> crmsh doesn't know about the new meta attributes for remote...)<br>
><br>
> But the communication isn't quite working. In my log I see:<br>
><br>
> May 16 15:58:34 cvmh04 crmd[4893]: warning: lrmd_tcp_connect_cb: Client tls<br>
> han<br>
> dshake failed for server swbuildsl6:3121. Disconnecting<br>
> May 16 15:58:34 swbuildsl6 pacemaker_remoted[2308]: error: lrmd_remote_client<br>
> _msg: Remote lrmd tls handshake failed<br>
> May 16 15:58:35 cvmh04 crmd[4893]: warning: lrmd_tcp_connect_cb: Client tls<br>
> han<br>
> dshake failed for server swbuildsl6:3121. Disconnecting<br>
> May 16 15:58:35 swbuildsl6 pacemaker_remoted[2308]: error: lrmd_remote_client<br>
> _msg: Remote lrmd tls handshake failed<br>
><br>
> and it isn't long before pacemaker stops trying.<br>
><br>
> Is there some additional configuration I need?<br>
<br>
</div></div>Ah, you dared to try my new feature, and this is what you get! :D<br>
<br>
It looks like you have it covered.  If you can telnet into the vm from the host (it should kick you off pretty quickly), then then all the firewall rules are correct. I'm not sure what is going on.  The only thing I can think of is perhaps your gnutls version doesn't like that I'm using a non-blocking socket during the tls handshake.<br>

<br>
I doubt this will make a difference, but here's the key I use during testing, lrmd:ce9db0bc3cec583d3b3bf38b0ac9ff91<br>
<br>
Has anyone else had success or ran into something similar yet?  I'll help investigate this next week. I'll be out of the office until Tuesday.<br>
<br>
-- Vossel<br>
<br>
> /Lindsay<br>
><br>
> _______________________________________________<br>
> Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
> <a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
><br>
> Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
> Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
> Bugs: <a href="http://bugs.clusterlabs.org" target="_blank">http://bugs.clusterlabs.org</a><br>
><br>
<br>
_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" target="_blank">http://bugs.clusterlabs.org</a><br>
</blockquote></div><br></div></div>