Hi, Daniel,
the problem I'm facing is a bit different from what you describe. For
example, I have one user who as one VM only. For him the setup works:
[uschwick@lxadm11 private]$ time euca-describe-instances | wc -l
2
real 0m0.614s
user 0m0.136s
sys 0m0.042s
If I switch to my other user with hundreds of VMs I run into described
timeout problems.
$ time euca-describe-instances
Warning: failed to parse error message from AWS: <unknown>:1:49: syntax
error
Traceback (most recent call last):
File "/usr/bin/euca-describe-instances", line 127, in <module>
main()
File "/usr/bin/euca-describe-instances", line 121, in main
euca.display_error_and_exit('%s' % ex)
File "/usr/lib/python2.6/site-packages/euca2ools/__init__.py", line
1436, in display_error_and_exit
dom = minidom.parseString(msg)
File "/usr/lib64/python2.6/xml/dom/minidom.py", line 1928, in parseString
return expatbuilder.parseString(string)
File "/usr/lib64/python2.6/xml/dom/expatbuilder.py", line 940, in
parseString
return builder.parseString(string)
File "/usr/lib64/python2.6/xml/dom/expatbuilder.py", line 223, in
parseString
parser.Parse(string, True)
xml.parsers.expat.ExpatError: syntax error: line 1, column 49
real 2m0.365s
user 0m0.122s
sys 0m0.046s
same test with econe gives:
[uschwick@oneadmin02 private]$ econe-describe-instances
econe-describe-instances: execution expired
This looks to me ike a performance issue.
Cheers,
Ulrich
On 02/03/2012 12:21 PM, Daniel Molina wrote:
On 3 February 2012 11:57, Daniel Molina<[email protected]> wrote:
On 3 February 2012 11:30, Ulrich Schwickerath
<[email protected]> wrote:
Hi, Daniel,
thanks a lot for the help on this. The problem with the ssl proxy was that I
was missing an extra / at the end of the ssl_server directive. So one needs
:ssl_server: https://cloud.opennebula.org/
rather than
:ssl_server: https://cloud.opennebula.org
else I get authentication errors. However, this is not the end of the story
I'm afraid. With this patch in place I can query the system, but it's very
very slow. My most important user has some 500 VMs in the system, and a
euca-describe-instances
times out or gives expat parse errors. If I query the system locally it
works fine and is very responsive. This problem is new in 3.2.1, I didn't
have this in 3.0 which I was using before. I already checked that I have all
rubygems installed which are needed.
Are you using the same client in both sides? Maybe It is an
environment problem (EC2_URL)
Any idea?
Ok, I think the problem is euca tools does not support paths. I have
already tested the following configuration and it works:
:ssl_server: https://devel.cloud.opennebula.org/
$ euca-describe-instances -U https://devel.cloud.opennebula.org | wc -l
151
$ econe-describe-instances -U https://devel.cloud.opennebula.org/ | wc -l
151
If you use euca with this url; https://devel.cloud.opennebula.org/ you
will get the previous error/timeout. Also if you use econe with this
url; https://devel.cloud.opennebula.org it will return a path empty
error. I will update the econe tools to set '/' by default
Cheers
Thanks!
Ulrich
On 02/02/2012 11:40 PM, Daniel Molina wrote:
Hi Ulrich,
We have added a new patch in order to support custom paths and ports
when setting up an SSL proxy on top of the econe-server. You can see
this patch in the following link:
http://dev.opennebula.org/issues/985
This patch has been included in the last release (3.2.1). I recommend
you to upgrade to this version. Also the performance should be
improved since we have included a new authentication cache.
Currently the econe-server is running in our public cloud with an SSL
proxy, using the following configuration:
$ cat econe.conf
# Host and port where econe server will run
:server: localhost
:port: 7141
# SSL proxy that serves the API (set if is being used)
:ssl_server: https://cloud.opennebula.org/econe
# Authentication driver for incomming requests
# ec2, default Acess key and Secret key scheme
# x509, for x509 certificates based authentication
:auth: ec2
# Authentication driver to communicate with OpenNebula core
# cipher, for symmetric cipher encryption of tokens
# x509, for x509 certificate encryption of tokens
:core_auth: cipher
$ cat apache2.conf
<VirtualHost *:443>
servername cloud.opennebula.org
SSLEngine on
ProxyPass /econe http://localhost:7141/
ProxyPassReverse /econe http://localhost:7141/
</VirtualHost>
If you use a path different from '/' the client must support this
feature, otherwise the authentication will fail. The econe tools
included in the 3.2.1 release support custom paths.
Also if you want the proxy to listen in a different port from the
default (443) you can specify it in the ssl_parameter:
:ssl_server: https://cloud.opennebula.org:8082/
Hope this helps
On 2 February 2012 22:45, Ulrich Schwickerath
<[email protected]> wrote:
Hi,
did anybody try to setup the ONE 3.2 econe-server with an SSL proxy ? The
instructions on the web on this seem to be a bit out of date.
I had it working fine with 3.0 but with 3.2 I get authentication errors
(the
ssl proxy setup is unchanged sinde 3.0). Direct access via http works
(although slower than before).
Cheers,
Ulrich
_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
--
--------------------------------------
Dr. Ulrich Schwickerath
CERN IT/PES-PS
1211 Geneva 23
e-mail: [email protected]
phone: +41 22 767 9576
mobile: +41 76 487 5602
--
Daniel Molina
Project Engineer
OpenNebula - The Open Source Toolkit for Data Center Virtualization
www.OpenNebula.org | [email protected] | @OpenNebula
--
--------------------------------------
Dr. Ulrich Schwickerath
CERN IT/PES-PS
1211 Geneva 23
e-mail: [email protected]
phone: +41 22 767 9576
mobile: +41 76 487 5602
_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
