apt-get install -y virtualenv virtualenvwrapper git python-pip python-dev

     mkdir ~/mysite/

     mkvirtualenv -a ~/mysite/ mysite

2. And that is about it to be able to actually use this particular role! So

   let's try running it::

3. If all went well, you should have two files now:

   * :file:`~/mysite/preseed_files/www.example.com.cfg`

4. You can have a look at them, but you might notice the settings in the file

5. Now re-run the preseed playbook::

6. The preseed files should have been updated now, and you should have the new

   customised configuration files in the ``preseed_files`` directory. You can

In order to effectively use Ansible, a small initial bootstrap always has to be

done for managed servers. This mainly involves set-up of Ansible users on the

When you use the preseed configuration files to deploy a server, you get the

benefit of having the authorized_keys set-up for the root operating system,

        roles:

          - bootstrap

   need to make any changes so far.

3. SSH into both machines at least once from the Ansible server in order to

4. Now, simply run the bootstrap role against the two servers::

6. At this point you won't be able to ssh into the machines with root account

7. After this you can finally move on to configuring what you really want -

   common configuration and services for your site.

1. Create playbook for the communications server:

      ---

      - hosts: communications

2. Create playbook for the web server:

      ---

      - hosts: web

3. Create the global site playbook:

      ---

      - include: preseed.yml

   set-up a common base, we'll set-up the variables file that applies to all

   roles:

      ---

5. That's all for configuration, time to apply the changes::

Introducing LDAP

1. Update the playbook for communications server to include the LDAP client and

   server roles (``ldap_client`` and ``ldap_server``, respectively).

      ---

      - hosts: communications

2. Update the playbook for web server to include the LDAP client role

   (``ldap_client``). You never know when it might come in handy :)

      ---

      - hosts: web

3. Time to configure the roles. For start, let us configure the LDAP server

   role. Keep in mind that there is a lot of default variables set-up by the

      ---

   start off with global LDAP client configuration. In case of LDAP client,

   we've got to be a bit more explicit.

      # (defined up there) will use server's domain to form the base for LDAP.

      ldap_client_config:

        - comment: Set the base DN

   configuration on the communications server itself. Namely, on that one we

   should be able to connect to socket with LDAP clients instead over TCP port.

      ldap_client_config:

        - comment: Set the base DN

   of our own, plus the necessary server certificate for the LDAP service...

   1. Let's first install a couple of more tools on the Ansible server, since we

   2. Create directory where the private keys and certificates will be stored

        mkdir ~/mysite/tls/

   3. It is time to create a couple of templates for the ``certtool`` so it

      would know what extensions and content to have in the certificates:

         organization = "Example Inc."

         country = "SE"

         cert_signing_key

         crl_signing_key

         organization = "Example Inc."

         country = SE

        cp ~/mysite/tls/ca.pem ~/mysite/tls/truststore.pem

7. With private keys and certificates in place, we are almost ready to re-run

      tls_private_key_dir: "~/mysite/tls/"

      tls_certificate_dir: "~/mysite/tls/"

8. And now as finishing touch, simply run the playbooks again::

Adding mail server

The next thing in line is to implement the mail server capability. *Majic

Ansible Roles* come with two distinct mail server-related roles. One for

The mail server role looks-up available mail domains, users, and aliases in the

LDAP directory. This has already been set-up on the server

1. Update the playbook for communications server to include the mail server

role.

      ---

      - hosts: communications

2. Let's configure the role next.

      # Set the LDAP URL to connect through. Keep in mind TLS is required.

      mail_ldap_url: ldap://comms.example.com/

   before accepting them as valid mail users. Once again, the LDAP server role

   comes with a simple option for creating groups.

      # Don't forget, the passwords here must match with passwords specified

      ldap_server_consumers:

         - name: postfix

           password: postfix

      other means than the ``ldap_entries`` option. The reason for this is

      because this type of data in LDAP directory can be considered more of an

      operational/application data than configuration data that frequently

      also be backing-up your LDAP directory on regular basis ;)

      ldap_entries:

          # Create first a couple of user entries. Don't forget to set the

          # ldap_entries option passes the provided entries directly to the

          # ldap_entry module. "state: append" will make sure we don't overwrite

          # the group, and instead add the attributes to it (in this case we add

          - dn: cn=mail,ou=groups,dc=example,dc=com

            uniqueMember:

              - uid=johndoe,ou=people,dc=example,dc=com

   1. Create new templates for ``certtool``:

         organization = "Example Inc."

         country = SE

         signing_key

         encryption_key

         organization = "Example Inc."

         country = SE

         signing_key

         encryption_key

        certtool --sec-param normal --generate-privkey --outfile ~/mysite/tls/comms.example.com_smtp.key

        certtool --generate-certificate --load-ca-privkey ~/mysite/tls/ca.key --load-ca-certificate ~/mysite/tls/ca.pem --template ~/mysite/tls/comms.example.com_smtp.cfg --load-privkey ~/mysite/tls/comms.example.com_smtp.key --outfile ~/mysite/tls/comms.example.com_smtp.pem

6. Configuration and TLS keys have ben set-up, so it is time to apply the changes::

7. If no errors have been reported, at this point you should have two mail

Setting-up mail relaying from web server

With the mail server set-up, the next thing to do would be to set-up the SMTP

server on web server to relay mails via the communications server. This way we

can make sure that mail that gets sent via local SMTP to external addresses on

      ---

      - hosts: web

   configuration has not been touched before, so this will be a new

   configuration file.

      ---

         root: root john.doe@example.com

      # Now signal the local SMTP to relay any non-local mails via our

      smtp_relay_host: comms.example.com

3. Although we have told our web server to use the communications server as

   So, let's fix this a bit - we have a configuration option for the mail server

   for exactly this purpose.

      # We want to allow relaying of mails from our web server here. Beware the

      # IP spoofing, though! Don't forget to change the bellow IP for your

4. Let's apply the changes::

5. After this you may want to test out sending mail via web server's local SMTP

   to the root user (to see if the aliasing works), and to some external mail

     swaks --to root@localhost --server localhost

     swaks --to YOUR_MAIL --server localhost

1. Update the playbook for communications server to include the XMPP server

   role.

      ---

      - hosts: communications

2. Configure the role.

      # Set one of the users to also be an XMPP administrator.

      xmpp_administrators:

   Prosody itself. We should also create the group for granting the users right

   to use the service.

      # Just make sure the new entry is added for the prosody user - you can

      # leave the postfix/dovecot intact in your file if you use different

      Same warning applies here as for mail server role for managing the

      user/group entries! Scroll up and re-read it if you missed it!

      # Don't replace the entire ldap_entries, just append the new group

      # modification.

              - uid=janedoe,ou=people,dc=example,dc=com

            state: append

   and certificates, this time for our XMPP server ;)

   1. Create new template for ``certtool``:

         organization = "Example Inc."

         country = SE

6. Apply the changes::

7. If no errors have been reported, at this point you should have two users

   capable of using the XMPP service - one with username

   ``john.doe@example.com`` and one with username ``jane.doe@example.com``. Same

   passwords are used as for when you were creating the two users for mail

   server. For testing you can turn to your favourite XMPP client (I don't know

Taking a step back - preparing for web server

---------------------------------------------

communications server. That is, we haven't done anything beyond the basic set-up

of the web server.

Let us first define what we want to deploy on the web server. Since the goal is

1. First off, we will set-up the web server. This will be necessary no matter

   what web application we decide to deploy later on.

   setting-up a couple of web applications. For the purpose of the usage

   instructions, we will deploy the following two:

      things simple, we will not integrate it with our LDAP server (although

      this is supported and possible). Being written in PHP, this will

      demonstrate the role for PHP web application deployment.

It should be noted that the web application deployment roles are a bit more

complex - namely they are not meant to be used directly, but instead as a

dependency for a custom role. They do come with decent amount of batteries

With all the above noted, let us finally move on to the next step.

Finally we are moving on to the web server deployment, and we shell start

with... Well, erm, web server deployment! To be more precise, we will set-up

1. Update the playbook for web server to include the web server role.

      ---

      - hosts: web

   server role parameters are all optional, and they default to some ok-ish

   values. But let us spicen up things a bit nevertheless.

      web_default_title: "Welcome to default page!"

      web_default_message: "Nothing to see here, move along..."

   1. Create new template for ``certtool``:

         organization = "Example Inc."

         country = SE

4. Apply the changes::

5. If no errors have been reported, at this point you should have a default web

   out with some browser. Keep in mind you will get a warning about the

   untrusted certificate!

Since both of the web applications we want to deploy need a database, we will

proceed to set-up the database server role on the web server itself. *Majic

server.

1. Update the playbook for web server to include the database server role.

      ---

      - hosts: web

2. Now let's configure the role. This is rather simplistic, since we only need

   to set the database server root (admin) password.

      db_root_password: root

3. No TLS support has been implemented for this role (yet), so simply apply the

   changes::

4. If no errors have been reported, you should have a database server up and

   running on the web server. You should be able to log-in using password

     mysql -uroot -p

We have some basic infrastructure up and running now on our web server, so we

shall move on to setting-up a PHP web application on it. As mentioned before, we

For this we will create a local role in our site to take care of it. This role

will in turn utilise two roles coming from *Majic Ansible Roles* that will make

our life (a little) easier.

* The role is designed to execute every application via dedicated user and

  group. The user/group name is automatically derived from the FQDN of website,

2. Let's set-up role dependencies, reusing some common roles to make our life

   easier.

      ---

         - role: php_website

           # We shall let our admin account be able to read/write files

           # belonging to the application. This allows us to use regular user

           admin: admin

           fqdn: tbg.example.com

           # Some additional packages are required in order to deploy and use TBG.

           packages:

           # This is both the database name, _and_ name of the database user

           # that will be granted full privileges on the database.

           db_name: tbg

           # database. Take note the user can only login from localhost.

           db_password: tbg

   1. Create new template for ``certtool``:

         organization = "Example Inc."

         country = SE

4. Time to get our hands a bit more dirty... Up until now we didn't have to write

   custom tasks, but at this point we need to.

      ---

        become: yes

        become_user: admin

        file: path="{{ item }}" mode=g+w

        with_items:

           - /var/www/tbg.example.com/thebuggenie-{{ tbg_version }}/

        become: yes

        become_user: admin

      b2db:

          username: "tbg"

          tableprefix: ''

          cacheclass: '\thebuggenie\core\framework\Cache'

      #!/usr/bin/expect

6. And... Let's add the new role to our web server.

      ---

      - hosts: web

7. Apply the changes::

   https://tbg.example.com/ (or http://tbg.example.com/) and log-in into

   *The Bug Genie* with username ``administrator`` and password ``admin``.

Deploying a WSGI application (Django Wiki)

------------------------------------------

Similar to the PHP application deployment, we will use a couple of roles to make

it easier to deploy it in a standardised manner, and we will not have any kind

* The role is designed to execute every application via dedicated user and

  group. The user/group name is automatically derived from the FQDN of website,

2. Set-up some role dependencies, reusing the common role infrastructure.

      ---

         - role: wsgi_website

           admin: admin

           fqdn: wiki.example.com

           packages:

              - build-essential

              - python-dev

              - libopenjpeg-dev

              - libmariadb-client-lgpl-dev

              - libmariadb-client-lgpl-dev-compat

           static_locations:

              - /static/

           uid: 2001

           virtualenv_packages:

              - pillow

              - wiki

              - MySQL-python

           wsgi_application: wiki_example_com.wsgi:application

         - role: database

           db_name: wiki

   1. Create new template for ``certtool``:

         organization = "Example Inc."

         country = SE

4. At this point we have exhausted what we can do with the built-in roles. Time

   to add some custom tasks.

      ---

      - name: Create Django project directory

        file: dest="/var/www/wiki.example.com/code" state=directory

              owner=admin group=web-wiki_example_com

5. There is a couple of files that we are deploying through the above

   tasks. Let's create them as well.

      """