OCCI Service Configuration 3.0
The OpenNebula OCCI (Open Cloud Computing Interface) server is a web service that enables you to launch and manage virtual machines in your OpenNebula installation using an implementation of the OGF OCCI API specification based on the draft 0.8. This implementation also includes some extensions, requested by the community, to support OpenNebula specific functionality. The OpenNebula OCCI service is implemented upon the OpenNebula Cloud API (OCA) layer that exposes the full capabilities of an OpenNebula private cloud; and Sinatra, a widely used light web framework.
The current implementation includes all the resource referenced in the latest draft of the OGF OCCI API specification, namely:
The following sections explain how to install and configure the OCCI service on top of a running OpenNebula cloud.
You must have an OpenNebula site properly configured and running to install the OpenNebula OCCI service, be sure to check the OpenNebula Installation and Configuration Guides to set up your private cloud first. This guide also assumes that you are familiar with the configuration and use of OpenNebula.
The OpenNebula OCCI service was installed during the OpenNebula installation, and the dependencies of this service are installed when using the install_gems tool as explained in the installation guide
If you installed OpenNebula from source you can install the OCCI dependencias as explained at the end of the Building from Source Code guide
The OCCI Server included in the OpenNebula distribution does not implement the latest OCCI specification, it is based on the draft 0.8 of the OFG OCCI specification. The implementation of the latest specification is being developed by TU-Dortmund in a ecosystem project. You can check the documentation of this project in the following link
The service is configured through the /etc/one/occi-server.conf
file, where you can set up the basic operational parameters for the OCCI service, namely:
oned
daemon; and the server and port for the OpenNebula OCCI service web server. This will be the URL of your cloud.VM_TYPE
defines the name and the OpenNebula templates for each type of Compute, to enable different sizes of Computes.The following table summarizes the available options:
VARIABLE | VALUE |
---|---|
:one_xmlrpc | oned xmlrpc service, http://localhost:2633/RPC2 |
:server | FQDN for your cloud |
:port | for incoming connections |
:bridge | Name of the bridge needed to create Networks |
:auth | Authentication protocol for the OCCI server |
:instance_types | The Computes types for your cloud |
SERVER
must be a FQDN, do not use IP's here
occi-server.conf
file
Example:
# OpenNebula sever contact information :one_xmlrpc: http://localhost:2633/RPC2 # Host and port where OCCI server will run :server: localhost :port: 4567 # SSL proxy that serves the API (set if is being used) #:ssl_server: fqdm.of.the.server # Authentication driver for incomming requests # occi, for OpenNebula's user-password scheme # x509, for x509 certificates based authentication :auth: occi # Authentication driver to communicate with OpenNebula core # cipher, for symmetric cipher encryption of tokens # x509, for x509 certificate encryption of tokens :core_auth: cipher # Life-time in seconds for token renewal (that used to handle OpenNebula auths) :token_expiration_delta: 1800 # VM types allowed and its template file (inside templates directory) :instance_types: :small: :template: small.erb :cpu: 1 :memory: 1024 :medium: :template: medium.erb :cpu: 4 :memory: 4096 :large: :template: large.erb :cpu: 8 :memory: 8192 # Default language setting for Self-Service UI :lang: en_US
You can define as many Compute types as you want, just:
/etc/one/occi_templates
. This template will be completed with the data for each cloud occi-compute create request, and then submitted to OpenNebula.CPU = 1 MEMORY = 1024 OS = [ kernel = /vmlinuz, initrd = /initrd.img, root = sda1, kernel_cmd = "ro xencons=tty console=tty1"]
/etc/one/occi_templates/common.erb
file.
common.erb
file.
To start the OCCI service just issue the following command
<xterm>
occi-server start
</xterm>
You can find the OCCI server log file in /var/log/one/occi-server.log
.
To stop the OCCI service: <xterm> occi-server stop </xterm>
The cloud users have to be created in the OpenNebula system by oneadmin
using the oneuser
utility. Once a user is registered in the system, using the same procedure as to create private cloud users, they can start using the system. The users will authenticate using the HTTP basic authentication with user-ID
their OpenNebula's username and password
their OpenNebula's password.
OpenNebula OCCI Server supports two authorization methods in order to log in. The method can be set in the occi-server.conf, as explained above. These two methods are:
In the basic mode, username and password(sha1) are matched to those in OpenNebula's database in order to authenticate the user in each request.
This method performs the request to OpenNebula based on a x509 certicate DN (Distinguished Name). The DN is extracted from the certificate and matched to the password value in the user database (remember spaces are removed from DNs).
In order to use this method, OpenNebula must be configured with the x509 for Public Clouds settings.
Note that OpenNebula will not verify that the user is holding a valid certificate at the time of login: this is expected to be done by the external container of the OCCI server (normally Apache), whose job is to tell the user's client that the site requires a user certificate and to check that the certificate is consistently signed by the chosen Certificate Authority (CA).
OpenNebula OCCI runs natively just on normal HTTP connections. If the extra security provided by SSL is needed, a proxy can be set up to handle the SSL connection that forwards the petition to the OCCI Service and takes back the answer to the client.
This set up needs:
If you want to try out the SSL setup easily, you can find in the following lines an example to set a self-signed certificate to be used by a lighttpd configured to act as an HTTP proxy to a correctly configured OCCI Service.
Let's assume the server were the lighttpd proxy is going to be started is called cloudserver.org
. Therefore, the steps are:
We are going to generate a snakeoil certificate. If using an Ubuntu system follow the next steps (otherwise your milleage may vary, but not a lot):
ssl-cert
package<xterm> $ sudo apt-get install ssl-cert </xterm>
<xterm> $ sudo /usr/sbin/make-ssl-cert generate-default-snakeoil </xterm>
<xterm> $ sudo cat /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem > /etc/lighttpd/server.pem </xterm>
You will need to edit the /etc/lighttpd/lighttpd.conf
configuration file and
server.port = 8443
#### proxy module ## read proxy.txt for more info proxy.server = ( "" => ("" => ( "host" => "127.0.0.1", "port" => 4567 ) ) ) #### SSL engine ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/server.pem"
The host must be the server hostname of the computer running the EC2Query Service, and the port the one that the EC2Query Service is running on.
The occi.conf
needs to define the following:
# Host and port where the occi server will run :server: <FQDN OF OCCI SERVER> :port: 4567 # SSL proxy that serves the API (set if is being used) :ssl_server: https://localhost:443
Once the lighttpd server is started, OCCI petitions using HTTPS uris can be directed to https://cloudserver.org:8443
, that will then be unencrypted, passed to localhost, port 4567, satisfied (hopefully), encrypted again and then passed back to the client.