5:16 a.m.
It was never there. When we use ssl module we perform a client certificate
check which is not available in our m2crypto code. The check fails because
the name we use in the certificate is not resolvable in OST.
30 kwi 2017 12:09 "Yaniv Kaul" <ykaul(a)redhat.com> napisał(a):
On Sun, Apr 30, 2017 at 1:03 PM, Piotr Kliczewski <
piotr.kliczewski(a)gmail.com> wrote:
> When we can have it fixed? I checked few minutes ago and the problem
> is still there.
>
https://gerrit.ovirt.org/#/c/76225/ should cover this.
What I wonder is what caused this in the first place. The SSL change?
Y.
>
> Thanks,
> Piotr
>
> On Sat, Apr 29, 2017 at 11:18 AM, Piotr Kliczewski <pkliczew(a)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(a)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(a)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(a)redhat.com
> >
> >> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Apr 27, 2017 at 3:13 PM, Evgheni Dereveanchin
> >>> <ederevea(a)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_ma
> ster/6491/
> >>>>
> >>>> VDSM log:
> >>>>
> >>>>
> >>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
> ster/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(a)ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>