oVirt 3.5 test day 2 results
Hi everyone, Hi tested again http://www.ovirt.org/Features/WebSocketProxy_on_a_separate_host What happened on tast day 1 * found minor packaging issues * stopped earlier facing SSL issues, had a followup the day after an managed to have the feature working. This time things got better, and again the feature works as expected. The packaging issues are gone, but I still had UX annoyances along the way. I followed instructions on the wiki page above. Platform: F20 hypervisor host F20 engine host F19 websocket proxy (Didn't had time to test on different platforms because local bandwith issues eat lot of time just to install things) Installation went fine. websocket proxy setup is maybe a bit clumsy (I mean the text mode wizard), but it is bearable (I don't mind at all, but someone else can...); for some reasons (I cannot exclude an error from mine) engine got configured to use localhost as websocket proxy. To fix this I edited the engine config (update on DBMS), but then faced this error on proxy side: Jul 29 17:13:14 shinji ovirt-websocket-proxy.py[17004]: 1: handler exception: [Errno 1] _ssl.c:504: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher to redo the websocket setup I removed (actually renamed) /etc/pki/ovirt-engine and rerun setup. After that everything worked fine Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 8: connecting to: 192.168.1.53:5900 (using SSL) Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177: SSL/TLS (wss://) WebSocket connection Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177: Version hybi-13, base64: 'False' Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177: Path: '/eyJ2YWxpZFRvIjoiMjAxNDA3MjkxNTIx [...] 192.168.1.53 is the hypervisor host I used Now the point is maybe I did some mistakes or overlooked some configuration steps (maybe blindly hit return instead of changing a default), but I suggest to improve the docs/wiki to document how to fix common gotchas and/or to reconfigure things. Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
Thanks Francesco, some comments between the lines. ----- Original Message -----
From: "Francesco Romani" <fromani@redhat.com> To: "users" <users@ovirt.org>, devel@ovirt.org Sent: Tuesday, July 29, 2014 5:42:06 PM Subject: [ovirt-devel] oVirt 3.5 test day 2 results
Hi everyone,
Hi tested again http://www.ovirt.org/Features/WebSocketProxy_on_a_separate_host
What happened on tast day 1 * found minor packaging issues * stopped earlier facing SSL issues, had a followup the day after an managed to have the feature working.
This time things got better, and again the feature works as expected.
The packaging issues are gone, but I still had UX annoyances along the way.
I followed instructions on the wiki page above. Platform: F20 hypervisor host F20 engine host F19 websocket proxy (Didn't had time to test on different platforms because local bandwith issues eat lot of time just to install things)
Installation went fine.
websocket proxy setup is maybe a bit clumsy (I mean the text mode wizard), but it is bearable (I don't mind at all, but someone else can...);
We choose that way to avoid to ask to the user to provide the root password of the engine host, in order to automatically copying files via SCP or executing commands over ssh on the remote host, for security reasons. I agree with you that due to that assumption this result is not so usable.
for some reasons (I cannot exclude an error from mine) engine got configured to use localhost as websocket proxy.
As a default value, engine-setup configure the engine to look for a websocket proxy on localhost. The setup on the two host are asynchronous but we always need a value for the websocket proxy location so we use localhost as the default value for that. On the second host, setting up the websocket proxy, engine-setup produces all the command that the user have to run on the engine host in order to enroll the certificate and to have it pointing to the right websocket proxy. That command in my case is: engine-config -s WebSocketProxy=f19t6.localdomain:6100 and should be enough to configure the websocket proxy location without manually touching the DB. I tried to reproduce and I also encountered the problem you stated: the engine still points to localhost for websocket proxy. Going deeper, 'engine-config -g WebSocketProxy' already returns the new correct value but the web console still points on localhost. Now I had to reload the whole engine to make that property effective; if I remember correctly with past release it was enough to change the property value without reloading it. I'm reporting a bug for that: https://bugzilla.redhat.com/1124851
To fix this I edited the engine config (update on DBMS), but then faced this error on proxy side:
Jul 29 17:13:14 shinji ovirt-websocket-proxy.py[17004]: 1: handler exception: [Errno 1] _ssl.c:504: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
to redo the websocket setup I removed (actually renamed) /etc/pki/ovirt-engine and rerun setup.
After that everything worked fine
Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 8: connecting to: 192.168.1.53:5900 (using SSL) Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177: SSL/TLS (wss://) WebSocket connection Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177: Version hybi-13, base64: 'False' Jul 29 17:26:52 shinji ovirt-websocket-proxy.py[17180]: 5: 192.168.1.177: Path: '/eyJ2YWxpZFRvIjoiMjAxNDA3MjkxNTIx [...]
192.168.1.53 is the hypervisor host I used
Now the point is maybe I did some mistakes or overlooked some configuration steps (maybe blindly hit return instead of changing a default), but I suggest to improve the docs/wiki to document how to fix common gotchas and/or to reconfigure things.
ok, I'll do.
Bests,
-- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Wed, 30 Jul 2014 09:04:10 -0400 (EDT) Simone Tiraboschi <stirabos@redhat.com> wrote:
We choose that way to avoid to ask to the user to provide the root password of the engine host, in order to automatically copying files via SCP or executing commands over ssh on the remote host, for security reasons. I agree with you that due to that assumption this result is not so usable.
'...no so usable', this is joke. It's real design failure. Do not take this personally but whoever approved this did bad job. j.
----- Original Message -----
From: "Jiri Belka" <jbelka@redhat.com> To: "Simone Tiraboschi" <stirabos@redhat.com> Cc: "Francesco Romani" <fromani@redhat.com>, "users" <users@ovirt.org>, devel@ovirt.org Sent: Wednesday, July 30, 2014 4:06:23 PM Subject: Re: [ovirt-users] [ovirt-devel] oVirt 3.5 test day 2 results
On Wed, 30 Jul 2014 09:04:10 -0400 (EDT) Simone Tiraboschi <stirabos@redhat.com> wrote:
We choose that way to avoid to ask to the user to provide the root password of the engine host, in order to automatically copying files via SCP or executing commands over ssh on the remote host, for security reasons. I agree with you that due to that assumption this result is not so usable.
'...no so usable', this is joke. It's real design failure. Do not take this personally but whoever approved this did bad job.
No, of course: I'm not so proud of it too. :-) A previous attempt used ssh and scp to do all automatically but it was rejected being judged not so secure. Avoiding to use ssh and scp so seams a strong requirement; if you have any better idea feel free to propose it. Simone
'...no so usable', this is joke. It's real design failure. Do not take this personally but whoever approved this did bad job.
No, of course: I'm not so proud of it too. :-)
A previous attempt used ssh and scp to do all automatically but it was rejected being judged not so secure. Avoiding to use ssh and scp so seams a strong requirement; if you have any better idea feel free to propose it.
I will not repeat myself again in details, all setup should be done from Admin portal, same was one adds a host. Anyway, job spent time on this work is useless. I hope it will be moved to trash bin, this is ridiculous. What is obvious is that who designed this is not UNIX sysadmin oriented junkie. j.
On Thu, 31 Jul 2014 08:26:20 +0200 Jiri Belka <jbelka@redhat.com> wrote:
'...no so usable', this is joke. It's real design failure. Do not take this personally but whoever approved this did bad job.
No, of course: I'm not so proud of it too. :-)
A previous attempt used ssh and scp to do all automatically but it was rejected being judged not so secure. Avoiding to use ssh and scp so seams a strong requirement; if you have any better idea feel free to propose it.
I will not repeat myself again in details, all setup should be done from Admin portal, same was one adds a host.
Anyway, job spent time on this work is useless. I hope it will be moved to trash bin, this is ridiculous.
What is obvious is that who designed this is not UNIX sysadmin oriented junkie.
----- Original Message -----
From: "Jiri Belka" <jbelka@redhat.com> To: "Simone Tiraboschi" <stirabos@redhat.com> Cc: "users" <users@ovirt.org>, devel@ovirt.org Sent: Thursday, July 31, 2014 8:26:20 AM Subject: Re: [ovirt-users] [ovirt-devel] oVirt 3.5 test day 2 results
'...no so usable', this is joke. It's real design failure. Do not take this personally but whoever approved this did bad job.
No, of course: I'm not so proud of it too. :-)
A previous attempt used ssh and scp to do all automatically but it was rejected being judged not so secure. Avoiding to use ssh and scp so seams a strong requirement; if you have any better idea feel free to propose it.
I will not repeat myself again in details, all setup should be done from Admin portal, same was one adds a host.
Anyway, job spent time on this work is useless. I hope it will be moved to trash bin, this is ridiculous.
What is obvious is that who designed this is not UNIX sysadmin oriented junkie.
j.
The big part of this task was indeed to properly complete the modularization of engine setup: now you can run engine-setup only for the websocket-proxy stuff and it don't try anymore to setup jboss AS and DBMS stuff as it did in the past. We need that in any case. The work on the console UI for websocket proxy cert was quite small since the 'interface' is really simple. Of course we can do better, but I'm not so sure we really need it now. Actual solution can be judged cumbersome but I think that only a few sysadmin are really going to install the websocket proxy on a separate host; I'm almost sure that they aren't going to move it one day on an host and one day on another so a bit of manual work on my opinion can be acceptable on that. Simone
participants (3)
-
Francesco Romani -
Jiri Belka -
Simone Tiraboschi