On Thu, Jun 11, 2015 at 11:57 AM, <nicolas(a)devels.es> wrote:
El 2015-06-11 08:55, Simone Tiraboschi escribió:
>
>
Indeed, checking the Javascript console I discovered where the culprit is.
This ovirt engine machine had formerly a FQDN that was changed afterwards
(I used the .../setup/bin/ovirt-engine-rename script), so at installation
time, SSL certs were issued for that FQDN. The ovirt-engine-rename script
regenerated the engine certs, but seems that it didn't do the work for the
websocket proxy, so the old FQDN cert is still used and a connection cannot
be established with the daemon (logically, due to the mismatch). I can't
find any documentation on how to regenerate the websocket proxy cert,
though. Is there some script for that, or at least some manual way to
accomplish it?
Thanks for your help.
Based on an environment in 3.3.2 I solved a situation with webSocketProxy
Enabled only after original install + update thanks to Alon advises.
See full lthread here:
http://lists.ovirt.org/pipermail/users/2013-December/018554.html
Possibly it can apply to your environment too
You could do the following:
1. remove
In /etc/pki/ovirt-engine/keys/:
websocket-proxy.key.nopass
websocket-proxy.p12
In /etc/pki/ovirt-engine/certs/:
websocket-proxy.cer
2. run setup using:
# engine-setup --otopi-environment="OVESETUP_CONFIG/websocketProxyConfig=
bool:True"
and this should create websocket proxy certificates/keys in correct way....
Be sure to make backups and verify better, in particular it this is a
production environment.
HIH,
Gianluca