When we can have it fixed? I checked few minutes ago and the problem
is still there.
Thanks,
Piotr
On Sat, Apr 29, 2017 at 11:18 AM, Piotr Kliczewski <pkliczew@redhat.com> wrote:
> 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:
>> 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
>> 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:
>>>>
>>>>
>>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ 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
>
>
>
> _______________________________________________
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel