[ovirt-users] ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) [] Unable to process messages

[Martin Perina]

On Wed, Jul 20, 2016 at 4:44 PM, Nicolás <nicolas at devels.es> wrote:

> Hi Martin,
>
> Actually, up until now we had that cert configured in httpd and in
> websocket proxy. Seems that now in 4.0.x it's not enough, as opening the
> https://fqdn complains about the cert not being imported in the key
> chain.
>

​Yes, there's an updated procedure on using external CA in 4.0, for details
please take a look at Doc Text in

https://bugzilla.redhat.com/show_bug.cgi?id=1336838
​


> So I imported it via keytool, but I don't want to use it in the engine <->
> VDSM communication.
>

​Hmm, so that would imply that we have some issue with existing internal
enigne CA during upgrade ...
The strange thing is that we test upgrades a lot but so far we haven't seen
any issues which will broke
SSL setup between engine and VDSM. You said that you had to downgrade back
to 3.6.7 (so unfortunately for us we cannot investigate your nonworking
setup more), but how did you do that?
Removing all engine packages and configuration​, installing back 3.6.7
packaging and restoring configuration form backup?
I'm asking to know what changed in your setup between not working 4.0 and
working 3.6.7 ...

Thanks

Martin


> Thanks!
> En 20/7/2016 2:48 p. m., Martin Perina <mperina at redhat.com> escribió:
>
> Hi,
>
> sorry for late response, I overlook your reply :-(
>
> ​I looked at your logs and it seems to me that​ there's SSL error when
> engine tries to contact VDSM.
> ​You have mentioned that your are using your own custom CA. ​Are you using
> it only for HTTPS certificate or do you want to use it also for Engine <->
> VDSM communication?
> ​
> Martin Perina
>
>
> On Wed, Jul 20, 2016 at 9:18 AM, <nicolas at devels.es> wrote:
>
>> Any hints about this?
>>
>> El 2016-07-13 11:13, nicolas at devels.es escribió:
>>
>>> Hi,
>>>
>>> Unfortunately, upgrading to 4.0.1RC didn't solve the problem.
>>> Actually, the error changed to 'General SSLEngine problem', but the
>>> result was the same, like this:
>>>
>>> 2016-07-13 09:52:22,010 INFO
>>> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp
>>> Reactor) [] Connecting to /10.X.X.X
>>> 2016-07-13 09:52:22,018 ERROR
>>> [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor)
>>> [] Unable to process messages: General SSLEngine problem
>>>
>>> It's worth mentioning that we're using our own SSL certificates (not
>>> self-signed), and I imported the combined certificate into the
>>> /etc/pki/ovirt-engine/.truststore key file. Not sure if related, but
>>> just in case.
>>>
>>
>>> I had to downgrade to 3.6.7. I'm attaching requested logs, if you need
>>> anything else don't hesitate to ask.
>>>
>>> Regards.
>>>
>>> El 2016-07-13 09:45, Martin Perina escribió:
>>>
>>>> Hi,
>>>>
>>>> could you please share also vdsm.log from your hosts and also
>>>> server.log and setup logs from /var/log/ovirt-engine/setup directory?
>>>>
>>>> Thanks
>>>>
>>>> Martin Perina
>>>>
>>>> On Wed, Jul 13, 2016 at 10:36 AM, <nicolas at devels.es> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> We upgraded from 3.6.6 to 4.0.0 and we have a big issue since the
>>>>> engine cannot connect to hosts. In the logs all we see is this
>>>>> error:
>>>>>
>>>>>     ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL
>>>>> Stomp Reactor) [] Unable to process messages
>>>>>
>>>>> I'm attaching full logs.
>>>>>
>>>>> Could someone help please?
>>>>>
>>>>> Thanks.
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users [1]
>>>>>
>>>>
>>>>
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160720/ff398faa/attachment-0001.html>