quick-install-admin-guide.rst

Administrator's Quick Installation Guide

This is the Administrator's quick installation guide.

It describes how to install the whole synnefo stack on two (2) physical nodes, with minimum configuration. It installs synnefo from Debian packages, and assumes the nodes run Debian Squeeze. After successful installation, you will have the following services running:

• Identity Management (Astakos)
• Object Storage Service (Pithos+)
• Compute Service (Cyclades)
• Image Registry Service (Plankton)

and a single unified Web UI to manage them all.

The Volume Storage Service (Archipelago) and the Billing Service (Aquarium) are not released yet.

If you just want to install the Object Storage Service (Pithos+), follow the guide and just stop after the "Testing of Pithos+" section.

Installation of Synnefo / Introduction

We will install the services with the above list's order. Cyclades and Plankton will be installed in a single step (at the end), because at the moment they are contained in the same software component. Furthermore, we will install all services in the first physical node, except Pithos+ which will be installed in the second, due to a conflict between the snf-pithos-app and snf-cyclades-app component (scheduled to be fixed in the next version).

For the rest of the documentation we will refer to the first physical node as "node1" and the second as "node2". We will also assume that their domain names are "node1.example.com" and "node2.example.com" and their IPs are "4.3.2.1" and "4.3.2.2" respectively.

Note

It is import that the two machines are under the same domain name. If they are not, you can do this by editting the file /etc/hosts on both machines, and add the following lines:

4.3.2.1     node1.example.com
4.3.2.2     node2.example.com

General Prerequisites

These are the general synnefo prerequisites, that you need on node1 and node2 and are related to all the services (Astakos, Pithos+, Cyclades, Plankton).

To be able to download all synnefo components you need to add the following lines in your /etc/apt/sources.list file:

deb http://apt.dev.grnet.gr squeeze main

deb-src http://apt.dev.grnet.gr squeeze main

deb http://apt.dev.grnet.gr squeeze-backports main

and import the repo's GPG key:

curl https://dev.grnet.gr/files/apt-grnetdev.pub | apt-key add -

Also add the following line to enable the squeeze-backports repository, which may provide more recent versions of certain packages. The repository is deactivated by default and must be specified expicitly in apt-get operations:

deb http://backports.debian.org/debian-backports squeeze-backports main

You also need a shared directory visible by both nodes. Pithos+ will save all data inside this directory. By 'all data', we mean files, images, and pithos specific mapping data. If you plan to upload more than one basic image, this directory should have at least 50GB of free space. During this guide, we will assume that node1 acts as an NFS server and serves the directory /srv/pithos to node2 (be sure to set no_root_squash flag). Node2 has this directory mounted under /srv/pithos, too.

Before starting the synnefo installation, you will need basic third party software to be installed and configured on the physical nodes. We will describe each node's general prerequisites separately. Any additional configuration, specific to a synnefo service for each node, will be described at the service's section.

Finally, it is required for Cyclades and Ganeti nodes to have synchronized system clocks (e.g. by running ntpd).

Node1

General Synnefo dependencies

• apache (http server)
• gunicorn (WSGI http server)
• postgresql (database)
• rabbitmq (message queue)
• ntp (NTP daemon)
• gevent

You can install apache2, progresql and ntp by running:

# apt-get install apache2 postgresql ntp

Make sure to install gunicorn >= v0.12.2. You can do this by installing from the official debian backports:

# apt-get -t squeeze-backports install gunicorn

Also, make sure to install gevent >= 0.13.6. Again from the debian backports:

# apt-get -t squeeze-backports install python-gevent

On node1, we will create our databases, so you will also need the python-psycopg2 package:

# apt-get install python-psycopg2

To install RabbitMQ>=2.8.4, use the RabbitMQ APT repository by adding the following line to /etc/apt/sources.list:

deb http://www.rabbitmq.com/debian testing main

Add RabbitMQ public key, to trusted key list:

# wget http://www.rabbitmq.com/rabbitmq-signing-key-public.asc
# apt-key add rabbitmq-signing-key-public.asc

Finally, to install the package run:

# apt-get update
# apt-get install rabbitmq-server

Database setup

On node1, we create a database called snf_apps, that will host all django apps related tables. We also create the user synnefo and grant him all privileges on the database. We do this by running:

root@node1:~ # su - postgres
postgres@node1:~ $ psql
postgres=# CREATE DATABASE snf_apps WITH ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C' TEMPLATE=template0;
postgres=# CREATE USER synnefo WITH PASSWORD 'example_passw0rd';
postgres=# GRANT ALL PRIVILEGES ON DATABASE snf_apps TO synnefo;

We also create the database snf_pithos needed by the pithos+ backend and grant the synnefo user all privileges on the database. This database could be created on node2 instead, but we do it on node1 for simplicity. We will create all needed databases on node1 and then node2 will connect to them.

postgres=# CREATE DATABASE snf_pithos WITH ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C' TEMPLATE=template0;
postgres=# GRANT ALL PRIVILEGES ON DATABASE snf_pithos TO synnefo;

Configure the database to listen to all network interfaces. You can do this by editting the file /etc/postgresql/8.4/main/postgresql.conf and change listen_addresses to '*' :

listen_addresses = '*'

Furthermore, edit /etc/postgresql/8.4/main/pg_hba.conf to allow node1 and node2 to connect to the database. Add the following lines under #IPv4 local connections: :

host                all     all     4.3.2.1/32      md5
host                all     all     4.3.2.2/32      md5

Make sure to substitute "4.3.2.1" and "4.3.2.2" with node1's and node2's actual IPs. Now, restart the server to apply the changes:

# /etc/init.d/postgresql restart

Gunicorn setup

Create the file /etc/gunicorn.d/synnefo containing the following:

CONFIG = {
 'mode': 'django',
 'environment': {
   'DJANGO_SETTINGS_MODULE': 'synnefo.settings',
 },
 'working_dir': '/etc/synnefo',
 'user': 'www-data',
 'group': 'www-data',
 'args': (
   '--bind=127.0.0.1:8080',
   '--worker-class=gevent',
   '--workers=8',
   '--log-level=debug',
 ),
}

Warning

Do NOT start the server yet, because it won't find the synnefo.settings module. Also, in case you are using /etc/hosts instead of a DNS to get the hostnames, change --worker-class=gevent to --worker-class=sync. We will start the server after successful installation of astakos. If the server is running:

# /etc/init.d/gunicorn stop

Apache2 setup

Create the file /etc/apache2/sites-available/synnefo containing the following:

<VirtualHost *:80>
    ServerName node1.example.com

    RewriteEngine On
    RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|%0A|%0D).* [NC]
    RewriteRule ^(.*)$ - [F,L]
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Create the file /etc/apache2/sites-available/synnefo-ssl containing the following:

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
    ServerName node1.example.com

    Alias /static "/usr/share/synnefo/static"

    #  SetEnv no-gzip
    #  SetEnv dont-vary

   AllowEncodedSlashes On

   RequestHeader set X-Forwarded-Protocol "https"

<Proxy * >
    Order allow,deny
    Allow from all
</Proxy>

    SetEnv                proxy-sendchunked
    SSLProxyEngine        off
    ProxyErrorOverride    off

    ProxyPass        /static !
    ProxyPass        / http://localhost:8080/ retry=0
    ProxyPassReverse / http://localhost:8080/

    RewriteEngine On
    RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|%0A|%0D).* [NC]
    RewriteRule ^(.*)$ - [F,L]

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>
</IfModule>

Now enable sites and modules by running:

# a2enmod ssl
# a2enmod rewrite
# a2dissite default
# a2ensite synnefo
# a2ensite synnefo-ssl
# a2enmod headers
# a2enmod proxy_http

Warning

Do NOT start/restart the server yet. If the server is running:

# /etc/init.d/apache2 stop

Message Queue setup

The message queue will run on node1, so we need to create the appropriate rabbitmq user. The user is named synnefo and gets full privileges on all exchanges:

# rabbitmqctl add_user synnefo "example_rabbitmq_passw0rd"
# rabbitmqctl set_permissions synnefo ".*" ".*" ".*"

We do not need to initialize the exchanges. This will be done automatically, during the Cyclades setup.

Pithos+ data directory setup

As mentioned in the General Prerequisites section, there is a directory called /srv/pithos visible by both nodes. We create and setup the data directory inside it:

# cd /srv/pithos
# mkdir data
# chown www-data:www-data data
# chmod g+ws data

You are now ready with all general prerequisites concerning node1. Let's go to node2.

Node2

General Synnefo dependencies

• apache (http server)
• gunicorn (WSGI http server)
• postgresql (database)
• ntp (NTP daemon)
• gevent

You can install the above by running:

# apt-get install apache2 postgresql ntp

Make sure to install gunicorn >= v0.12.2. You can do this by installing from the official debian backports:

# apt-get -t squeeze-backports install gunicorn

Also, make sure to install gevent >= 0.13.6. Again from the debian backports:

# apt-get -t squeeze-backports install python-gevent

Node2 will connect to the databases on node1, so you will also need the python-psycopg2 package:

# apt-get install python-psycopg2

Database setup

All databases have been created and setup on node1, so we do not need to take any action here. From node2, we will just connect to them. When you get familiar with the software you may choose to run different databases on different nodes, for performance/scalability/redundancy reasons, but those kind of setups are out of the purpose of this guide.

Gunicorn setup

Create the file /etc/gunicorn.d/synnefo containing the following (same contents as in node1; you can just copy/paste the file):

CONFIG = {
 'mode': 'django',
 'environment': {
  'DJANGO_SETTINGS_MODULE': 'synnefo.settings',
 },
 'working_dir': '/etc/synnefo',
 'user': 'www-data',
 'group': 'www-data',
 'args': (
   '--bind=127.0.0.1:8080',
   '--worker-class=gevent',
   '--workers=4',
   '--log-level=debug',
   '--timeout=43200'
 ),
}

Warning

Do NOT start the server yet, because it won't find the synnefo.settings module. Also, in case you are using /etc/hosts instead of a DNS to get the hostnames, change --worker-class=gevent to --worker-class=sync. We will start the server after successful installation of astakos. If the server is running:

# /etc/init.d/gunicorn stop

Apache2 setup

Create the file /etc/apache2/sites-available/synnefo containing the following:

<VirtualHost *:80>
    ServerName node2.example.com

    RewriteEngine On
    RewriteCond %{THE_REQUEST} ^.*(\\r|\\n|%0A|%0D).* [NC]
    RewriteRule ^(.*)$ - [F,L]
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Create the file synnefo-ssl under /etc/apache2/sites-available/ containing the following:

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
    ServerName node2.example.com

    Alias /static "/usr/share/synnefo/static"

    SetEnv no-gzip
    SetEnv dont-vary
    AllowEncodedSlashes On

    RequestHeader set X-Forwarded-Protocol "https"

    <Proxy * >
        Order allow,deny
        Allow from all
    </Proxy>

    SetEnv                proxy-sendchunked
    SSLProxyEngine        off
    ProxyErrorOverride    off

    ProxyPass        /static !
    ProxyPass        / http://localhost:8080/ retry=0
    ProxyPassReverse / http://localhost:8080/

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>
</IfModule>

As in node1, enable sites and modules by running:

# a2enmod ssl
# a2enmod rewrite
# a2dissite default
# a2ensite synnefo
# a2ensite synnefo-ssl
# a2enmod headers
# a2enmod proxy_http

Warning

Do NOT start/restart the server yet. If the server is running:

# /etc/init.d/apache2 stop

We are now ready with all general prerequisites for node2. Now that we have finished with all general prerequisites for both nodes, we can start installing the services. First, let's install Astakos on node1.

Installation of Astakos on node1

To install astakos, grab the package from our repository (make sure you made the additions needed in your /etc/apt/sources.list file, as described previously), by running:

# apt-get install snf-astakos-app snf-quotaholder-app snf-pithos-backend

After successful installation of snf-astakos-app, make sure that also snf-webproject has been installed (marked as "Recommended" package). By default Debian installs "Recommended" packages, but if you have changed your configuration and the package didn't install automatically, you should explicitly install it manually running:

# apt-get install snf-webproject

The reason snf-webproject is "Recommended" and not a hard dependency, is to give the experienced administrator the ability to install Synnefo in a custom made Django project. This corner case concerns only very advanced users that know what they are doing and want to experiment with synnefo.

Configuration of Astakos

Conf Files

After astakos is successfully installed, you will find the directory /etc/synnefo and some configuration files inside it. The files contain commented configuration options, which are the default options. While installing new snf-* components, new configuration files will appear inside the directory. In this guide (and for all services), we will edit only the minimum necessary configuration options, to reflect our setup. Everything else will remain as is.

After getting familiar with synnefo, you will be able to customize the software as you wish and fits your needs. Many options are available, to empower the administrator with extensively customizable setups.

For the snf-webproject component (installed as an astakos dependency), we need the following:

Edit /etc/synnefo/10-snf-webproject-database.conf. You will need to uncomment and edit the DATABASES block to reflect our database:

DATABASES = {
 'default': {
     # 'postgresql_psycopg2', 'postgresql','mysql', 'sqlite3' or 'oracle'
     'ENGINE': 'postgresql_psycopg2',
     # ATTENTION: This *must* be the absolute path if using sqlite3.
     # See: http://docs.djangoproject.com/en/dev/ref/settings/#name
     'NAME': 'snf_apps',
     'USER': 'synnefo',                      # Not used with sqlite3.
     'PASSWORD': 'example_passw0rd',         # Not used with sqlite3.
     # Set to empty string for localhost. Not used with sqlite3.
     'HOST': '4.3.2.1',
     # Set to empty string for default. Not used with sqlite3.
     'PORT': '5432',
 }
}

Edit /etc/synnefo/10-snf-webproject-deploy.conf. Uncomment and edit SECRET_KEY. This is a Django specific setting which is used to provide a seed in secret-key hashing algorithms. Set this to a random string of your choise and keep it private:

SECRET_KEY = 'sy6)mw6a7x%n)-example_secret_key#zzk4jo6f2=uqu!1o%)'

For astakos specific configuration, edit the following options in /etc/synnefo/20-snf-astakos-app-settings.conf :

ASTAKOS_DEFAULT_ADMIN_EMAIL = None

ASTAKOS_COOKIE_DOMAIN = '.example.com'

ASTAKOS_BASEURL = 'https://node1.example.com'

The ASTAKOS_COOKIE_DOMAIN should be the base url of our domain (for all services). ASTAKOS_BASEURL is the astakos home page.

ASTAKOS_DEFAULT_ADMIN_EMAIL refers to the administrator's email. Every time a new account is created a notification is sent to this email. For this we need access to a running mail server, so we have disabled it for now by setting its value to None. For more informations on this, read the relative :ref:`section <mail-server>`.

Note

For the purpose of this guide, we don't enable recaptcha authentication. If you would like to enable it, you have to edit the following options:

ASTAKOS_RECAPTCHA_PUBLIC_KEY = 'example_recaptcha_public_key!@#$%^&*('
ASTAKOS_RECAPTCHA_PRIVATE_KEY = 'example_recaptcha_private_key!@#$%^&*('
ASTAKOS_RECAPTCHA_USE_SSL = True
ASTAKOS_RECAPTCHA_ENABLED = True

For the ASTAKOS_RECAPTCHA_PUBLIC_KEY and ASTAKOS_RECAPTCHA_PRIVATE_KEY go to https://www.google.com/recaptcha/admin/create and create your own pair.

Then edit /etc/synnefo/20-snf-astakos-app-cloudbar.conf :

CLOUDBAR_LOCATION = 'https://node1.example.com/static/im/cloudbar/'

CLOUDBAR_SERVICES_URL = 'https://node1.example.com/im/get_services'

CLOUDBAR_MENU_URL = 'https://node1.example.com/im/get_menu'

Those settings have to do with the black cloudbar endpoints and will be described in more detail later on in this guide. For now, just edit the domain to point at node1 which is where we have installed Astakos.

If you are an advanced user and want to use the Shibboleth Authentication method, read the relative :ref:`section <shibboleth-auth>`.

Note

Because Cyclades and Astakos are running on the same machine in our example, we have to deactivate the CSRF verification. We can do so by adding to /etc/synnefo/99-local.conf:

MIDDLEWARE_CLASSES.remove('django.middleware.csrf.CsrfViewMiddleware')
TEMPLATE_CONTEXT_PROCESSORS.remove('django.core.context_processors.csrf')

Since version 0.13 you need to configure some basic settings for the new Quota feature.

Specifically:

Edit /etc/synnefo/20-snf-astakos-app-settings.conf:

QUOTAHOLDER_URL = 'https://node1.example.com/quotaholder/v'
QUOTAHOLDER_TOKEN = 'aExampleTokenJbFm12w'
ASTAKOS_QUOTAHOLDER_TOKEN = 'aExampleTokenJbFm12w'
ASTAKOS_QUOTAHOLDER_URL = 'https://node1.example.com/quotaholder/v'

Enable Pooling

This section can be bypassed, but we strongly recommend you apply the following, since they result in a significant performance boost.

Synnefo includes a pooling DBAPI driver for PostgreSQL, as a thin wrapper around Psycopg2. This allows independent Django requests to reuse pooled DB connections, with significant performance gains.

To use, first monkey-patch psycopg2. For Django, run this before the DATABASES setting in /etc/synnefo/10-snf-webproject-database.conf:

from synnefo.lib.db.pooled_psycopg2 import monkey_patch_psycopg2
monkey_patch_psycopg2()

Since we are running with greenlets, we should modify psycopg2 behavior, so it works properly in a greenlet context:

from synnefo.lib.db.psyco_gevent import make_psycopg_green
make_psycopg_green()

Use the Psycopg2 driver as usual. For Django, this means using django.db.backends.postgresql_psycopg2 without any modifications. To enable connection pooling, pass a nonzero synnefo_poolsize option to the DBAPI driver, through DATABASES.OPTIONS in Django.

All the above will result in an /etc/synnefo/10-snf-webproject-database.conf file that looks like this:

# Monkey-patch psycopg2
from synnefo.lib.db.pooled_psycopg2 import monkey_patch_psycopg2
monkey_patch_psycopg2()

# If running with greenlets
from synnefo.lib.db.psyco_gevent import make_psycopg_green
make_psycopg_green()

DATABASES = {
 'default': {
     # 'postgresql_psycopg2', 'postgresql','mysql', 'sqlite3' or 'oracle'
     'ENGINE': 'postgresql_psycopg2',
     'OPTIONS': {'synnefo_poolsize': 8},

     # ATTENTION: This *must* be the absolute path if using sqlite3.
     # See: http://docs.djangoproject.com/en/dev/ref/settings/#name
     'NAME': 'snf_apps',
     'USER': 'synnefo',                      # Not used with sqlite3.
     'PASSWORD': 'example_passw0rd',         # Not used with sqlite3.
     # Set to empty string for localhost. Not used with sqlite3.
     'HOST': '4.3.2.1',
     # Set to empty string for default. Not used with sqlite3.
     'PORT': '5432',
 }
}

Database Initialization

After configuration is done, we initialize the database by running:

# snf-manage syncdb

At this example we don't need to create a django superuser, so we select [no] to the question. After a successful sync, we run the migration needed for astakos:

# snf-manage migrate im

Then, we load the pre-defined user groups

# snf-manage loaddata groups

Services Registration

When the database is ready, we configure the elements of the Astakos cloudbar, to point to our future services:

# snf-manage service-add "~okeanos home" https://node1.example.com/im/ home-icon.png
# snf-manage service-add "cyclades" https://node1.example.com/ui/
# snf-manage service-add "pithos+" https://node2.example.com/ui/

Servers Initialization

Finally, we initialize the servers on node1:

root@node1:~ # /etc/init.d/gunicorn restart
root@node1:~ # /etc/init.d/apache2 restart

We have now finished the Astakos setup. Let's test it now.

Testing of Astakos

Open your favorite browser and go to:

http://node1.example.com/im

If this redirects you to https://node1.example.com/im/ and you can see the "welcome" door of Astakos, then you have successfully setup Astakos.

Let's create our first user. At the homepage click the "CREATE ACCOUNT" button and fill all your data at the sign up form. Then click "SUBMIT". You should now see a green box on the top, which informs you that you made a successful request and the request has been sent to the administrators. So far so good, let's assume that you created the user with username user@example.com.

Now we need to activate that user. Return to a command prompt at node1 and run:

root@node1:~ # snf-manage user-list

This command should show you a list with only one user; the one we just created. This user should have an id with a value of 1. It should also have an "active" status with the value of 0 (inactive). Now run:

root@node1:~ # snf-manage user-update --set-active 1

This modifies the active value to 1, and actually activates the user. When running in production, the activation is done automatically with different types of moderation, that Astakos supports. You can see the moderation methods (by invitation, whitelists, matching regexp, etc.) at the Astakos specific documentation. In production, you can also manually activate a user, by sending him/her an activation email. See how to do this at the :ref:`User activation <user_activation>` section.

Now let's go back to the homepage. Open http://node1.example.com/im/ with your browser again. Try to sign in using your new credentials. If the astakos menu appears and you can see your profile, then you have successfully setup Astakos.

Let's continue to install Pithos+ now.

Installation of Pithos+ on node2

To install pithos+, grab the packages from our repository (make sure you made the additions needed in your /etc/apt/sources.list file, as described previously), by running:

# apt-get install snf-pithos-app snf-pithos-backend

After successful installation of snf-pithos-app, make sure that also snf-webproject has been installed (marked as "Recommended" package). Refer to the "Installation of Astakos on node1" section, if you don't remember why this should happen. Now, install the pithos web interface:

# apt-get install snf-pithos-webclient

This package provides the standalone pithos web client. The web client is the web UI for pithos+ and will be accessible by clicking "pithos+" on the Astakos interface's cloudbar, at the top of the Astakos homepage.

Configuration of Pithos+

Conf Files

After pithos+ is successfully installed, you will find the directory /etc/synnefo and some configuration files inside it, as you did in node1 after installation of astakos. Here, you will not have to change anything that has to do with snf-common or snf-webproject. Everything is set at node1. You only need to change settings that have to do with pithos+. Specifically:

Edit /etc/synnefo/20-snf-pithos-app-settings.conf. There you need to set this options:

PITHOS_BACKEND_DB_CONNECTION = 'postgresql://synnefo:example_passw0rd@node1.example.com:5432/snf_pithos'

PITHOS_BACKEND_BLOCK_PATH = '/srv/pithos/data'

PITHOS_AUTHENTICATION_URL = 'https://node1.example.com/im/authenticate'
PITHOS_AUTHENTICATION_USERS = None

PITHOS_SERVICE_TOKEN = 'pithos_service_token22w=='
PITHOS_USER_CATALOG_URL = 'https://node1.example.com/user_catalogs'
PITHOS_USER_FEEDBACK_URL = 'https://node1.example.com/feedback'
PITHOS_USER_LOGIN_URL = 'https://node1.example.com/login'

PITHOS_QUOTAHOLDER_URL = 'https://node1.example.com/quotaholder/v'
PITHOS_QUOTAHOLDER_TOKEN = 'aExampleTokenJbFm12w'
PITHOS_USE_QUOTAHOLDER = True

# Set to False if astakos & pithos are on the same host
#PITHOS_PROXY_USER_SERVICES = True

The PITHOS_BACKEND_DB_CONNECTION option tells to the pithos+ app where to find the pithos+ backend database. Above we tell pithos+ that its database is snf_pithos at node1 and to connect as user synnefo with password example_passw0rd. All those settings where setup during node1's "Database setup" section.

The PITHOS_BACKEND_BLOCK_PATH option tells to the pithos+ app where to find the pithos+ backend data. Above we tell pithos+ to store its data under /srv/pithos/data, which is visible by both nodes. We have already setup this directory at node1's "Pithos+ data directory setup" section.

The PITHOS_AUTHENTICATION_URL option tells to the pithos+ app in which URI is available the astakos authentication api. If not set, pithos+ tries to authenticate using the PITHOS_AUTHENTICATION_USERS user pool.

The PITHOS_SERVICE_TOKEN should be the Pithos+ token returned by running on the Astakos node (node1 in our case):

# snf-manage service-list

The token has been generated automatically during the :ref:`Pithos+ service registration <services-reg>`.

Then we need to setup the web UI and connect it to astakos. To do so, edit /etc/synnefo/20-snf-pithos-webclient-settings.conf:

PITHOS_UI_LOGIN_URL = "https://node1.example.com/im/login?next="
PITHOS_UI_FEEDBACK_URL = "https://node2.example.com/feedback"

The PITHOS_UI_LOGIN_URL option tells the client where to redirect you, if you are not logged in. The PITHOS_UI_FEEDBACK_URL option points at the pithos+ feedback form. Astakos already provides a generic feedback form for all services, so we use this one.

Then edit /etc/synnefo/20-snf-pithos-webclient-cloudbar.conf, to connect the pithos+ web UI with the astakos web UI (through the top cloudbar):

CLOUDBAR_LOCATION = 'https://node1.example.com/static/im/cloudbar/'
PITHOS_UI_CLOUDBAR_ACTIVE_SERVICE = '3'
CLOUDBAR_SERVICES_URL = 'https://node1.example.com/im/get_services'
CLOUDBAR_MENU_URL = 'https://node1.example.com/im/get_menu'

The CLOUDBAR_LOCATION tells the client where to find the astakos common cloudbar.

The PITHOS_UI_CLOUDBAR_ACTIVE_SERVICE points to an already registered Astakos service. You can see all :ref:`registered services <services-reg>` by running on the Astakos node (node1):

# snf-manage service-list

The value of PITHOS_UI_CLOUDBAR_ACTIVE_SERVICE should be the pithos service's id as shown by the above command, in our case 3.

The CLOUDBAR_SERVICES_URL and CLOUDBAR_MENU_URL options are used by the pithos+ web client to get from astakos all the information needed to fill its own cloudbar. So we put our astakos deployment urls there.

Pooling and Greenlets

Pithos is pooling-ready without the need of further configuration, because it doesn't use a Django DB. It pools HTTP connections to Astakos and pithos backend objects for access to the Pithos DB.

However, as in Astakos, since we are running with Greenlets, it is also recommended to modify psycopg2 behavior so it works properly in a greenlet context. This means adding the following lines at the top of your /etc/synnefo/10-snf-webproject-database.conf file:

from synnefo.lib.db.psyco_gevent import make_psycopg_green
make_psycopg_green()

Furthermore, add the --worker-class=gevent (or --worker-class=sync as mentioned above, depending on your setup) argument on your /etc/gunicorn.d/synnefo configuration file. The file should look something like this:

CONFIG = {
 'mode': 'django',
 'environment': {
   'DJANGO_SETTINGS_MODULE': 'synnefo.settings',
 },
 'working_dir': '/etc/synnefo',
 'user': 'www-data',
 'group': 'www-data',
 'args': (
   '--bind=127.0.0.1:8080',
   '--workers=4',
   '--worker-class=gevent',
   '--log-level=debug',
   '--timeout=43200'
 ),
}

Stamp Database Revision

Pithos uses the alembic database migrations tool.

After a sucessful installation, we should stamp it at the most recent revision, so that future migrations know where to start upgrading in the migration history.

First, find the most recent revision in the migration history:

root@node2:~ # pithos-migrate history
2a309a9a3438 -> 27381099d477 (head), alter public add column url
165ba3fbfe53 -> 2a309a9a3438, fix statistics negative population
3dd56e750a3 -> 165ba3fbfe53, update account in paths
230f8ce9c90f -> 3dd56e750a3, Fix latest_version
8320b1c62d9 -> 230f8ce9c90f, alter nodes add column latest version
None -> 8320b1c62d9, create index nodes.parent

Finally, we stamp it with the one found in the previous step:

root@node2:~ # pithos-migrate stamp 27381099d477

Servers Initialization