I started to investigate the issue [1] and it seems like there is an issue in Lago setup we use.
During handshake we have a step to verify whether client certificate was issued for a specific host (no such functionality in m2crytpo code base). It works fine when using either ip addresses or fqdns but in this
Nadav, Yes, vdsm is not able to resolve 'engine' which is used in engine's certificate. Thanks, Piotr 29 kwi 2017 00:37 "Nadav Goldin" <ngoldin@redhat.com> napisał(a): Hi Piotr, Can you clarify what you noticed is not resolvable - the 'engine' FQDN from host0? Thanks, Nadav. On Fri, Apr 28, 2017 at 4:15 PM, Piotr Kliczewski <pkliczew@redhat.com> wrote: particular
setup we use mixed.
When added logging I see that in engine certificate we use 'engine' name which is not resolvable on the host side and the check fails. I posted a patch [2] which fixes IPv4 mapped addresses issue but we need to fix the setup issue.
Thanks, Piotr
[1] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/326/ [2] https://gerrit.ovirt.org/#/c/76197/
On Thu, Apr 27, 2017 at 3:39 PM, Piotr Kliczewski <pkliczew@redhat.com> wrote:
On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin <ederevea@redhat.com> wrote:
Test failed: 002_bootstrap/add_hosts
Link to suspected patches: https://gerrit.ovirt.org/76107 - ssl: change default library
Link to job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6491/
VDSM log:
master/6491/artifact/exported-artifacts/basic-suit-master- el7/test_logs/basic-suite-master/post-002_bootstrap.py/ lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
Error snippet from VDSM log, this repeats on each connection attempt
from
Engine side:
<error>
2017-04-27 06:39:27,768-0400 INFO (Reactor thread) [ProtocolDetector.AcceptorImpl] Accepted connection from ::ffff:192.168.201.3:49530 (protocoldetector:74) 2017-04-27 06:39:27,898-0400 ERROR (Reactor thread) [vds.dispatcher] uncaptured python exception, closing channel <yajsonrpc.betterAsyncore.Dispatcher connected ('::ffff:192.168.201.3', 49530, 0, 0) at 0x1cc3b00> (<class 'socket.error'>:Address family not supported by protocol [/usr/lib64/python2.7/asyncore.py|readwrite|110] [/usr/lib64/python2.7/asyncore.py|handle_write_event|468] [/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore.py|handle_ write|70] [/usr/lib/python2.7/site-packages/yajsonrpc/betterAsyncore.py|_delegate_ call|149] [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|handle_write|213] [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_handle_io|223] [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|_verify_host|237] [/usr/lib/python2.7/site-packages/vdsm/sslutils.py|compare_names|249]) (betterAsyncore:160)
</error>
This means that what we have in the certificate do not match the source address we get. I suspect that we issue the certificate for 192.168.201.3 but when we get ::ffff:192.168.201.3. The change was verified in the env when ipv4 is used. I pushed a revert [1] for now so we can work on fixing the issue.
[1] https://gerrit.ovirt.org/#/c/76160
-- Regards, Evgheni Dereveanchin
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel