10:42 a.m.
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
8:04 a.m.
New subject: [ovirt-devel] oVirt 3.5 test day 2 results
Thanks Francesco,
some comments between the lines.
----- Original Message -----
From: "Francesco Romani" <fromani(a)redhat.com>
To: "users" <users(a)ovirt.org>, devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:06 a.m.
New subject: [ovirt-devel] oVirt 3.5 test day 2 results
On Wed, 30 Jul 2014 09:04:10 -0400 (EDT)
Simone Tiraboschi <stirabos(a)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.
11:14 a.m.
New subject: [ovirt-devel] oVirt 3.5 test day 2 results
----- Original Message -----
From: "Jiri Belka" <jbelka(a)redhat.com>
To: "Simone Tiraboschi" <stirabos(a)redhat.com>
Cc: "Francesco Romani" <fromani(a)redhat.com>, "users"
<users(a)ovirt.org>, devel(a)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(a)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
1:26 a.m.
New subject: [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.
2:44 a.m.
New subject: [ovirt-devel] oVirt 3.5 test day 2 results
On Thu, 31 Jul 2014 08:26:20 +0200
Jiri Belka <jbelka(a)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.
FYA https://bugzilla.redhat.com/show_bug.cgi?id=1116017
3:05 a.m.
New subject: [ovirt-devel] oVirt 3.5 test day 2 results
----- Original Message -----
From: "Jiri Belka" <jbelka(a)redhat.com>
To: "Simone Tiraboschi" <stirabos(a)redhat.com>
Cc: "users" <users(a)ovirt.org>, devel(a)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
3566
days inactive
3568
days old
6 comments
3 participants
participants (3)
-
Francesco Romani -
Jiri Belka -
Simone Tiraboschi