On 17 Sep 2013, at 10:03, Tino Vazquez wrote:
Hi Stefan,
comments inline,
On Tue, Sep 17, 2013 at 2:51 PM, Stefan Kooman <ste...@bit.nl> wrote:
Hi list,
I'm in the process of testing the OpenNebula oZones / VDC
functionality.
My setup is as follows:
- 2 hosts, with 1 one of them in a cluster "TESTCLUST01", 1 in
default
cluster.
- a zone "TESTZONE01" using resources from "TESTCLUST01"
- a VDC "TESTVDC01" within zone "TESTZONE01".
I have several apache vhosts (listening on *:443) acting as reverse
(SSL) proxy:
- ozones (reverse proxying to http://127.0.0.1:6121)
- sunstone (reverse proxying to http://172.16.0.183:9869
- occi (reverse proxying to http://127.0.0.1:4567)
These end points all work correctly (occi API works, sunstone works,
ozones web GUI works).
This is a wise choice. Given that Sunstone and oZones accept and emit
authentication credentials in plaintext, it is insane to have those
listeners talking to the Internet without a SSL proxy.
Creating the zone, cluster and vdc goes fine. However, the Sunstone
Endpoint for the VDC "TESTVDC01" is not working. If I understand the
documentation correctly [1] I should point my browser to the
sunstone
endpoint. In my case
http(s)://sunstone.domain.tld/sunstone_TESTVDC01/
The response I get is:
"Sinatra doesn’t know this ditty.
Try this:
get '/sunstone_TESTVDC01/' do
"Hello World"
end
VDC cli interface does work (export
ONE_XMLRPC="http://localhost:2633/RPC2"; and export
ONE_AUTH=~/.one/one_vdc).
In this case you are not using the oZones reverse proxy functionality,
but rather accessing OpenNebula directly. You should use an endpoint
of the form
ONE_XMLRPC="http://ozones-server/TESTVDC01";
It seems like a very bad idea to do anything that would make a URL like
that functional, as it implies an insecure proxy of the XMLRPC interface
to an external address.
sunstone.log:
"GET /sunstone_TESTVDC01/ HTTP/1.1" 404 456 0.0024
ozones-server.log
"GET /zone/user?timeout=true HTTP/1.1" 200 19672 0.0189
I haven't setup the Apache server like [2] but made per vhost reverse
proxies. What port and URI should be hit by the proxy on the backend
site when
hitting "http://ozones.server/sunstone_MyVDC/"; on the frontend?
I don't think your use case is supported.
That's an understatement.
The docs for configuring the oZones server are laughably poor (e.g.
commands and file paths that are only found on Ubuntu and its sibling
distros, whose Apache config is unlike any others) and the only useful
way to understand how it is intended to work is to watch its startlingly
wrong behaviors when given seemingly correct config parameters and
search through the code for how they happen.
The oZones GUI is not designed to support secure (i.e. proxied)
communications with OpenNebula instances, and that is made obvious lines
349 and 406 of /usr/lib/one/ozones/public/js/plugins/vdcs-tab.js, both
of which use literal "http://"; strings to build the links to OpenNebula
and use the hostname extracted from zone's ENDPOINT parameter (which is
likely to be 'localhost' for instances that are only used to build VDC's
in a zone managed on the same host) To make the oZones GUI provide URL's
that work, one must fix the code.
From a broader perspective, the problem is in the design. It doesn't
make any sense for one tool to handle multiple OpenNebula instances as a
collection of Zones that also is the only tool for defining a VDC: a
subset of a cluster, which is a subset of a zone. VDC definition should
be moved into OpenNebula proper (oned/one.db) and Sunstone. The oZones
server should only be required or useful for handling multiple zones, it
should assume that it needs to be able to communicate with OpenNebula
instances that are behind SSL proxies, and it should be documented to
make that assumption clear.
You see, the ozones server
talks with the apache server via a .htaccess file, where it is
dynamically setting reverse proxy rules for each created VDC. So,
after creating TESTVDC01, a couple of lines are written in the
.htaccess file so apache knows that when a request comes for
http://ozones-server/sunstone_TESTVDC01
it should redirect to
http://sunstone-server:9869
where sunstone-server is the Sunstone endpoint defined by the zone
that contains TESTVDC01. 9869 is the default Sunstone port, which can
be changed as well upon VDC creation.
This explanation doesn't much improve on the muddled documentation of
the oZones server. Maybe a as someone who has come at oZones as an admin
instead of as a developer I can offer a different angle:
It is important for people deploying the oZones server to understand
that it performs two weakly related functions:
I. Aggregate access to subsets (VDCs) of multiple OpenNebula instances
(Zones) through a single host running a web proxy.
II. Create a templated pattern of users, groups, and ACLs in a zone that
allows delegated administration & use of VDCs.
It does this using two distinct components:
1. A Ruby http (Sinatra/Thin) server listening on port 6121 which
manages the oZones database of zones and VDCs, serves the CLI tools and
the web GUI as clients, and creates OpenNebula and Apache configurations
for VDCs.
2. An Apache httpd with a virtual host configured as a dedicated
mod_rewrite reverse proxy, serving URLs for the XMLRPC and Sunstone
interfaces of all VDCs in all Zones under a single hostname. This
presents users with the appearance of all VDCs being in one place.
The linkage between the two is that (1) writes out a new root .htaccess
file for (2) with a set of 3 mod_rewrite rules for each VDC whenever a
VDC is created. As far as I can tell, Sunstone and the core one* CLI
tools are unaware of the VDC paradigm (unless you consider the
"vdcadmin" Sunstone view awareness) and the creation of a VDC by oZones
is nothing more than:
A. The creation of a user, a group, and 11 ACLs associated with them in
OpenNebula.
B. The creation of a set of 3 mod_rewrite rules for Apache.
C. Changes in the oZones database, which is only ever touched by oZones.
Only (A) is critical to the core VDC functionality: delegating
administrative control of a subset of an OpenNebula instance's resources
to one user and access to those resources for additional users that the
delegated admin can create. Any user of the "real" Sunstone and XMLRPC
URLs gets exactly what he would get via any of the VDC-specific URLs
that proxy the same zone. Unfortunately, oZones has assumptions embedded
in its code that make it incompatible with a minimally-secure OpenNebula
installation. Fortunately, one use what oZones does as a basis for
manual configuration of Apache and OpenNebula that achieves the same end
results.
_______________________________________________
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
