User Tools

Site Tools


soft:cloudservices

CLOUD SERVICE SOFTWARE


The update of the Community Cloud services will be done in http://cloudy.community/services

Prior to the general adoption of cloud services, users of CNs already shared or provided services and resources to the community, however, these users were only a minority. One of the reasons identified is the technological barrier. Before providing content, users willing to share information with the community have first to take care of the technical aspects such as the deployment of a server with a set of services.

In the past, users from the Guifi.net 1) CN tried to overcome this problem by releasing a GNU/Linux distribution named Guinux 2) which provided end users with an easy way of offering network services to the community (HTTP proxy, DNS systems and MRTG graphic interfaces).

The key part of the distribution was a set of scripts that automatised the configuration process. End users were only asked for a few parameters such as their e-mail address and the node identifier. Shortly after the distribution was made available the number of end users sharing resources proliferated.

According to that, it became clear that lowering (or removing) the technological entry barrier encouraged users to provide more services and share their resources with the community. To this end, one of the goals of the CLOMMUNITY project is to release a GNU/Linux distribution, codenamed Cloudy, aimed at end users, to foster the transition and adoption of the CN cloud environment.

There was an OLD development page and a roadmap page for the first stage of the distribution.

Now there is a new development page with the sources.

Join the cloud!


Cloudy: CLOMMUNITY GNU/Linux distribution


Distribution requirements

The global specifications for the distribution were discussed as part of the task 4.1 (WP4) in the development guidelines of Cloudy, leading to a process of research, testing and selection of the software that better suited the requirements. The following list summarises the specified requirements and the chosen solutions to accomplish them:

  • Distribution: in order to foster services distribution amongst the CNs, a platform to publish and discover them is required. This way, service access does not depend on static networking deployments and is aware of the dynamically-changing conditions of CNs. The software chosen for service publishing and discovering is Avahi 3).
  • Decentralisation: a common network layer is required to allow all CN cloud nodes to communicate with each other directly. A good way to build it is to create a virtual Layer 2 based on a VPN service. Among the available options, TincVPN 4) has been chosen, as it fulfills all the requirements while being easy to configure and manage.
    • To coordinate the devices with TincVPN, a tool to automate the system deployment has been developed as part of the project. This software, named Getinconf 5), takes care of the TincVPN configuration process and the exchange of keys with the rest of the cloud nodes.
  • User-friendliness and experience: to this end, a web-based management platform has been developed aimed to integrate all the installation and configuration steps for the cloud services enabled in the Cloudy distribution. A simple web interface is available to the end user as an easy way of configure, administer and monitor the cloud services running in the node.
  • Free, Libre, Open Source Software: the distribution has been based on Debian GNU/Linux 6). Apart from being one of the most popular distributions and fulfilling all the technical requirements, it has been chosen because the Debian Social Contract 7) safeguards and guarantees that the software will always be open and free.

Architecture

The internal architecture of the Cloudy distribution is depicted in the figure in the right side, inside the central rectangle. On the bottom part, the virtual L2 over L3 network provides the overlay to interconnect all the servers in a micro cloud. This overlay network is used in the service announcement and discovery processes, that respectively publish local information to the cloud and receive remote data from its neighbour peers.

The service announcement daemon periodically checks the status of the available services by means of their corresponding plug-in and publishes the information. The nodes in the micro cloud receive this information and update their lists of services. When a service in a node is stopped or removed, this information is also announced to the rest of cloud servers. The service discovery daemon continuously listens for announcements from other peers, and keeps an updated list of the available services in the micro cloud. This list can be consulted directly by the services or by the end user. In this case, operations are performed via the command-line interface (console) or using the Cloudy web-based management interface.

The system can be administered via either the web interface or the console. The first one provides to end users a tool for that, covering the most basic options (installation, self-configuration and control of the services). The console is the traditional approach to the system management, providing all the available options, let for advanced users.

Contents (services offered)

The services are public for the guifi.net CN and useful for research purposes.

A list of services offered in the Cloudy distribution:

[ TO REVISE ]

Tahoe Introducer

Distributed storage listed in the GNU Software directory.

Can be seen as a RAID for the cloud.

Running the client-storage service for guifi.net Tahoe public GRID:

  • As root:
    • apt-get install tahoe-lafs
  • As normal user:
    • tahoe create-node -i pb://cporo6rrozvkzu5ux6qkzdt5pqbynvkb@10.139.40.59:60730/introducer
    • tahoe start

At the same time the configured node is a client and storage for the Tahoe-LAFS guifi.net public GRID.

By default needs 10 storage nodes, you can tune ~/.tahoe/tahoe.cfg if your needs are different.

It's better to be directly connected, to allow offering your node as storage too. You can use the service behind NAT.

PeerStreamer

Users in a network are able to stream video in a P2P overlay. This software is developed by a research team from the university of Trento (Italy). Click here to visit the project official website.

For the time being we found the following facilities useful for the Clommunity project

  • Video on demand streaming
  • Live streaming (from almost any devices, such as webcams or antenas)
  • Streaming from VLC
  • Web GUI Interface

To see the tutorials related with PeerStreamer visit this page

Tinc VPN

VPN software.

Configured to form a Layer 2 network, in switch mode.

Maximum number of nodes ~1.000 based on the Tinc VPN page talking about the scalability of the VPN. Perhaps enough.

VPN Data

Configuration data for the Network: gcodis 192.168.168.0/24

  • /etc/tinc/gcodis/tinc.conf
Device=/dev/net/tun
Mode=switch
Name=gcodistinc1
  • /etc/tinc/gcodis/tinc-up script
#!/bin/sh
ip -4 addr add 192.168.168.1/24 dev $INTERFACE
ifconfig $INTERFACE up
  • /etc/tinc/gcodis/hosts/gcodistinc1
Compression=10
Address=10.139.40.39
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA9Jf5olMZ1khDh5Y1gaJ1lso48A48KRBnTRrjhphL6EL70hilPG7N
ff/oJPna/ZI0vukfVjoPTx8DT00clGWXEMNTqtiomnZjs1OhaDV808GeKbXKC5QP
dK3o816wces41XvakDMm5sUx9vrwhqNdmy/UMtP3B0Si5Bd3hhx6ilb998CwIbrR
mcmj1zmJojeDVTBozt6IN2D0TMTwyfp0qf7YMhM89spzJiyfQzBGiGNg7BiDhnVj
LUD/+6ZtoJos7o/XIhxSja+SSsAmotvc9dvwIhRKGYLqKXISimNsbOMmsqCxqIb4
2q7NSSQZ6j1bdGHbxcST/V6EqdmtnNKtfQIDAQAB
-----END RSA PUBLIC KEY-----
TODO

Syncronize the configuration for the nodes. The qmp project has been developing a web tool.

gcodis Tinc client

This is what is needed for a client configuration right now with the minimal manual method Tinc system for adding nodes.

apt-get install tinc
mkdir /etc/tinc/gcodis/

Edit the Tinc client file

vi /etc/tinc/gcodis/tinc.conf

Write this configuration:

Device=/dev/net/tun
Mode=switch
Name=whatevername
ConnectTo=gcodistinc1

if needed do this, but gcodis script already creates this this is for use with LXC containers

mkdir /dev/net
cd /dev/net
mknod tun c 10 200
cd -

Needed to avoid creation failure

mkdir /etc/tinc/gcodis/hosts

Creates keys and /etc/tinc/gcodis/hosts/whatevername

tincd -n gcodis -K

your created tinc hostname

vi /etc/tinc/gcodis/hosts/whatevername

add the field Address with you real IP address

Address=a.b.c.d

Edit the script to bring up the interface.

vi /etc/tinc/gcodis/tinc-up

Write this exact content.

#!/bin/sh
ip -4 addr add 192.168.168.X/24 dev $INTERFACE
ifconfig $INTERFACE up

Make executable the script.

chmod 755 /etc/tinc/gcodis/tinc-up

Add info to connect to server. Edit the 'server' node script.

vi /etc/tinc/gcodis/hosts/gcodistinc1

Put this data inside:

Address=10.139.40.39
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEA9Jf5olMZ1khDh5Y1gaJ1lso48A48KRBnTRrjhphL6EL70hilPG7N
ff/oJPna/ZI0vukfVjoPTx8DT00clGWXEMNTqtiomnZjs1OhaDV808GeKbXKC5QP
dK3o816wces41XvakDMm5sUx9vrwhqNdmy/UMtP3B0Si5Bd3hhx6ilb998CwIbrR
mcmj1zmJojeDVTBozt6IN2D0TMTwyfp0qf7YMhM89spzJiyfQzBGiGNg7BiDhnVj
LUD/+6ZtoJos7o/XIhxSja+SSsAmotvc9dvwIhRKGYLqKXISimNsbOMmsqCxqIb4
2q7NSSQZ6j1bdGHbxcST/V6EqdmtnNKtfQIDAQAB
-----END RSA PUBLIC KEY-----

Copy your whatevername:/etc/tinc/gcodis/hosts/whatevername to gcodistinc1:/etc/tinc/gcodis/hosts/whatevername perhaps you will need administration permissions with this implementation in the remote 'gcodistinc1' host. With this you add the 'whatevername' machine to the Tinc VPN.

After this, activate the gcodis VPN to run on startup.

echo "gcodis" >> /etc/tinc/nets.boot

Restart the Tinc daemon.

 /etc/init.d/tinc restart

You can do some tests now.

ping -c4 192.168.168.1

You can ping another nodes which are not in your /etc/tinc/gcodis/hosts/ directory but are present in the 'server' /etc/tinc/gcodis/hosts/ directory.

TODO routes?

gcodis Software repository

Install and updates the gcodis software.

First install is using the gcodis-create.sh script for creating or adapting an existing installation.

Manage updates for the already installed gcodis system and includes the project Consortium Software.

Configure your repositories creating the file /etc/sources.list.d/gcodis.list containing the line:

deb http://10.139.40.20/ wheezy main

Further instructions for updating the gcodis installation will be given when new software be available.

AvahiDNS (a.k.a. ddnsc)

Publish Avahi services globally, beyond the Layer 2 limitation, further broadcast domain. In Linux there is no implementation for publishing services to a remote DNS server.

Based on a research group “Distributed DNS Cache” from Battlemesh v6.

The distribution of the DNS service is done configuring multiple DNS servers using anycast addresses, the same for all the DNS servers, the user get the nearest DNS server based on the underlaying routing protocol, it's independent of the routing protocol but relies on it; the routing protocol gives the nearest DNS server to the client.

A Community Box could be plugged inside different CNs and use the same anycast IP as the IP for the DNS servers and get a list of services from the AvahiDNS and connect to the same 'tahoe-introducer-main' service in all the CNs without changing the code inside gcodis. You don't need to configure anything.

With this the Community Box is ubiquitous related to the CN it's installed.

Caracal DB

Installation

You require an installation of either OpenJDK 8 or Oracle JDK 8.

For OpenJDK see https://github.com/hgomez/obuildfactory/wiki/How-to-build-and-package-OpenJDK-8-on-Linux

To install Oracle's JDK on Ubuntu you can use

sudo add-apt-repository ppa:webupd8team/java -y
sudo apt-get update
sudo apt-get install oracle-java8-installer

To automatically set up the Java 8 environment variables

sudo apt-get install oracle-java8-set-default

Alternatively for Debian see http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html

Verify that your installation works by running

java -version

and checking the version number.

Once this works you have to download the binary

wget http://cloud7.sics.se/caracal/caracaldb.deb

and install it

dpkg -i caracaldb.deb

.

After you configure it properly (see below) you should be able to start the server with either

service caracaldb start

or

/etc/init.d/caracaldb start

.

If you wish to install the REST API for caracal on the same machine download its binary as well

wget http://cloud7.sics.se/caracal/caracaldb-api.deb

and install it

dpkg -i caracaldb-api.deb

. Equivalently to above the REST API gets started with

service caracaldb-api start

or

/etc/init.d/caracaldb-api start

.

To have a Web UI in addition to the simply REST API, install a web-server like nginx:

apt-get install nginx

Configuration

The config files for CaracalDB and its REST API are in /etc/caracaldb/application.conf and /etc/caracaldb-api/application.conf respectively.

Please note that in order to boot up a CaracalDB cluster you need at least 3 machines which need to be configured to point to the same bootstrap server (simply the machine where bootstrap.address.hostname=server.address.hostname). The variable caracal.bootThreshold defines how long the bootstrap server will wait for nodes to join before actually booting up the cluster. It is much more efficient to boot a cluster via the initial bootstrapping process than by adding new nodes later, so set this value as high as you can guarantee nodes to be join in the beginning.

Make sure to assign every node an IP address that can be reached from the other nodes and doesn't change over time, since it is part of the node's system id.

This is the minimal configuration necessary. In order to tweak more setting take a look at https://github.com/CaracalDB/CaracalDB/blob/master/server/src/main/resources/reference.conf for available options.

To set up the REST API you need to configure 3 IP addresses (and associated ports):

  1. caracal.api.host.hostname refers to the web facing IP address you can later use to access the API from a browser.
  2. client.address.hostname is the internal ip that is used to communicate with the caracal-server nodes.
  3. bootstrap.address.hostname is the ip of the bootstrap server (after booting the system).

To allow access to the Web UI configure your web-server to point to /srv/www/caracalui. In case of nginx, for example, create a file in /etc/nginx/sites-enabled containing

server {
        listen   80;
        server_name  caracal.SOMETHING.com;
 
        access_log  /var/log/nginx/localhost.access.log;
 
        location / {
                root   /srv/www/caracalui;
                index  index.html index.htm caracalui.html;
        }
}

Also make sure that apiUrl in /srv/www/caracalui/config.yaml and caracal.api.host.hostname:caracal.api.host.port in /etc/caracaldb-api/application.conf correspond!

In order to test if everything works as expected call up the url of the Web UI and try to put a value and retrieve it again. If only the REST API is available you can you use curl to do the same thing:

curl -X PUT -d "some test string" http://{apiUrl}/schema/test/key/01020304
curl http://{apiUrl}/schema/test/key/01020304

This should return a JSON construct containing “some test string”.

If you didn't install the REST API at all, you can use the client library jar file (e.g. http://cloud7.sics.se/caracal/caracaldb-client.jar) and run the CLI directly:

java -jar caracaldb-client.jar
CaracalDB@disconnected> connect {bootstrapaddress}:{port} {clientaddress}:{port}
CaracalDB@{bootstrapaddress}:{port}> set 01020304 "some test string"
CaracalDB@{bootstrapaddress}:{port}> get 01020304

This should return “some test string”. Please note that calling get 01020304 on the CLI is *not* the same key as using GET method on http:/{apiUrl}/schema/test/key/01020304 in the REST API. The REST API automatically uses MD5 hash of the schema name, in this case “test”, as a prefix of the key, while the CLI currently has no such support.

Basic Usage

Java API

Once you have a working cluster running you can use the Java API to execute operations. A simple example for all the core operations would be:

import se.sics.caracaldb.Key;
import se.sics.caracaldb.client.BlockingClient;
import se.sics.caracaldb.client.ClientManager;
import se.sics.caracaldb.operations.GetResponse;
import se.sics.caracaldb.operations.ResponseCode;
 
class SomeClass {
	public boolean someMethod(Key k, byte[] value) {
		BlockingClient client = ClientManager.newClient();
		ResponseCode putResp = client.put(k, val);
		if (putResp != ResponseCode.SUCCESS) {
            		return false;
        		}
		GetResponse getResp = client.get(k);
		if (getResp.code != ResponseCode.SUCCESS) {
            		return false;
        		}
		KeyRange range = KeyRange.closed(k).closed(k);
		RangeResponse rangeResp = client.rangeRequest(range);
		if (rangeResp.code != ResponseCode.SUCCESS) {
            		return false;
        		}
		return Arrays.equal(value, getResp.data) 
			&& rangeResp.results.contains(k);
	}
}

For more advanced usage feel free to look into the implementation of the command-line client (https://github.com/CaracalDB/CaracalDB/blob/master/client/src/main/java/se/sics/caracaldb/client/Console.java) and the REST API (https://github.com/CaracalDB/CaracalDB/blob/master/rest-api/src/main/scala/se/sics/caracaldb/api/CaracalWorker.scala).

REST API

CaracalDB's REST API provides the following services:

  1. *PUT/GET/DELETE* at /schema/{schema}/key/{key} on key in schema. If type is *PUT* then the body of the request must be a string (or a JSON object as a string) of the value to be put.
  2. *GET* at /schema/{schema}/key/{fromkey}/{tokey} performs a range query of the range [fromkey,tokey] (prefixed by schema).
  3. *GET* at /schema/{schema}/prefix/{key} performs a range query of all entries with the prefix key in schema.
  4. *GET* at /schema/{schema} performs a range query of all entries with in schema.

All requests are responded to in a JSON format.

GVod Video-On-Demand

http://cloud7.sics.se:1969/1 visit this test-page for GVod. At this page, you will find a link to download and install our firefox addon, as well as a test video that you can click on after you have installed the addon. The installation requirements are jdk 1.6+ and firefox v4+. We have tested the system on ubuntu 12.04+ and windows 7.

Installation process

As mentioned above the Cloudy distribution generation process is based on Debian’s live-build tool 8). This allows to create an installation image that can also be used as a Live CD 9) for testing it without modifying the machine’s content. When starting the server from the installation media, the user is prompted with a customised screen of GRUB 10) showing the available options (see figure below). In the boot menu, the Install option is selected by default.

Go to howto install wiki page to know the steps to install the Cloudy distribution.

Web-based management interface

One of the objectives of Cloudy is to allow non technical skilled users to deploy their own cloud servers and services. To this end, a web based management interface is available as part of the distribution. Once Cloudy is installed, during the first boot the user is prompted with a message indicating the URL which could be used for accessing it with any standard web browser from the user’s local computer.

The management interface (see screenshot below) is a light website made with PHP 11) combined with the Bootstrap framework 12). This way, non technically skilled users can find themselves comfortable and familiar with it.

The design is based on a whole-framed page with a horizontal bar on top. This bar contains the following drop-down menus to access the website functions (left to right):

  • User: access basic user functions (password change, logout, etc.).
  • Languages: change the language of the web interface.
  • Avahi: show the list of services discovered in the micro cloud.
  • Clommunity: manage the cloud services shipped in Cloudy.
  • Guifi: manage the Guifi.net-related services shipped in Cloudy.

Go to howto [TO ADD] wiki page to know the steps to configure and to manage the Cloudy distribution via web interface.

Service announcement and discovery

As it has been found during WP4.1 and described in section 2.3.3 of D4.1, one of the most important things to help users participate from the network services are the service announcement and discovery tools. This is the reason why the model has been developed on the basis that each server publishes its available services with the necessary credentials to be used or federated, so that other users and servers can use it.

Go to howto [TO ADD] wiki page to know about the service announcement and discovery in the Cloudy distribution.

Clouder: Docker with Cloudy container

Currently the Guifi.net team has started the development of a new approach to CN clouds that consists on using Docker (a Linux container (LXC) management system) to virtualise the Cloudy distribution.

This approach adds a special support for infrastructure services (IaaS), as the cloud nodes are able to create multiple virtual machine instances for other purposes in addition to the ones dedicated to Cloudy.


References

soft/cloudservices.txt · Last modified: 2015/09/23 16:42 by jlflorit