[one-users] Sunstone endpoint for VDC

[Bill Cole]

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 <stefan at 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.