Statistics
| Branch: | Tag: | Revision:

root / docs / quick-install-admin-guide.rst @ d5426b9b

History | View | Annotate | Download (76.4 kB)

1
.. _quick-install-admin-guide:
2

    
3
Administrator's Quick Installation Guide
4
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5

    
6
This is the Administrator's quick installation guide.
7

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

    
13
    * Identity Management (Astakos)
14
    * Object Storage Service (Pithos+)
15
    * Compute Service (Cyclades)
16
    * Image Registry Service (Plankton)
17

    
18
and a single unified Web UI to manage them all.
19

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

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

    
26

    
27
Installation of Synnefo / Introduction
28
======================================
29

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

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

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

    
46
    .. code-block:: console
47

    
48
        4.3.2.1     node1.example.com
49
        4.3.2.2     node2.example.com
50

    
51

    
52
General Prerequisites
53
=====================
54

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

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

    
61
| ``deb http://apt2.dev.grnet.gr stable/``
62
| ``deb-src http://apt2.dev.grnet.gr stable/``
63

    
64
and import the repo's GPG key:
65

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

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

    
73
| ``deb http://backports.debian.org/debian-backports squeeze-backports main``
74

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

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

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

    
92
Node1
93
-----
94

    
95
General Synnefo dependencies
96
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
97

    
98
    * apache (http server)
99
    * gunicorn (WSGI http server)
100
    * postgresql (database)
101
    * rabbitmq (message queue)
102
    * ntp (NTP daemon)
103
    * gevent
104

    
105
You can install apache2, progresql and ntp by running:
106

    
107
.. code-block:: console
108

    
109
   # apt-get install apache2 postgresql ntp
110

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

    
114
.. code-block:: console
115

    
116
   # apt-get -t squeeze-backports install gunicorn
117

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

    
120
.. code-block:: console
121

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

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

    
127
.. code-block:: console
128

    
129
   # apt-get install python-psycopg2
130

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

    
134
.. code-block:: console
135

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

    
138
Add RabbitMQ public key, to trusted key list:
139

    
140
.. code-block:: console
141

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

    
145
Finally, to install the package run:
146

    
147
.. code-block:: console
148

    
149
  # apt-get update
150
  # apt-get install rabbitmq-server
151

    
152
Database setup
153
~~~~~~~~~~~~~~
154

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

    
159
.. code-block:: console
160

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

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

    
172
.. code-block:: console
173

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

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

    
181
.. code-block:: console
182

    
183
    listen_addresses = '*'
184

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

    
189
.. code-block:: console
190

    
191
    host		all	all	4.3.2.1/32	md5
192
    host		all	all	4.3.2.2/32	md5
193

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

    
197
.. code-block:: console
198

    
199
   # /etc/init.d/postgresql restart
200

    
201
Gunicorn setup
202
~~~~~~~~~~~~~~
203

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

    
206
.. code-block:: console
207

    
208
    CONFIG = {
209
     'mode': 'django',
210
     'environment': {
211
       'DJANGO_SETTINGS_MODULE': 'synnefo.settings',
212
     },
213
     'working_dir': '/etc/synnefo',
214
     'user': 'www-data',
215
     'group': 'www-data',
216
     'args': (
217
       '--bind=127.0.0.1:8080',
218
       '--worker-class=gevent',
219
       '--workers=8',
220
       '--log-level=debug',
221
     ),
222
    }
223

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

    
230
       # /etc/init.d/gunicorn stop
231

    
232
Apache2 setup
233
~~~~~~~~~~~~~
234

    
235
Create the file ``/etc/apache2/sites-available/synnefo`` containing the
236
following:
237

    
238
.. code-block:: console
239

    
240
    <VirtualHost *:80>
241
        ServerName node1.example.com
242

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

    
249
Create the file ``/etc/apache2/sites-available/synnefo-ssl`` containing the
250
following:
251

    
252
.. code-block:: console
253

    
254
    <IfModule mod_ssl.c>
255
    <VirtualHost _default_:443>
256
        ServerName node1.example.com
257

    
258
        Alias /static "/usr/share/synnefo/static"
259

    
260
        #  SetEnv no-gzip
261
        #  SetEnv dont-vary
262

    
263
       AllowEncodedSlashes On
264

    
265
       RequestHeader set X-Forwarded-Protocol "https"
266

    
267
    <Proxy * >
268
        Order allow,deny
269
        Allow from all
270
    </Proxy>
271

    
272
        SetEnv                proxy-sendchunked
273
        SSLProxyEngine        off
274
        ProxyErrorOverride    off
275

    
276
        ProxyPass        /static !
277
        ProxyPass        / http://localhost:8080/ retry=0
278
        ProxyPassReverse / http://localhost:8080/
279

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

    
284
        SSLEngine on
285
        SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
286
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
287
    </VirtualHost>
288
    </IfModule>
289

    
290
Now enable sites and modules by running:
291

    
292
.. code-block:: console
293

    
294
   # a2enmod ssl
295
   # a2enmod rewrite
296
   # a2dissite default
297
   # a2ensite synnefo
298
   # a2ensite synnefo-ssl
299
   # a2enmod headers
300
   # a2enmod proxy_http
301

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

    
304
       # /etc/init.d/apache2 stop
305

    
306
.. _rabbitmq-setup:
307

    
308
Message Queue setup
309
~~~~~~~~~~~~~~~~~~~
310

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

    
315
.. code-block:: console
316

    
317
   # rabbitmqctl add_user synnefo "example_rabbitmq_passw0rd"
318
   # rabbitmqctl set_permissions synnefo ".*" ".*" ".*"
319

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

    
323
Pithos+ data directory setup
324
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
325

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

    
330
.. code-block:: console
331

    
332
   # cd /srv/pithos
333
   # mkdir data
334
   # chown www-data:www-data data
335
   # chmod g+ws data
336

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

    
340
Node2
341
-----
342

    
343
General Synnefo dependencies
344
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
345

    
346
    * apache (http server)
347
    * gunicorn (WSGI http server)
348
    * postgresql (database)
349
    * ntp (NTP daemon)
350
    * gevent
351

    
352
You can install the above by running:
353

    
354
.. code-block:: console
355

    
356
   # apt-get install apache2 postgresql ntp
357

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

    
361
.. code-block:: console
362

    
363
   # apt-get -t squeeze-backports install gunicorn
364

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

    
367
.. code-block:: console
368

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

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

    
374
.. code-block:: console
375

    
376
   # apt-get install python-psycopg2
377

    
378
Database setup
379
~~~~~~~~~~~~~~
380

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

    
387
Gunicorn setup
388
~~~~~~~~~~~~~~
389

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

    
393
.. code-block:: console
394

    
395
    CONFIG = {
396
     'mode': 'django',
397
     'environment': {
398
      'DJANGO_SETTINGS_MODULE': 'synnefo.settings',
399
     },
400
     'working_dir': '/etc/synnefo',
401
     'user': 'www-data',
402
     'group': 'www-data',
403
     'args': (
404
       '--bind=127.0.0.1:8080',
405
       '--worker-class=gevent',
406
       '--workers=4',
407
       '--log-level=debug',
408
       '--timeout=43200'
409
     ),
410
    }
411

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

    
418
       # /etc/init.d/gunicorn stop
419

    
420
Apache2 setup
421
~~~~~~~~~~~~~
422

    
423
Create the file ``/etc/apache2/sites-available/synnefo`` containing the
424
following:
425

    
426
.. code-block:: console
427

    
428
    <VirtualHost *:80>
429
        ServerName node2.example.com
430

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

    
437
Create the file ``synnefo-ssl`` under ``/etc/apache2/sites-available/``
438
containing the following:
439

    
440
.. code-block:: console
441

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

    
446
        Alias /static "/usr/share/synnefo/static"
447

    
448
        SetEnv no-gzip
449
        SetEnv dont-vary
450
        AllowEncodedSlashes On
451

    
452
        RequestHeader set X-Forwarded-Protocol "https"
453

    
454
        <Proxy * >
455
            Order allow,deny
456
            Allow from all
457
        </Proxy>
458

    
459
        SetEnv                proxy-sendchunked
460
        SSLProxyEngine        off
461
        ProxyErrorOverride    off
462

    
463
        ProxyPass        /static !
464
        ProxyPass        / http://localhost:8080/ retry=0
465
        ProxyPassReverse / http://localhost:8080/
466

    
467
        SSLEngine on
468
        SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
469
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
470
    </VirtualHost>
471
    </IfModule>
472

    
473
As in node1, enable sites and modules by running:
474

    
475
.. code-block:: console
476

    
477
   # a2enmod ssl
478
   # a2enmod rewrite
479
   # a2dissite default
480
   # a2ensite synnefo
481
   # a2ensite synnefo-ssl
482
   # a2enmod headers
483
   # a2enmod proxy_http
484

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

    
487
       # /etc/init.d/apache2 stop
488

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

    
493

    
494
Installation of Astakos on node1
495
================================
496

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

    
501
.. code-block:: console
502

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

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

    
511
.. code-block:: console
512

    
513
   # apt-get install snf-webproject
514

    
515
The reason snf-webproject is "Recommended" and not a hard dependency, is to give
516
the experienced administrator the ability to install Synnefo in a custom made
517
`Django <https://www.djangoproject.com/>`_ project. This corner case
518
concerns only very advanced users that know what they are doing and want to
519
experiment with synnefo.
520

    
521

    
522
.. _conf-astakos:
523

    
524
Configuration of Astakos
525
========================
526

    
527
Conf Files
528
----------
529

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

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

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

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

    
547
.. code-block:: console
548

    
549
    DATABASES = {
550
     'default': {
551
         # 'postgresql_psycopg2', 'postgresql','mysql', 'sqlite3' or 'oracle'
552
         'ENGINE': 'postgresql_psycopg2',
553
         # ATTENTION: This *must* be the absolute path if using sqlite3.
554
         # See: http://docs.djangoproject.com/en/dev/ref/settings/#name
555
         'NAME': 'snf_apps',
556
         'USER': 'synnefo',                      # Not used with sqlite3.
557
         'PASSWORD': 'example_passw0rd',         # Not used with sqlite3.
558
         # Set to empty string for localhost. Not used with sqlite3.
559
         'HOST': '4.3.2.1',
560
         # Set to empty string for default. Not used with sqlite3.
561
         'PORT': '5432',
562
     }
563
    }
564

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

    
570
.. code-block:: console
571

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

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

    
577
.. code-block:: console
578

    
579
    ASTAKOS_DEFAULT_ADMIN_EMAIL = None
580

    
581
    ASTAKOS_COOKIE_DOMAIN = '.example.com'
582

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

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

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

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

    
597
    .. code-block:: console
598

    
599
        ASTAKOS_RECAPTCHA_PUBLIC_KEY = 'example_recaptcha_public_key!@#$%^&*('
600
        ASTAKOS_RECAPTCHA_PRIVATE_KEY = 'example_recaptcha_private_key!@#$%^&*('
601
        ASTAKOS_RECAPTCHA_USE_SSL = True
602
        ASTAKOS_RECAPTCHA_ENABLED = True
603

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

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

    
609
.. code-block:: console
610

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

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

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

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

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

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

    
629
    .. code-block:: console
630

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

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

    
637
Specifically:
638

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

    
641
.. code-block:: console
642

    
643
    QUOTAHOLDER_URL = 'https://node1.example.com/quotaholder/v'
644
    QUOTAHOLDER_TOKEN = 'aExampleTokenJbFm12w'
645
    ASTAKOS_QUOTAHOLDER_TOKEN = 'aExampleTokenJbFm12w'
646
    ASTAKOS_QUOTAHOLDER_URL = 'https://node1.example.com/quotaholder/v'
647

    
648
Enable Pooling
649
--------------
650

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

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

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

    
661
.. code-block:: console
662

    
663
    from synnefo.lib.db.pooled_psycopg2 import monkey_patch_psycopg2
664
    monkey_patch_psycopg2()
665

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

    
669
.. code-block:: console
670

    
671
    from synnefo.lib.db.psyco_gevent import make_psycopg_green
672
    make_psycopg_green()
673

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

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

    
682
.. code-block:: console
683

    
684
    # Monkey-patch psycopg2
685
    from synnefo.lib.db.pooled_psycopg2 import monkey_patch_psycopg2
686
    monkey_patch_psycopg2()
687

    
688
    # If running with greenlets
689
    from synnefo.lib.db.psyco_gevent import make_psycopg_green
690
    make_psycopg_green()
691

    
692
    DATABASES = {
693
     'default': {
694
         # 'postgresql_psycopg2', 'postgresql','mysql', 'sqlite3' or 'oracle'
695
         'ENGINE': 'postgresql_psycopg2',
696
         'OPTIONS': {'synnefo_poolsize': 8},
697

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

    
710
Database Initialization
711
-----------------------
712

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

    
715
.. code-block:: console
716

    
717
    # snf-manage syncdb
718

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

    
723
.. code-block:: console
724

    
725
    # snf-manage migrate im
726

    
727
Then, we load the pre-defined user groups
728

    
729
.. code-block:: console
730

    
731
    # snf-manage loaddata groups
732

    
733
.. _services-reg:
734

    
735
Services Registration
736
---------------------
737

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

    
741
.. code-block:: console
742

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

    
747
Servers Initialization
748
----------------------
749

    
750
Finally, we initialize the servers on node1:
751

    
752
.. code-block:: console
753

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

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

    
759

    
760
Testing of Astakos
761
==================
762

    
763
Open your favorite browser and go to:
764

    
765
``http://node1.example.com/im``
766

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

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

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

    
778
.. code-block:: console
779

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

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

    
786
.. code-block:: console
787

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

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

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

    
803
Let's continue to install Pithos+ now.
804

    
805

    
806
Installation of Pithos+ on node2
807
================================
808

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

    
813
.. code-block:: console
814

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

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

    
822
.. code-block:: console
823

    
824
   # apt-get install snf-pithos-webclient
825

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

    
830

    
831
.. _conf-pithos:
832

    
833
Configuration of Pithos+
834
========================
835

    
836
Conf Files
837
----------
838

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

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

    
848
.. code-block:: console
849

    
850
   ASTAKOS_URL = 'https://node1.example.com/'
851

    
852
   PITHOS_BACKEND_DB_CONNECTION = 'postgresql://synnefo:example_passw0rd@node1.example.com:5432/snf_pithos'
853
   PITHOS_BACKEND_BLOCK_PATH = '/srv/pithos/data'
854

    
855

    
856
   PITHOS_SERVICE_TOKEN = 'pithos_service_token22w=='
857
   PITHOS_USER_CATALOG_URL = 'https://node1.example.com/user_catalogs'
858
   PITHOS_USER_FEEDBACK_URL = 'https://node1.example.com/feedback'
859
   PITHOS_USER_LOGIN_URL = 'https://node1.example.com/login'
860

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

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

    
868

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

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

    
880
The ``ASTAKOS_URL`` option tells to the pithos+ app in which URI
881
is available the astakos authentication api.
882

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

    
886
.. code-block:: console
887

    
888
   # snf-manage service-list
889

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

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

    
896
.. code-block:: console
897

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

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

    
906
The ``PITHOS_UPDATE_MD5`` option by default disables the computation of the
907
object checksums. This results to improved performance during object uploading.
908
However, if compatibility with the OpenStack Object Storage API is important
909
then it should be changed to ``True``.
910

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

    
914
.. code-block:: console
915

    
916
    CLOUDBAR_LOCATION = 'https://node1.example.com/static/im/cloudbar/'
917
    PITHOS_UI_CLOUDBAR_ACTIVE_SERVICE = '3'
918
    CLOUDBAR_SERVICES_URL = 'https://node1.example.com/im/get_services'
919
    CLOUDBAR_MENU_URL = 'https://node1.example.com/im/get_menu'
920

    
921
The ``CLOUDBAR_LOCATION`` tells the client where to find the astakos common
922
cloudbar.
923

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

    
928
.. code-block:: console
929

    
930
   # snf-manage service-list
931

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

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

    
939
Pooling and Greenlets
940
---------------------
941

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

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

    
951
.. code-block:: console
952

    
953
    from synnefo.lib.db.psyco_gevent import make_psycopg_green
954
    make_psycopg_green()
955

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

    
961
.. code-block:: console
962

    
963
    CONFIG = {
964
     'mode': 'django',
965
     'environment': {
966
       'DJANGO_SETTINGS_MODULE': 'synnefo.settings',
967
     },
968
     'working_dir': '/etc/synnefo',
969
     'user': 'www-data',
970
     'group': 'www-data',
971
     'args': (
972
       '--bind=127.0.0.1:8080',
973
       '--workers=4',
974
       '--worker-class=gevent',
975
       '--log-level=debug',
976
       '--timeout=43200'
977
     ),
978
    }
979

    
980
Stamp Database Revision
981
-----------------------
982

    
983
Pithos uses the alembic_ database migrations tool.
984

    
985
.. _alembic: http://alembic.readthedocs.org
986

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

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

    
993
.. code-block:: console
994

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

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

    
1005
.. code-block:: console
1006

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

    
1009
Servers Initialization
1010
----------------------
1011

    
1012
After configuration is done, we initialize the servers on node2:
1013

    
1014
.. code-block:: console
1015

    
1016
    root@node2:~ # /etc/init.d/gunicorn restart
1017
    root@node2:~ # /etc/init.d/apache2 restart
1018

    
1019
You have now finished the Pithos+ setup. Let's test it now.
1020

    
1021

    
1022
Testing of Pithos+
1023
==================
1024

    
1025
Open your browser and go to the Astakos homepage:
1026

    
1027
``http://node1.example.com/im``
1028

    
1029
Login, and you will see your profile page. Now, click the "pithos+" link on the
1030
top black cloudbar. If everything was setup correctly, this will redirect you
1031
to:
1032

    
1033

    
1034
and you will see the blue interface of the Pithos+ application.  Click the
1035
orange "Upload" button and upload your first file. If the file gets uploaded
1036
successfully, then this is your first sign of a successful Pithos+ installation.
1037
Go ahead and experiment with the interface to make sure everything works
1038
correctly.
1039

    
1040
You can also use the Pithos+ clients to sync data from your Windows PC or MAC.
1041

    
1042
If you don't stumble on any problems, then you have successfully installed
1043
Pithos+, which you can use as a standalone File Storage Service.
1044

    
1045
If you would like to do more, such as:
1046

    
1047
    * Spawning VMs
1048
    * Spawning VMs from Images stored on Pithos+
1049
    * Uploading your custom Images to Pithos+
1050
    * Spawning VMs from those custom Images
1051
    * Registering existing Pithos+ files as Images
1052
    * Connect VMs to the Internet
1053
    * Create Private Networks
1054
    * Add VMs to Private Networks
1055

    
1056
please continue with the rest of the guide.
1057

    
1058

    
1059
Cyclades (and Plankton) Prerequisites
1060
=====================================
1061

    
1062
Before proceeding with the Cyclades (and Plankton) installation, make sure you
1063
have successfully set up Astakos and Pithos+ first, because Cyclades depends
1064
on them. If you don't have a working Astakos and Pithos+ installation yet,
1065
please return to the :ref:`top <quick-install-admin-guide>` of this guide.
1066

    
1067
Besides Astakos and Pithos+, you will also need a number of additional working
1068
prerequisites, before you start the Cyclades installation.
1069

    
1070
Ganeti
1071
------
1072

    
1073
`Ganeti <http://code.google.com/p/ganeti/>`_ handles the low level VM management
1074
for Cyclades, so Cyclades requires a working Ganeti installation at the backend.
1075
Please refer to the
1076
`ganeti documentation <http://docs.ganeti.org/ganeti/2.5/html>`_ for all the
1077
gory details. A successful Ganeti installation concludes with a working
1078
:ref:`GANETI-MASTER <GANETI_NODES>` and a number of :ref:`GANETI-NODEs
1079
<GANETI_NODES>`.
1080

    
1081
The above Ganeti cluster can run on different physical machines than node1 and
1082
node2 and can scale independently, according to your needs.
1083

    
1084
For the purpose of this guide, we will assume that the :ref:`GANETI-MASTER
1085
<GANETI_NODES>` runs on node1 and is VM-capable. Also, node2 is a
1086
:ref:`GANETI-NODE <GANETI_NODES>` and is Master-capable and VM-capable too.
1087

    
1088
We highly recommend that you read the official Ganeti documentation, if you are
1089
not familiar with Ganeti.
1090

    
1091
Unfortunatelly, the current stable version of the stock Ganeti (v2.6.2) doesn't
1092
support IP pool management. This feature will be available in Ganeti >= 2.7.
1093
Synnefo depends on the IP pool functionality of Ganeti, so you have to use
1094
GRNET provided packages until stable 2.7 is out. To do so:
1095

    
1096
.. code-block:: console
1097

    
1098
   # apt-get install snf-ganeti ganeti-htools
1099
   # rmmod -f drbd && modprobe drbd minor_count=255 usermode_helper=/bin/true
1100

    
1101
You should have:
1102

    
1103
Ganeti >= 2.6.2+ippool11+hotplug5+extstorage3+rdbfix1+kvmfix2-1
1104

    
1105
We assume that Ganeti will use the KVM hypervisor. After installing Ganeti on
1106
both nodes, choose a domain name that resolves to a valid floating IP (let's
1107
say it's ``ganeti.node1.example.com``). Make sure node1 and node2 have same
1108
dsa/rsa keys and authorised_keys for password-less root ssh between each other.
1109
If not then skip passing --no-ssh-init but be aware that it will replace
1110
/root/.ssh/* related files and you might lose access to master node. Also,
1111
make sure there is an lvm volume group named ``ganeti`` that will host your
1112
VMs' disks. Finally, setup a bridge interface on the host machines (e.g: br0).
1113
Then run on node1:
1114

    
1115
.. code-block:: console
1116

    
1117
    root@node1:~ # gnt-cluster init --enabled-hypervisors=kvm --no-ssh-init \
1118
                    --no-etc-hosts --vg-name=ganeti --nic-parameters link=br0 \
1119
                    --master-netdev eth0 ganeti.node1.example.com
1120
    root@node1:~ # gnt-cluster modify --default-iallocator hail
1121
    root@node1:~ # gnt-cluster modify --hypervisor-parameters kvm:kernel_path=
1122
    root@node1:~ # gnt-cluster modify --hypervisor-parameters kvm:vnc_bind_address=0.0.0.0
1123

    
1124
    root@node1:~ # gnt-node add --no-ssh-key-check --master-capable=yes \
1125
                    --vm-capable=yes node2.example.com
1126
    root@node1:~ # gnt-cluster modify --disk-parameters=drbd:metavg=ganeti
1127
    root@node1:~ # gnt-group modify --disk-parameters=drbd:metavg=ganeti default
1128

    
1129
For any problems you may stumble upon installing Ganeti, please refer to the
1130
`official documentation <http://docs.ganeti.org/ganeti/2.5/html>`_. Installation
1131
of Ganeti is out of the scope of this guide.
1132

    
1133
.. _cyclades-install-snfimage:
1134

    
1135
snf-image
1136
---------
1137

    
1138
Installation
1139
~~~~~~~~~~~~
1140
For :ref:`Cyclades <cyclades>` to be able to launch VMs from specified Images,
1141
you need the :ref:`snf-image <snf-image>` OS Definition installed on *all*
1142
VM-capable Ganeti nodes. This means we need :ref:`snf-image <snf-image>` on
1143
node1 and node2. You can do this by running on *both* nodes:
1144

    
1145
.. code-block:: console
1146

    
1147
   # apt-get install snf-image snf-pithos-backend python-psycopg2
1148

    
1149
snf-image also needs the `snf-pithos-backend <snf-pithos-backend>`, to be able
1150
to handle image files stored on Pithos+. It also needs `python-psycopg2` to be
1151
able to access the Pithos+ database. This is why, we also install them on *all*
1152
VM-capable Ganeti nodes.
1153

    
1154
.. warning:: snf-image uses ``curl`` for handling URLs. This means that it will
1155
    not  work out of the box if you try to use URLs served by servers which do
1156
    not have a valid certificate. To circumvent this you should edit the file
1157
    ``/etc/default/snf-image``. Change ``#CURL="curl"`` to ``CURL="curl -k"``.
1158

    
1159
After `snf-image` has been installed successfully, create the helper VM by
1160
running on *both* nodes:
1161

    
1162
.. code-block:: console
1163

    
1164
   # snf-image-update-helper
1165

    
1166
This will create all the needed files under ``/var/lib/snf-image/helper/`` for
1167
snf-image to run successfully, and it may take a few minutes depending on your
1168
Internet connection.
1169

    
1170
Configuration
1171
~~~~~~~~~~~~~
1172
snf-image supports native access to Images stored on Pithos+. This means that
1173
it can talk directly to the Pithos+ backend, without the need of providing a
1174
public URL. More details, are described in the next section. For now, the only
1175
thing we need to do, is configure snf-image to access our Pithos+ backend.
1176

    
1177
To do this, we need to set the corresponding variables in
1178
``/etc/default/snf-image``, to reflect our Pithos+ setup:
1179

    
1180
.. code-block:: console
1181

    
1182
    PITHOS_DB="postgresql://synnefo:example_passw0rd@node1.example.com:5432/snf_pithos"
1183

    
1184
    PITHOS_DATA="/srv/pithos/data"
1185

    
1186
If you have installed your Ganeti cluster on different nodes than node1 and
1187
node2 make sure that ``/srv/pithos/data`` is visible by all of them.
1188

    
1189
If you would like to use Images that are also/only stored locally, you need to
1190
save them under ``IMAGE_DIR``, however this guide targets Images stored only on
1191
Pithos+.
1192

    
1193
Testing
1194
~~~~~~~
1195
You can test that snf-image is successfully installed by running on the
1196
:ref:`GANETI-MASTER <GANETI_NODES>` (in our case node1):
1197

    
1198
.. code-block:: console
1199

    
1200
   # gnt-os diagnose
1201

    
1202
This should return ``valid`` for snf-image.
1203

    
1204
If you are interested to learn more about snf-image's internals (and even use
1205
it alongside Ganeti without Synnefo), please see
1206
`here <https://code.grnet.gr/projects/snf-image/wiki>`_ for information
1207
concerning installation instructions, documentation on the design and
1208
implementation, and supported Image formats.
1209

    
1210
.. _snf-image-images:
1211

    
1212
Actual Images for snf-image
1213
---------------------------
1214

    
1215
Now that snf-image is installed successfully we need to provide it with some
1216
Images. :ref:`snf-image <snf-image>` supports Images stored in ``extdump``,
1217
``ntfsdump`` or ``diskdump`` format. We recommend the use of the ``diskdump``
1218
format. For more information about snf-image Image formats see `here
1219
<https://code.grnet.gr/projects/snf-image/wiki/Image_Format>`_.
1220

    
1221
:ref:`snf-image <snf-image>` also supports three (3) different locations for the
1222
above Images to be stored:
1223

    
1224
    * Under a local folder (usually an NFS mount, configurable as ``IMAGE_DIR``
1225
      in :file:`/etc/default/snf-image`)
1226
    * On a remote host (accessible via public URL e.g: http://... or ftp://...)
1227
    * On Pithos+ (accessible natively, not only by its public URL)
1228

    
1229
For the purpose of this guide, we will use the Debian Squeeze Base Image found
1230
on the official `snf-image page
1231
<https://code.grnet.gr/projects/snf-image/wiki#Sample-Images>`_. The image is
1232
of type ``diskdump``. We will store it in our new Pithos+ installation.
1233

    
1234
To do so, do the following:
1235

    
1236
a) Download the Image from the official snf-image page.
1237

    
1238
b) Upload the Image to your Pithos+ installation, either using the Pithos+ Web
1239
   UI or the command line client `kamaki
1240
   <http://www.synnefo.org/docs/kamaki/latest/index.html>`_.
1241

    
1242
Once the Image is uploaded successfully, download the Image's metadata file
1243
from the official snf-image page. You will need it, for spawning a VM from
1244
Ganeti, in the next section.
1245

    
1246
Of course, you can repeat the procedure to upload more Images, available from
1247
the `official snf-image page
1248
<https://code.grnet.gr/projects/snf-image/wiki#Sample-Images>`_.
1249

    
1250
.. _ganeti-with-pithos-images:
1251

    
1252
Spawning a VM from a Pithos+ Image, using Ganeti
1253
------------------------------------------------
1254

    
1255
Now, it is time to test our installation so far. So, we have Astakos and
1256
Pithos+ installed, we have a working Ganeti installation, the snf-image
1257
definition installed on all VM-capable nodes and a Debian Squeeze Image on
1258
Pithos+. Make sure you also have the `metadata file
1259
<https://pithos.okeanos.grnet.gr/public/gwqcv>`_ for this image.
1260

    
1261
Run on the :ref:`GANETI-MASTER's <GANETI_NODES>` (node1) command line:
1262

    
1263
.. code-block:: console
1264

    
1265
   # gnt-instance add -o snf-image+default --os-parameters \
1266
                      img_passwd=my_vm_example_passw0rd,img_format=diskdump,img_id="pithos://UUID/pithos/debian_base-6.0-7-x86_64.diskdump",img_properties='{"OSFAMILY":"linux"\,"ROOT_PARTITION":"1"}' \
1267
                      -t plain --disk 0:size=2G --no-name-check --no-ip-check \
1268
                      testvm1
1269

    
1270
In the above command:
1271

    
1272
 * ``img_passwd``: the arbitrary root password of your new instance
1273
 * ``img_format``: set to ``diskdump`` to reflect the type of the uploaded Image
1274
 * ``img_id``: If you want to deploy an Image stored on Pithos+ (our case), this
1275
               should have the format ``pithos://<UUID>/<container>/<filename>``:
1276
               * ``username``: ``user@example.com`` (defined during Astakos sign up)
1277
               * ``container``: ``pithos`` (default, if the Web UI was used)
1278
               * ``filename``: the name of file (visible also from the Web UI)
1279
 * ``img_properties``: taken from the metadata file. Used only the two mandatory
1280
                       properties ``OSFAMILY`` and ``ROOT_PARTITION``. `Learn more
1281
                       <https://code.grnet.gr/projects/snf-image/wiki/Image_Format#Image-Properties>`_
1282

    
1283
If the ``gnt-instance add`` command returns successfully, then run:
1284

    
1285
.. code-block:: console
1286

    
1287
   # gnt-instance info testvm1 | grep "console connection"
1288

    
1289
to find out where to connect using VNC. If you can connect successfully and can
1290
login to your new instance using the root password ``my_vm_example_passw0rd``,
1291
then everything works as expected and you have your new Debian Base VM up and
1292
running.
1293

    
1294
If ``gnt-instance add`` fails, make sure that snf-image is correctly configured
1295
to access the Pithos+ database and the Pithos+ backend data (newer versions
1296
require UUID instead of a username). Another issue you may encounter is that in
1297
relatively slow setups, you may need to raise the default HELPER_*_TIMEOUTS in
1298
/etc/default/snf-image. Also, make sure you gave the correct ``img_id`` and
1299
``img_properties``. If ``gnt-instance add`` succeeds but you cannot connect,
1300
again find out what went wrong. Do *NOT* proceed to the next steps unless you
1301
are sure everything works till this point.
1302

    
1303
If everything works, you have successfully connected Ganeti with Pithos+. Let's
1304
move on to networking now.
1305

    
1306
.. warning::
1307

    
1308
    You can bypass the networking sections and go straight to
1309
    :ref:`Cyclades Ganeti tools <cyclades-gtools>`, if you do not want to setup
1310
    the Cyclades Network Service, but only the Cyclades Compute Service
1311
    (recommended for now).
1312

    
1313
Networking Setup Overview
1314
-------------------------
1315

    
1316
This part is deployment-specific and must be customized based on the specific
1317
needs of the system administrator. However, to do so, the administrator needs
1318
to understand how each level handles Virtual Networks, to be able to setup the
1319
backend appropriately, before installing Cyclades. To do so, please read the
1320
:ref:`Network <networks>` section before proceeding.
1321

    
1322
Since synnefo 0.11 all network actions are managed with the snf-manage
1323
network-* commands. This needs the underlying setup (Ganeti, nfdhcpd,
1324
snf-network, bridges, vlans) to be already configured correctly. The only
1325
actions needed in this point are:
1326

    
1327
a) Have Ganeti with IP pool management support installed.
1328

    
1329
b) Install :ref:`snf-network <snf-network>`, which provides a synnefo specific kvm-ifup script, etc.
1330

    
1331
c) Install :ref:`nfdhcpd <nfdhcpd>`, which serves DHCP requests of the VMs.
1332

    
1333
In order to test that everything is setup correctly before installing Cyclades,
1334
we will make some testing actions in this section, and the actual setup will be
1335
done afterwards with snf-manage commands.
1336

    
1337
.. _snf-network:
1338

    
1339
snf-network
1340
~~~~~~~~~~~
1341

    
1342
snf-network includes `kvm-vif-bridge` script that is invoked every time
1343
a tap (a VM's NIC) is created. Based on environment variables passed by
1344
Ganeti it issues various commands depending on the network type the NIC is
1345
connected to and sets up a corresponding dhcp lease.
1346

    
1347
Install snf-network on all Ganeti nodes:
1348

    
1349
.. code-block:: console
1350

    
1351
   # apt-get install snf-network
1352

    
1353
Then, in :file:`/etc/default/snf-network` set:
1354

    
1355
.. code-block:: console
1356

    
1357
   MAC_MASK=ff:ff:f0:00:00:00
1358

    
1359
.. _nfdhcpd:
1360

    
1361
nfdhcpd
1362
~~~~~~~
1363

    
1364
Each NIC's IP is chosen by Ganeti (with IP pool management support).
1365
`kvm-vif-bridge` script sets up dhcp leases and when the VM boots and
1366
makes a dhcp request, iptables will mangle the packet and `nfdhcpd` will
1367
create a dhcp response.
1368

    
1369
.. code-block:: console
1370

    
1371
   # apt-get install nfqueue-bindings-python=0.3+physindev-1
1372
   # apt-get install nfdhcpd
1373

    
1374
Edit ``/etc/nfdhcpd/nfdhcpd.conf`` to reflect your network configuration. At
1375
least, set the ``dhcp_queue`` variable to ``42`` and the ``nameservers``
1376
variable to your DNS IP/s. Those IPs will be passed as the DNS IP/s of your new
1377
VMs. Once you are finished, restart the server on all nodes:
1378

    
1379
.. code-block:: console
1380

    
1381
   # /etc/init.d/nfdhcpd restart
1382

    
1383
If you are using ``ferm``, then you need to run the following:
1384

    
1385
.. code-block:: console
1386

    
1387
   # echo "@include 'nfdhcpd.ferm';" >> /etc/ferm/ferm.conf
1388
   # /etc/init.d/ferm restart
1389

    
1390
or make sure to run after boot:
1391

    
1392
.. code-block:: console
1393

    
1394
   # iptables -t mangle -A PREROUTING -p udp -m udp --dport 67 -j NFQUEUE --queue-num 42
1395

    
1396
and if you have IPv6 enabled:
1397

    
1398
.. code-block:: console
1399

    
1400
   # ip6tables -t mangle -A PREROUTING -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j NFQUEUE --queue-num 43
1401
   # ip6tables -t mangle -A PREROUTING -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j NFQUEUE --queue-num 44
1402

    
1403
You can check which clients are currently served by nfdhcpd by running:
1404

    
1405
.. code-block:: console
1406

    
1407
   # kill -SIGUSR1 `cat /var/run/nfdhcpd/nfdhcpd.pid`
1408

    
1409
When you run the above, then check ``/var/log/nfdhcpd/nfdhcpd.log``.
1410

    
1411
Public Network Setup
1412
--------------------
1413

    
1414
To achieve basic networking the simplest way is to have a common bridge (e.g.
1415
``br0``, on the same collision domain with the router) where all VMs will
1416
connect to. Packets will be "forwarded" to the router and then to the Internet.
1417
If you want a more advanced setup (ip-less routing and proxy-arp plese refer to
1418
:ref:`Network <networks>` section).
1419

    
1420
Physical Host Setup
1421
~~~~~~~~~~~~~~~~~~~
1422

    
1423
Assuming ``eth0`` on both hosts is the public interface (directly connected
1424
to the router), run on every node:
1425

    
1426
.. code-block:: console
1427

    
1428
   # apt-get install vlan
1429
   # brctl addbr br0
1430
   # ip link set br0 up
1431
   # vconfig add eth0 100
1432
   # ip link set eth0.100 up
1433
   # brctl addif br0 eth0.100
1434

    
1435

    
1436
Testing a Public Network
1437
~~~~~~~~~~~~~~~~~~~~~~~~
1438

    
1439
Let's assume, that you want to assign IPs from the ``5.6.7.0/27`` range to you
1440
new VMs, with ``5.6.7.1`` as the router's gateway. In Ganeti you can add the
1441
network by running:
1442

    
1443
.. code-block:: console
1444

    
1445
   # gnt-network add --network=5.6.7.0/27 --gateway=5.6.7.1 --network-type=public --tags=nfdhcpd test-net-public
1446

    
1447
Then, connect the network to all your nodegroups. We assume that we only have
1448
one nodegroup (``default``) in our Ganeti cluster:
1449

    
1450
.. code-block:: console
1451

    
1452
   # gnt-network connect test-net-public default bridged br0
1453

    
1454
Now, it is time to test that the backend infrastracture is correctly setup for
1455
the Public Network. We will add a new VM, the same way we did it on the
1456
previous testing section. However, now will also add one NIC, configured to be
1457
managed from our previously defined network. Run on the GANETI-MASTER (node1):
1458

    
1459
.. code-block:: console
1460

    
1461
   # gnt-instance add -o snf-image+default --os-parameters \
1462
                      img_passwd=my_vm_example_passw0rd,img_format=diskdump,img_id="pithos://UUID/pithos/debian_base-6.0-7-x86_64.diskdump",img_properties='{"OSFAMILY":"linux"\,"ROOT_PARTITION":"1"}' \
1463
                      -t plain --disk 0:size=2G --no-name-check --no-ip-check \
1464
                      --net 0:ip=pool,network=test-net-public \
1465
                      testvm2
1466

    
1467
If the above returns successfully, connect to the new VM and run:
1468

    
1469
.. code-block:: console
1470

    
1471
   root@testvm2:~ # ip addr
1472
   root@testvm2:~ # ip route
1473
   root@testvm2:~ # cat /etc/resolv.conf
1474

    
1475
to check IP address (5.6.7.2), IP routes (default via 5.6.7.1) and DNS config
1476
(nameserver option in nfdhcpd.conf). This shows correct configuration of
1477
ganeti, snf-network and nfdhcpd.
1478

    
1479
Now ping the outside world. If this works too, then you have also configured
1480
correctly your physical host and router.
1481

    
1482
Make sure everything works as expected, before proceeding with the Private
1483
Networks setup.
1484

    
1485
.. _private-networks-setup:
1486

    
1487
Private Networks Setup
1488
----------------------
1489

    
1490
Synnefo supports two types of private networks:
1491

    
1492
 - based on MAC filtering
1493
 - based on physical VLANs
1494

    
1495
Both types provide Layer 2 isolation to the end-user.
1496

    
1497
For the first type a common bridge (e.g. ``prv0``) is needed while for the
1498
second a range of bridges (e.g. ``prv1..prv100``) each bridged on a different
1499
physical VLAN. To this end to assure isolation among end-users' private networks
1500
each has to have different MAC prefix (for the filtering to take place) or to be
1501
"connected" to a different bridge (VLAN actually).
1502

    
1503
Physical Host Setup
1504
~~~~~~~~~~~~~~~~~~~
1505

    
1506
In order to create the necessary VLAN/bridges, one for MAC filtered private
1507
networks and various (e.g. 20) for private networks based on physical VLANs,
1508
run on every node:
1509

    
1510
Assuming ``eth0`` of both hosts are somehow (via cable/switch with VLANs
1511
configured correctly) connected together, run on every node:
1512

    
1513
.. code-block:: console
1514

    
1515
   # modprobe 8021q
1516
   # $iface=eth0
1517
   # for prv in $(seq 0 20); do
1518
        vlan=$prv
1519
        bridge=prv$prv
1520
        vconfig add $iface $vlan
1521
        ifconfig $iface.$vlan up
1522
        brctl addbr $bridge
1523
        brctl setfd $bridge 0
1524
        brctl addif $bridge $iface.$vlan
1525
        ifconfig $bridge up
1526
      done
1527

    
1528
The above will do the following :
1529

    
1530
 * provision 21 new bridges: ``prv0`` - ``prv20``
1531
 * provision 21 new vlans: ``eth0.0`` - ``eth0.20``
1532
 * add the corresponding vlan to the equivalent bridge
1533

    
1534
You can run ``brctl show`` on both nodes to see if everything was setup
1535
correctly.
1536

    
1537
Testing the Private Networks
1538
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1539

    
1540
To test the Private Networks, we will create two instances and put them in the
1541
same Private Networks (one MAC Filtered and one Physical VLAN). This means
1542
that the instances will have a second NIC connected to the ``prv0``
1543
pre-provisioned bridge and a third to ``prv1``.
1544

    
1545
We run the same command as in the Public Network testing section, but with one
1546
more argument for the second NIC:
1547

    
1548
.. code-block:: console
1549

    
1550
   # gnt-network add --network=192.168.1.0/24 --mac-prefix=aa:00:55 --network-type=private --tags=nfdhcpd,private-filtered test-net-prv-mac
1551
   # gnt-network connect test-net-prv-mac default bridged prv0
1552

    
1553
   # gnt-network add --network=10.0.0.0/24 --tags=nfdhcpd --network-type=private test-net-prv-vlan
1554
   # gnt-network connect test-net-prv-vlan default bridged prv1
1555

    
1556
   # gnt-instance add -o snf-image+default --os-parameters \
1557
                      img_passwd=my_vm_example_passw0rd,img_format=diskdump,img_id="pithos://UUID/pithos/debian_base-6.0-7-x86_64.diskdump",img_properties='{"OSFAMILY":"linux"\,"ROOT_PARTITION":"1"}' \
1558
                      -t plain --disk 0:size=2G --no-name-check --no-ip-check \
1559
                      --net 0:ip=pool,network=test-net-public \
1560
                      --net 1:ip=pool,network=test-net-prv-mac \
1561
                      --net 2:ip=none,network=test-net-prv-vlan \
1562
                      testvm3
1563

    
1564
   # gnt-instance add -o snf-image+default --os-parameters \
1565
                      img_passwd=my_vm_example_passw0rd,img_format=diskdump,img_id="pithos://UUID/pithos/debian_base-6.0-7-x86_64.diskdump",img_properties='{"OSFAMILY":"linux"\,"ROOT_PARTITION":"1"}' \
1566
                      -t plain --disk 0:size=2G --no-name-check --no-ip-check \
1567
                      --net 0:ip=pool,network=test-net-public \
1568
                      --net 1:ip=pool,network=test-net-prv-mac \
1569
                      --net 2:ip=none,network=test-net-prv-vlan \
1570
                      testvm4
1571

    
1572
Above, we create two instances with first NIC connected to the internet, their
1573
second NIC connected to a MAC filtered private Network and their third NIC
1574
connected to the first Physical VLAN Private Network. Now, connect to the
1575
instances using VNC and make sure everything works as expected:
1576

    
1577
 a) The instances have access to the public internet through their first eth
1578
    interface (``eth0``), which has been automatically assigned a public IP.
1579

    
1580
 b) ``eth1`` will have mac prefix ``aa:00:55``, while ``eth2`` default one (``aa:00:00``)
1581

    
1582
 c) ip link set ``eth1``/``eth2`` up
1583

    
1584
 d) dhclient ``eth1``/``eth2``
1585

    
1586
 e) On testvm3  ping 192.168.1.2/10.0.0.2
1587

    
1588
If everything works as expected, then you have finished the Network Setup at the
1589
backend for both types of Networks (Public & Private).
1590

    
1591
.. _cyclades-gtools:
1592

    
1593
Cyclades Ganeti tools
1594
---------------------
1595

    
1596
In order for Ganeti to be connected with Cyclades later on, we need the
1597
`Cyclades Ganeti tools` available on all Ganeti nodes (node1 & node2 in our
1598
case). You can install them by running in both nodes:
1599

    
1600
.. code-block:: console
1601

    
1602
   # apt-get install snf-cyclades-gtools
1603

    
1604
This will install the following:
1605

    
1606
 * ``snf-ganeti-eventd`` (daemon to publish Ganeti related messages on RabbitMQ)
1607
 * ``snf-ganeti-hook`` (all necessary hooks under ``/etc/ganeti/hooks``)
1608
 * ``snf-progress-monitor`` (used by ``snf-image`` to publish progress messages)
1609

    
1610
Configure ``snf-cyclades-gtools``
1611
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1612

    
1613
The package will install the ``/etc/synnefo/20-snf-cyclades-gtools-backend.conf``
1614
configuration file. At least we need to set the RabbitMQ endpoint for all tools
1615
that need it:
1616

    
1617
.. code-block:: console
1618

    
1619
  AMQP_HOSTS=["amqp://synnefo:example_rabbitmq_passw0rd@node1.example.com:5672"]
1620

    
1621
The above variables should reflect your :ref:`Message Queue setup
1622
<rabbitmq-setup>`. This file should be editted in all Ganeti nodes.
1623

    
1624
Connect ``snf-image`` with ``snf-progress-monitor``
1625
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1626

    
1627
Finally, we need to configure ``snf-image`` to publish progress messages during
1628
the deployment of each Image. To do this, we edit ``/etc/default/snf-image`` and
1629
set the corresponding variable to ``snf-progress-monitor``:
1630

    
1631
.. code-block:: console
1632

    
1633
   PROGRESS_MONITOR="snf-progress-monitor"
1634

    
1635
This file should be editted in all Ganeti nodes.
1636

    
1637
.. _rapi-user:
1638

    
1639
Synnefo RAPI user
1640
-----------------
1641

    
1642
As a last step before installing Cyclades, create a new RAPI user that will
1643
have ``write`` access. Cyclades will use this user to issue commands to Ganeti,
1644
so we will call the user ``cyclades`` with password ``example_rapi_passw0rd``.
1645
You can do this, by first running:
1646

    
1647
.. code-block:: console
1648

    
1649
   # echo -n 'cyclades:Ganeti Remote API:example_rapi_passw0rd' | openssl md5
1650

    
1651
and then putting the output in ``/var/lib/ganeti/rapi/users`` as follows:
1652

    
1653
.. code-block:: console
1654

    
1655
   cyclades {HA1}55aec7050aa4e4b111ca43cb505a61a0 write
1656

    
1657
More about Ganeti's RAPI users `here.
1658
<http://docs.ganeti.org/ganeti/2.5/html/rapi.html#introduction>`_
1659

    
1660
You have now finished with all needed Prerequisites for Cyclades (and
1661
Plankton). Let's move on to the actual Cyclades installation.
1662

    
1663

    
1664
Installation of Cyclades (and Plankton) on node1
1665
================================================
1666

    
1667
This section describes the installation of Cyclades. Cyclades is Synnefo's
1668
Compute service. Plankton (the Image Registry service) will get installed
1669
automatically along with Cyclades, because it is contained in the same Synnefo
1670
component right now.
1671

    
1672
We will install Cyclades (and Plankton) on node1. To do so, we install the
1673
corresponding package by running on node1:
1674

    
1675
.. code-block:: console
1676

    
1677
   # apt-get install snf-cyclades-app memcached python-memcache
1678

    
1679
If all packages install successfully, then Cyclades and Plankton are installed
1680
and we proceed with their configuration.
1681

    
1682
Since version 0.13, Synnefo uses the VMAPI in order to prevent sensitive data
1683
needed by 'snf-image' to be stored in Ganeti configuration (e.g. VM password).
1684
This is achieved by storing all sensitive information to a CACHE backend and
1685
exporting it via VMAPI. The cache entries are invalidated after the first
1686
request. Synnefo uses `memcached <http://memcached.org/>`_ as a
1687
`Django <https://www.djangoproject.com/>`_ cache backend.
1688

    
1689
Configuration of Cyclades (and Plankton)
1690
========================================
1691

    
1692
Conf files
1693
----------
1694

    
1695
After installing Cyclades, a number of new configuration files will appear under
1696
``/etc/synnefo/`` prefixed with ``20-snf-cyclades-app-``. We will describe here
1697
only the minimal needed changes to result with a working system. In general,
1698
sane defaults have been chosen for the most of the options, to cover most of the
1699
common scenarios. However, if you want to tweak Cyclades feel free to do so,
1700
once you get familiar with the different options.
1701

    
1702
Edit ``/etc/synnefo/20-snf-cyclades-app-api.conf``:
1703

    
1704
.. code-block:: console
1705

    
1706
   ASTAKOS_URL = 'https://node1.example.com/'
1707

    
1708
   # Set to False if astakos & cyclades are on the same host
1709
   CYCLADES_PROXY_USER_SERVICES = False
1710

    
1711
The ``ASTAKOS_URL`` denotes the authentication endpoint for Cyclades and is set
1712
to point to Astakos (this should have the same value with Pithos+'s
1713
``ASTAKOS_URL``, setup :ref:`previously <conf-pithos>`).
1714

    
1715
.. warning::
1716

    
1717
   All services must match the quotaholder token and url configured for
1718
   quotaholder.
1719

    
1720
TODO: Document the Network Options here
1721

    
1722
Edit ``/etc/synnefo/20-snf-cyclades-app-cloudbar.conf``:
1723

    
1724
.. code-block:: console
1725

    
1726
   CLOUDBAR_LOCATION = 'https://node1.example.com/static/im/cloudbar/'
1727
   CLOUDBAR_ACTIVE_SERVICE = '2'
1728
   CLOUDBAR_SERVICES_URL = 'https://node1.example.com/im/get_services'
1729
   CLOUDBAR_MENU_URL = 'https://account.node1.example.com/im/get_menu'
1730

    
1731
``CLOUDBAR_LOCATION`` tells the client where to find the Astakos common
1732
cloudbar. The ``CLOUDBAR_SERVICES_URL`` and ``CLOUDBAR_MENU_URL`` options are
1733
used by the Cyclades Web UI to get from Astakos all the information needed to
1734
fill its own cloudbar. So, we put our Astakos deployment urls there. All the
1735
above should have the same values we put in the corresponding variables in
1736
``/etc/synnefo/20-snf-pithos-webclient-cloudbar.conf`` on the previous
1737
:ref:`Pithos configuration <conf-pithos>` section.
1738

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

    
1743
.. code-block:: console
1744

    
1745
   # snf-manage service-list
1746

    
1747
The value of ``CLOUDBAR_ACTIVE_SERVICE`` should be the cyclades service's
1748
``id`` as shown by the above command, in our case ``2``.
1749

    
1750
Edit ``/etc/synnefo/20-snf-cyclades-app-plankton.conf``:
1751

    
1752
.. code-block:: console
1753

    
1754
   BACKEND_DB_CONNECTION = 'postgresql://synnefo:example_passw0rd@node1.example.com:5432/snf_pithos'
1755
   BACKEND_BLOCK_PATH = '/srv/pithos/data/'
1756

    
1757
In this file we configure the Plankton Service. ``BACKEND_DB_CONNECTION``
1758
denotes the Pithos+ database (where the Image files are stored). So we set that
1759
to point to our Pithos+ database. ``BACKEND_BLOCK_PATH`` denotes the actual
1760
Pithos+ data location.
1761

    
1762
Edit ``/etc/synnefo/20-snf-cyclades-app-queues.conf``:
1763

    
1764
.. code-block:: console
1765

    
1766
   AMQP_HOSTS=["amqp://synnefo:example_rabbitmq_passw0rd@node1.example.com:5672"]
1767

    
1768
The above settings denote the Message Queue. Those settings should have the same
1769
values as in ``/etc/synnefo/10-snf-cyclades-gtools-backend.conf`` file, and
1770
reflect our :ref:`Message Queue setup <rabbitmq-setup>`.
1771

    
1772
Edit ``/etc/synnefo/20-snf-cyclades-app-ui.conf``:
1773

    
1774
.. code-block:: console
1775

    
1776
   UI_LOGIN_URL = "https://node1.example.com/im/login"
1777
   UI_LOGOUT_URL = "https://node1.example.com/im/logout"
1778

    
1779
The ``UI_LOGIN_URL`` option tells the Cyclades Web UI where to redirect users,
1780
if they are not logged in. We point that to Astakos.
1781

    
1782
The ``UI_LOGOUT_URL`` option tells the Cyclades Web UI where to redirect the
1783
user when he/she logs out. We point that to Astakos, too.
1784

    
1785
Edit ``/etc/synnefo/20-snf-cyclades-app-quotas.conf``:
1786

    
1787
.. code-block:: console
1788

    
1789
   CYCLADES_USE_QUOTAHOLDER = True
1790
   CYCLADES_QUOTAHOLDER_URL = 'https://node1.example.com/quotaholder/v'
1791
   CYCLADES_QUOTAHOLDER_TOKEN = 'aExampleTokenJbFm12w'
1792

    
1793
Edit ``/etc/synnefo/20-snf-cyclades-app-vmapi.conf``:
1794

    
1795
.. code-block:: console
1796

    
1797
   VMAPI_CACHE_BACKEND = "memcached://127.0.0.1:11211/?timeout=3600"
1798
   VMAPI_BASE_URL = "https://node1.example.com"
1799

    
1800
Edit ``/etc/default/vncauthproxy``:
1801

    
1802
.. code-block:: console
1803

    
1804
   CHUID="nobody:www-data"
1805

    
1806
We have now finished with the basic Cyclades and Plankton configuration.
1807

    
1808
Database Initialization
1809
-----------------------
1810

    
1811
Once Cyclades is configured, we sync the database:
1812

    
1813
.. code-block:: console
1814

    
1815
   $ snf-manage syncdb
1816
   $ snf-manage migrate
1817

    
1818
and load the initial server flavors:
1819

    
1820
.. code-block:: console
1821

    
1822
   $ snf-manage loaddata flavors
1823

    
1824
If everything returns successfully, our database is ready.
1825

    
1826
Add the Ganeti backend
1827
----------------------
1828

    
1829
In our installation we assume that we only have one Ganeti cluster, the one we
1830
setup earlier.  At this point you have to add this backend (Ganeti cluster) to
1831
cyclades assuming that you have setup the :ref:`Rapi User <rapi-user>`
1832
correctly.
1833

    
1834
.. code-block:: console
1835

    
1836
   $ snf-manage backend-add --clustername=ganeti.node1.example.com --user=cyclades --pass=example_rapi_passw0rd
1837

    
1838
You can see everything has been setup correctly by running:
1839

    
1840
.. code-block:: console
1841

    
1842
   $ snf-manage backend-list
1843

    
1844
Enable the new backend by running:
1845

    
1846
.. code-block::
1847

    
1848
   $ snf-manage backend-modify --drained False 1
1849

    
1850
.. warning:: Since version 0.13, the backend is set to "drained" by default.
1851
    This means that you cannot add VMs to it. The reason for this is that the
1852
    nodes should be unavailable to Synnefo until the Administrator explicitly
1853
    releases them. To change this setting, use ``snf-manage backend-modify
1854
    --drained False <backend-id>``.
1855

    
1856
If something is not set correctly, you can modify the backend with the
1857
``snf-manage backend-modify`` command. If something has gone wrong, you could
1858
modify the backend to reflect the Ganeti installation by running:
1859

    
1860
.. code-block:: console
1861

    
1862
   $ snf-manage backend-modify --clustername "ganeti.node1.example.com"
1863
                               --user=cyclades
1864
                               --pass=example_rapi_passw0rd
1865
                               1
1866

    
1867
``clustername`` denotes the Ganeti-cluster's name. We provide the corresponding
1868
domain that resolves to the master IP, than the IP itself, to ensure Cyclades
1869
can talk to Ganeti even after a Ganeti master-failover.
1870

    
1871
``user`` and ``pass`` denote the RAPI user's username and the RAPI user's
1872
password.  Once we setup the first backend to point at our Ganeti cluster, we
1873
update the Cyclades backends status by running:
1874

    
1875
.. code-block:: console
1876

    
1877
   $ snf-manage backend-update-status
1878

    
1879
Cyclades can manage multiple Ganeti backends, but for the purpose of this
1880
guide,we won't get into more detail regarding mulitple backends. If you want to
1881
learn more please see /*TODO*/.
1882

    
1883
Add a Public Network
1884
----------------------
1885

    
1886
Cyclades supports different Public Networks on different Ganeti backends.
1887
After connecting Cyclades with our Ganeti cluster, we need to setup a Public
1888
Network for this Ganeti backend (`id = 1`). The basic setup is to bridge every
1889
created NIC on a bridge. After having a bridge (e.g. br0) created in every
1890
backend node edit Synnefo setting CUSTOM_BRIDGED_BRIDGE to 'br0':
1891

    
1892
.. code-block:: console
1893

    
1894
   $ snf-manage network-create --subnet=5.6.7.0/27 \
1895
                               --gateway=5.6.7.1 \
1896
                               --subnet6=2001:648:2FFC:1322::/64 \
1897
                               --gateway6=2001:648:2FFC:1322::1 \
1898
                               --public --dhcp --flavor=CUSTOM \
1899
                               --link=br0 --mode=bridged \
1900
                               --name=public_network \
1901
                               --backend-id=1
1902

    
1903
This will create the Public Network on both Cyclades and the Ganeti backend. To
1904
make sure everything was setup correctly, also run:
1905

    
1906
.. code-block:: console
1907

    
1908
   $ snf-manage reconcile-networks
1909

    
1910
You can see all available networks by running:
1911

    
1912
.. code-block:: console
1913

    
1914
   $ snf-manage network-list
1915

    
1916
and inspect each network's state by running:
1917

    
1918
.. code-block:: console
1919

    
1920
   $ snf-manage network-inspect <net_id>
1921

    
1922
Finally, you can see the networks from the Ganeti perspective by running on the
1923
Ganeti MASTER:
1924

    
1925
.. code-block:: console
1926

    
1927
   $ gnt-network list
1928
   $ gnt-network info <network_name>
1929

    
1930
Create pools for Private Networks
1931
---------------------------------
1932

    
1933
To prevent duplicate assignment of resources to different private networks,
1934
Cyclades supports two types of pools:
1935

    
1936
 - MAC prefix Pool
1937
 - Bridge Pool
1938

    
1939
As long as those resourses have been provisioned, admin has to define two
1940
these pools in Synnefo:
1941

    
1942

    
1943
.. code-block:: console
1944

    
1945
   root@testvm1:~ # snf-manage pool-create --type=mac-prefix --base=aa:00:0 --size=65536
1946

    
1947
   root@testvm1:~ # snf-manage pool-create --type=bridge --base=prv --size=20
1948

    
1949
Also, change the Synnefo setting in :file:`20-snf-cyclades-app-api.conf`:
1950

    
1951
.. code-block:: console
1952

    
1953
   DEFAULT_MAC_FILTERED_BRIDGE = 'prv0'
1954

    
1955
Servers restart
1956
---------------
1957

    
1958
Restart gunicorn on node1:
1959

    
1960
.. code-block:: console
1961

    
1962
   # /etc/init.d/gunicorn restart
1963

    
1964
Now let's do the final connections of Cyclades with Ganeti.
1965

    
1966
``snf-dispatcher`` initialization
1967
---------------------------------
1968

    
1969
``snf-dispatcher`` dispatches all messages published to the Message Queue and
1970
manages the Cyclades database accordingly. It also initializes all exchanges. By
1971
default it is not enabled during installation of Cyclades, so let's enable it in
1972
its configuration file ``/etc/default/snf-dispatcher``:
1973

    
1974
.. code-block:: console
1975

    
1976
   SNF_DSPTCH_ENABLE=true
1977

    
1978
and start the daemon:
1979

    
1980
.. code-block:: console
1981

    
1982
   # /etc/init.d/snf-dispatcher start
1983

    
1984
You can see that everything works correctly by tailing its log file
1985
``/var/log/synnefo/dispatcher.log``.
1986

    
1987
``snf-ganeti-eventd`` on GANETI MASTER
1988
--------------------------------------
1989

    
1990
The last step of the Cyclades setup is enabling the ``snf-ganeti-eventd``
1991
daemon (part of the :ref:`Cyclades Ganeti tools <cyclades-gtools>` package).
1992
The daemon is already installed on the GANETI MASTER (node1 in our case).
1993
``snf-ganeti-eventd`` is disabled by default during the ``snf-cyclades-gtools``
1994
installation, so we enable it in its configuration file
1995
``/etc/default/snf-ganeti-eventd``:
1996

    
1997
.. code-block:: console
1998

    
1999
   SNF_EVENTD_ENABLE=true
2000

    
2001
and start the daemon:
2002

    
2003
.. code-block:: console
2004

    
2005
   # /etc/init.d/snf-ganeti-eventd start
2006

    
2007
.. warning:: Make sure you start ``snf-ganeti-eventd`` *ONLY* on GANETI MASTER
2008

    
2009
Apply Quotas
2010
------------
2011

    
2012
.. code-block:: console
2013

    
2014
   node1 # snf-manage astakos-init --load-service-resources
2015
   node1 # snf-manage astakos-quota --verify
2016
   node1 # snf-manage astakos-quota --sync
2017
   node2 # snf-manage pithos-reset-usage
2018
   node1 # snf-manage cyclades-reset-usage
2019

    
2020
If all the above return successfully, then you have finished with the Cyclades
2021
and Plankton installation and setup.
2022

    
2023
Let's test our installation now.
2024

    
2025

    
2026
Testing of Cyclades (and Plankton)
2027
==================================
2028

    
2029
Cyclades Web UI
2030
---------------
2031

    
2032
First of all we need to test that our Cyclades Web UI works correctly. Open your
2033
browser and go to the Astakos home page. Login and then click 'cyclades' on the
2034
top cloud bar. This should redirect you to:
2035

    
2036
 `http://node1.example.com/ui/`
2037

    
2038
and the Cyclades home page should appear. If not, please go back and find what
2039
went wrong. Do not proceed if you don't see the Cyclades home page.
2040

    
2041
If the Cyclades home page appears, click on the orange button 'New machine'. The
2042
first step of the 'New machine wizard' will appear. This step shows all the
2043
available Images from which you can spawn new VMs. The list should be currently
2044
empty, as we haven't registered any Images yet. Close the wizard and browse the
2045
interface (not many things to see yet). If everything seems to work, let's
2046
register our first Image file.
2047

    
2048
Cyclades Images
2049
---------------
2050

    
2051
To test our Cyclades (and Plankton) installation, we will use an Image stored on
2052
Pithos+ to spawn a new VM from the Cyclades interface. We will describe all
2053
steps, even though you may already have uploaded an Image on Pithos+ from a
2054
:ref:`previous <snf-image-images>` section:
2055

    
2056
 * Upload an Image file to Pithos+
2057
 * Register that Image file to Plankton
2058
 * Spawn a new VM from that Image from the Cyclades Web UI
2059

    
2060
We will use the `kamaki <http://www.synnefo.org/docs/kamaki/latest/index.html>`_
2061
command line client to do the uploading and registering of the Image.
2062

    
2063
Installation of `kamaki`
2064
~~~~~~~~~~~~~~~~~~~~~~~~
2065

    
2066
You can install `kamaki` anywhere you like, since it is a standalone client of
2067
the APIs and talks to the installation over `http`. For the purpose of this
2068
guide we will assume that we have downloaded the `Debian Squeeze Base Image
2069
<https://pithos.okeanos.grnet.gr/public/9epgb>`_ and stored it under node1's
2070
``/srv/images`` directory. For that reason we will install `kamaki` on node1,
2071
too. We do this by running:
2072

    
2073
.. code-block:: console
2074

    
2075
   # apt-get install kamaki
2076

    
2077
Configuration of kamaki
2078
~~~~~~~~~~~~~~~~~~~~~~~
2079

    
2080
Now we need to setup kamaki, by adding the appropriate URLs and tokens of our
2081
installation. We do this by running:
2082

    
2083
.. code-block:: console
2084

    
2085
   $ kamaki config set user.url "https://node1.example.com"
2086
   $ kamaki config set compute.url "https://node1.example.com/api/v1.1"
2087
   $ kamaki config set image.url "https://node1.example.com/plankton"
2088
   $ kamaki config set file.url "https://node2.example.com/v1"
2089
   $ kamaki config set token USER_TOKEN
2090

    
2091
The USER_TOKEN appears on the user's `Profile` web page on the Astakos Web UI.
2092

    
2093
You can see that the new configuration options have been applied correctly,
2094
either by checking the editable file ``~/.kamakirc`` or by running:
2095

    
2096
.. code-block:: console
2097

    
2098
   $ kamaki config list
2099

    
2100
A quick test to check that kamaki is configured correctly, is to try to
2101
authenticate a user based on his/her token (in this case the user is you):
2102

    
2103
.. code-block:: console
2104

    
2105
  $ kamaki user authenticate
2106

    
2107
The above operation provides various user information, e.g. UUID (the unique
2108
user id) which might prove useful in some operations.
2109

    
2110
Upload an Image file to Pithos+
2111
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2112

    
2113
Now, that we have set up `kamaki` we will upload the Image that we have
2114
downloaded and stored under ``/srv/images/``. Although we can upload the Image
2115
under the root ``Pithos`` container (as you may have done when uploading the
2116
Image from the Pithos+ Web UI), we will create a new container called ``images``
2117
and store the Image under that container. We do this for two reasons:
2118

    
2119
a) To demonstrate how to create containers other than the default ``Pithos``.
2120
   This can be done only with the `kamaki` client and not through the Web UI.
2121

    
2122
b) As a best organization practise, so that you won't have your Image files
2123
   tangled along with all your other Pithos+ files and directory structures.
2124

    
2125
We create the new ``images`` container by running:
2126

    
2127
.. code-block:: console
2128

    
2129
   $ kamaki file create images
2130

    
2131
To check if the container has been created, list all containers of your
2132
account:
2133

    
2134
.. code-block:: console
2135

    
2136
  $ kamaki file list
2137

    
2138
Then, we upload the Image file to that container:
2139

    
2140
.. code-block:: console
2141

    
2142
   $ kamaki file upload /srv/images/debian_base-6.0-7-x86_64.diskdump images
2143

    
2144
The first is the local path and the second is the remote container on Pithos+.
2145
Check if the file has been uploaded, by listing the container contents:
2146

    
2147
.. code-block:: console
2148

    
2149
  $ kamaki file list images
2150

    
2151
Alternatively check if the new container and file appear on the Pithos+ Web UI.
2152

    
2153
Register an existing Image file to Plankton
2154
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2155

    
2156
For the purposes of the following example, we assume that the user UUID is
2157
``u53r-un1qu3-1d``.
2158

    
2159
Once the Image file has been successfully uploaded on Pithos+ then we register
2160
it to Plankton (so that it becomes visible to Cyclades), by running:
2161

    
2162
.. code-block:: console
2163

    
2164
   $ kamaki image register "Debian Base" \
2165
                           pithos://u53r-un1qu3-1d/images/debian_base-6.0-7-x86_64.diskdump \
2166
                           --public \
2167
                           --disk-format=diskdump \
2168
                           --property OSFAMILY=linux --property ROOT_PARTITION=1 \
2169
                           --property description="Debian Squeeze Base System" \
2170
                           --property size=451 --property kernel=2.6.32 --property GUI="No GUI" \
2171
                           --property sortorder=1 --property USERS=root --property OS=debian
2172

    
2173
This command registers the Pithos+ file
2174
``pithos://u53r-un1qu3-1d/images/debian_base-6.0-7-x86_64.diskdump`` as an
2175
Image in Plankton. This Image will be public (``--public``), so all users will
2176
be able to spawn VMs from it and is of type ``diskdump``. The first two
2177
properties (``OSFAMILY`` and ``ROOT_PARTITION``) are mandatory. All the rest
2178
properties are optional, but recommended, so that the Images appear nicely on
2179
the Cyclades Web UI. ``Debian Base`` will appear as the name of this Image. The
2180
``OS`` property's valid values may be found in the ``IMAGE_ICONS`` variable
2181
inside the ``20-snf-cyclades-app-ui.conf`` configuration file.
2182

    
2183
``OSFAMILY`` and ``ROOT_PARTITION`` are mandatory because they will be passed
2184
from Plankton to Cyclades and then to Ganeti and `snf-image` (also see
2185
:ref:`previous section <ganeti-with-pithos-images>`). All other properties are
2186
used to show information on the Cyclades UI.
2187

    
2188
Spawn a VM from the Cyclades Web UI
2189
-----------------------------------
2190

    
2191
If the registration completes successfully, then go to the Cyclades Web UI from
2192
your browser at:
2193

    
2194
 `https://node1.example.com/ui/`
2195

    
2196
Click on the 'New Machine' button and the first step of the wizard will appear.
2197
Click on 'My Images' (right after 'System' Images) on the left pane of the
2198
wizard. Your previously registered Image "Debian Base" should appear under
2199
'Available Images'. If not, something has gone wrong with the registration. Make
2200
sure you can see your Image file on the Pithos+ Web UI and ``kamaki image
2201
register`` returns successfully with all options and properties as shown above.
2202

    
2203
If the Image appears on the list, select it and complete the wizard by selecting
2204
a flavor and a name for your VM. Then finish by clicking 'Create'. Make sure you
2205
write down your password, because you *WON'T* be able to retrieve it later.
2206

    
2207
If everything was setup correctly, after a few minutes your new machine will go
2208
to state 'Running' and you will be able to use it. Click 'Console' to connect
2209
through VNC out of band, or click on the machine's icon to connect directly via
2210
SSH or RDP (for windows machines).
2211

    
2212
Congratulations. You have successfully installed the whole Synnefo stack and
2213
connected all components. Go ahead in the next section to test the Network
2214
functionality from inside Cyclades and discover even more features.
2215

    
2216
General Testing
2217
===============
2218

    
2219
Notes
2220
=====
2221