6. Ok, configuration of the role is complete. You may have noticed

   that we still haven't added any users to the new LDAP group called

   "xmpp". So let us correct this in similar way as we did for the

   mail server. Since we have the user entries already, no need to

   recreate them here. We will just update the group membership

   instead.

   .. warning::

      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!

   ::

     workon mysite && ansible --become -m ldap_attrs -a '{"dn": "cn=xmpp,ou=groups,dc=example,dc=com", "state": "present", "attributes": {"uniqueMember": "uid=johndoe,ou=people,dc=example,dc=com"}}' communications

     workon mysite && ansible --become -m ldap_attrs -a '{"dn": "cn=xmpp,ou=groups,dc=example,dc=com", "state": "present", "attributes": {"uniqueMember": "uid=janedoe,ou=people,dc=example,dc=com"}}' communications

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

   of any quick CLI-based tools to test the XMPP server functionality,

   unfortunately, but you could try using `mcabber <https://mcabber.com/>`_).

Taking a step back - preparing for web server

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

Up until now the usage instructions have dealt almost exclusively with the

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

of the other servers.

Let us first define what we want to deploy on the web server. Here is the plan:

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.

2. Next, we will set-up a database server. Why? Well, most web applications

   need to use some sort of database to store all the data, so we might as well

   try to take that one out of the way.

3. With this basic deployment for a web server in place, we can move on to

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

   instructions, we will deploy the following two:

   1. `Nextcloud <https://nextcloud.com/>`_ - extendable solution for

      file sharing, calendars etc. To keep things simple, we will not

      integrate it with our LDAP server (although this is supported

      and possible). Being written in PHP, this application will be

      used to demonstrate the role for PHP web application deployment.

   2. `Django Wiki <https://github.com/django-wiki/django-wiki>`_ - a wiki

      application written in Django. This will serve as a demo of how the WSGI

      role works.

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

included, and also play nice with the web server role.

As mentioned before, all roles will enforce TLS by default. The web server roles

will additionaly implement HSTS policy by sending connecting clients

``Strict-Transport-Security`` header with value set to ``max-age=31536000;

includeSubDomains``.

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

Setting-up the web server

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

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

Nginx.

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

    :file:`~/mysite/playbooks/web.yml`

    ::

      ---

      - hosts: web

        remote_user: ansible

        become: yes

        roles:

          - common

          - ldap_client

          - mail_forwarder

          - web_server

2. You know the drill, role configuration comes up next. No

   configuration has been deployed before for the web server, so we

   will be creating a new file. Only the TLS parameters are really

   necessary, but we'll spice things up a bit by setting custom title

   and message for default virtual host.

   :file:`~/mysite/group_vars/web.yml`

   ::

      ---

      default_https_tls_certificate: "{{ lookup('file', '~/mysite/tls/www.example.com_https.pem') }}"

      default_https_tls_key: "{{ lookup('file', '~/mysite/tls/www.example.com_https.key') }}"

      web_default_title: "Welcome to default page!"

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

3. The only thing left now is to create the TLS private key/certificate pair

   that should be used for default virtual host.

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

      :file:`~/mysite/tls/www.example.com_https.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Exampe Inc. Web Server"

         expiration_days = 365

         dns_name = "www.example.com"

         tls_www_server

         signing_key

         encryption_key

   2. Create the keys and certificates for default web server virtual host based

      on the template::

        certtool --sec-param normal --generate-privkey --outfile ~/mysite/tls/www.example.com_https.key

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

4. Apply the changes::

     workon mysite && ansible-playbook playbooks/site.yml

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

   page available and visible at https://www.example.com/ . By default plaintext

   connections are disabled, and trying to visit http://www.example.com/ should

   simply redirect you to the HTTPS address. Feel free to try it out with some

   browser. Keep in mind you will get a warning about the untrusted certificate!

Adding the database server

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

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

Ansible Roles* in particular come with a role that will deploy MariaDB database

server.

.. note::

   The ``database_server`` role will set-up unix socket authentication

   for the database ``root`` user. I.e. the ``root`` database user

   will have no password set, but authentication will pass only when

   logging-in as the operating system ``root`` user while connecting

   over database server unix socket.

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

    :file:`~/mysite/playbooks/web.yml`

    ::

      ---

      - hosts: web

        remote_user: ansible

        become: yes

        roles:

          - common

          - ldap_client

          - mail_forwarder

          - web_server

          - database_server

2. This particular role has no parameters, and no additional steps are

   necessary to configure it. So move along...

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

   changes::

     workon mysite && ansible-playbook playbooks/site.yml

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 as ``root``

   operating system user by running the following command on the web

   server itself::

     mysql

   Of course, no database has been created for either of the web applications,

   but we will get to that one later (there is a dedicated ``database`` role

   which can be combined with web app roles for this purpose).

Deploying a PHP web application (Nextcloud)

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

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

now we can move on to setting-up a PHP web application on it. As

mentioned before, we will roll-out *Nextcloud*.

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.

To make the example a bit simpler, no parameters will be introduced

for this role (not even the password for database) - we'll hard-code

everything.

Before we start, here is a couple of useful pointers regarding the

``php_website`` role:

* 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, for example ``web-nextcloud_example_com``.

* While running the application, application user's umask is set to

  ``0007`` (letting the administrator user be able to manage any files

  created while the application is running).

* An administrative user is created as well, and this user should be

  used when running maintenance and installation commands. Similar to

  application user, the name is also derived from the FQDN of website,

  for example ``admin-nextcloud_example_com``. Administrative user

  does not have a dedicated group, and instead belongs to same group

  as the application user.

* PHP applications are executed via FastCGI, using *PHP-FPM*.

* If you ever need to set some additional PHP FPM settings, this can

  easily be done via the ``additional_fpm_config`` role

  parameter. This particular example does not set any, though.

* Incoming request headers can be set/overridden using the

  ``http_header_overrides`` parameter. This can be useful for

  manipulating headers in specifics ways, such as disabling

  compression etc. on the application side.

* Mails delivered to local admin/application users are forwarded to

  ``root`` account (configurable via ``website_mail_recipients`` role

  parameter.

* If you ever find yourself mixing-up test and production websites,

  have a look at ``environment_indicator`` role parameter. It lets you

  insert small strip with environment information at bottom of each

  HTML page served by the web server. If the strip gets in the way, it

  can easily be collapsed using the arrows on the left side.

* Static content (non-PHP) is served directly by *Nginx*.

* Each web application gets distinct sub-directory under ``/var/www``,

  named after the FQDN. All sub-directories created under there are

  created with ``02750`` permissions, with ownership set to admin

  user, and group set to the application's group. In other words, all

  directories will have ``SGID`` bit set, allowing you to create

  files/directories that will have their group automatically set to

  the group of the parent directory.

* Files are served (both by *Nginx* and *PHP-FPM*) from sub-directory

  called ``htdocs`` (located in website directory). For example

  ``/var/www/nextcloud.example.com/htdocs/``. Normally, this can be a

  symlink to some other sub-directory within the website directory

  (useful for having multiple versions for easier downgrades etc).

* Combination of admin user membership in application group, ``SGID``

  permission, and the way ownership of sub-directories is set-up

  usually means that the administrator will be capable of managing

  application files, and application can be granted write permissions

  to a *minimum* of necessary files.

  .. warning::

     Just keep in mind that some file-management commands, like

     ``mv``, do *not* respect the ``SGID`` bit. In fact, I would

     recommend using ``cp`` when you deploy new files to the directory

     instead (don't simply move them from your home directory).

1. Start-off with creating the necessary directories for the new role::

     mkdir -p ~/mysite/roles/nextcloud/{tasks,meta,files}/

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

   our life easier.

   :file:`~/mysite/roles/nextcloud/meta/main.yml`

   ::

      ---

      dependencies:

        # Role helps us set-up Nginx virtual host for serving our app.

        - role: php_website

          # Name that will be bound to specific virtual host definition.

          fqdn: nextcloud.example.com

          # TLS key and certificate to use for the virtual host.

          https_tls_certificate: "{{ lookup('file', '~/mysite/tls/nextcloud.example.com_https.pem') }}"

          https_tls_key: "{{ lookup('file', '~/mysite/tls/nextcloud.example.com_https.key') }}"

          # Additional packages required for deploying and running Nextcloud.

          packages:

            - php-gd

            - php-json

            - php-mysql

            - php-curl

            - php-intl

            - php-mbstring

            - php-imagick

            - php-ldap

            - php-xml

            - php-zip

            - php-gmp

            - python3-pexpect

            - php-apcu

            - php-bcmath

          # Set-up URL rewrites for well-known URIs (see https://en.wikipedia.org/wiki/Well-known_URIs).

          rewrites:

            - '^/\.well-known/carddav /remote.php/dav/ permanent'

            - '^/\.well-known/caldav /remote.php/dav/ permanent'

            - '^/remote/(.*) /remote.php last'

          # Prevent specific files from ever being served by the web server (for security reasons etc).

          deny_files_regex:

            - '^/(build|tests|config|lib|3rdparty|templates|data)/'

            - '^/(?:\.|autotest|occ|issue|indie|db_|console)'

          # Custom regex defining what files shouled be processed via PHP

          # interpreter.

          php_file_regex: \.php(?:$|/)

          # Not necessarily needed, but in case you have a policy on uid/gid

          # usage, this is useful. Take note that the uid value is also used

          # for the application group (gid == uid).

          uid: 2000

          admin_uid: 3000

        # Role that sets up a new dedicated database for our web

        # application.

        - role: database

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

          # that will be granted full privileges on the database.

          db_name: nextcloud

          # Password for user used for accessing the database. Take note

          # that the user can only login from localhost.

          db_password: nextcloud

3. Now for my favourite part again - creating private keys and

   certificates!  Why?  Because the ``php_website`` role requires a

   private key/certificate pair to be deployed. So... Moving on:

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

      :file:`~/mysite/tls/nextcloud.example.com_https.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Example Inc. Cloud Service"

         expiration_days = 365

         dns_name = "nextcloud.example.com"

         tls_www_server

         signing_key

         encryption_key

   2. Create the keys and certificates for the application::

        certtool --sec-param normal --generate-privkey --outfile ~/mysite/tls/nextcloud.example.com_https.key

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

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

   have to write custom tasks, but that ends now.

   :file:`~/mysite/roles/nextcloud/tasks/main.yml`

   ::

      ---

      # Deployment

      # ==========

      - name: Download the application archive

        ansible.builtin.get_url:

          url: "https://download.nextcloud.com/server/releases/nextcloud-29.0.4.tar.bz2"

          dest: "/var/www/nextcloud.example.com/nextcloud-29.0.4.tar.gz"

        become: yes

        become_user: admin-nextcloud_example_com

      - name: Unpack the application archive

        ansible.builtin.unarchive:

          src: "/var/www/nextcloud.example.com/nextcloud-29.0.4.tar.gz"

          dest: "/var/www/nextcloud.example.com/"

          copy: no

          creates: "/var/www/nextcloud.example.com/nextcloud"

        become: yes

        become_user: admin-nextcloud_example_com

      # Majic Ansible Roles currently only support utf8 encoding.

      - name: Disable opportunistic use of utf8mb4 on fresh installs

        ansible.builtin.lineinfile:

          dest: "/var/www/nextcloud.example.com/nextcloud/lib/private/Setup/MySQL.php"

          line: "{{ '\t\t\t' }}$this->config->setValue('mysql.utf8mb4', true);"

          state: absent

      - name: Allow application user to install and update applications

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/nextcloud/apps"

          mode: g+w

      - name: Allow CLI tool to be run by the user and group

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/nextcloud/occ"

          mode: u+x,g+x

      - name: Create directory for storing data

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/data"

          state: directory

          mode: 02770

          owner: "admin-nextcloud_example_com"

          group: "web-nextcloud_example_com"

      - name: Create directory for storing configuration files

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/nextcloud/config"

          state: directory

          mode: 02750

          owner: "admin-nextcloud_example_com"

          group: "web-nextcloud_example_com"

      - name: Create an empty log file if it does not exist

        ansible.builtin.copy:

          content: ""

          dest: "/var/www/nextcloud.example.com/data/nextcloud.log"

          force: no

      - name: Set-up log file permissions

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/data/nextcloud.log"

          owner: "admin-nextcloud_example_com"

          group: "web-nextcloud_example_com"

          mode: 0660

      - name: Symlink the default path used by the web server for finding application files

        ansible.builtin.file:

          src: "/var/www/nextcloud.example.com/nextcloud"

          dest: "/var/www/nextcloud.example.com/htdocs"

          state: link

          owner: "admin-nextcloud_example_com"

          group: "web-nextcloud_example_com"

        notify:

          - Restart PHP-FPM

      # Installation

      # ============

      - name: Get application installation status

        ansible.builtin.command: "/var/www/nextcloud.example.com/nextcloud/occ status"

        become: yes

        become_user: "admin-nextcloud_example_com"

        register: nextcloud_status

        changed_when: False

        failed_when: False

      - name: Check if application is installed

        ansible.builtin.set_fact:

          nextcloud_installed: "{{ 'Nextcloud is not installed' not in nextcloud_status.stderr }}"

      - name: Deploy installation script

        ansible.builtin.copy:

          src: "install_nextcloud.py"

          dest: "/var/www/nextcloud.example.com/install_nextcloud.py"

          owner: "admin-nextcloud_example_com"

          group: "web-nextcloud_example_com"

          mode: 0700

        when: "not nextcloud_installed"

      - name: Install application

        ansible.builtin.command: "/var/www/nextcloud.example.com/install_nextcloud.py"

        become: yes

        become_user: "admin-nextcloud_example_com"

        when: "not nextcloud_installed"

      - name: Remove installation script

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/install_nextcloud.py"

          state: absent

      - name: Fix data file permissions for application user/group

        ansible.builtin.file:

          path: "/var/www/nextcloud.example.com/data"

          mode: g+w

          recurse: yes

          follow: no

      - name: Deploy local configuration overrides

        ansible.builtin.copy:

          src: "local.config.php"

          dest: "/var/www/nextcloud.example.com/nextcloud/config/local.config.php"

          owner: "admin-nextcloud_example_com"

          group: "web-nextcloud_example_com"

          mode: 0640

5. Set-up files that are deployed by the role.

   :file:`~/mysite/roles/nextcloud/files/local.config.php`

   ::

      <?php

      $CONFIG = array (

        'config_is_read_only' => true,

        'instanceid' => 'suqw2cvca8sp',

        'trusted_domains' =>

          array (

            0 => 'nextcloud.example.com',

          ),

      );

   :file:`~/mysite/roles/nextcloud/files/install_nextcloud.py`

   ::

      #!/usr/bin/env python3

      import pexpect

      # Spawn the process.

      install_process = pexpect.spawnu('/var/www/nextcloud.example.com/nextcloud/occ',

                                       args = [ 'maintenance:install',

                                                '--database', 'mysql',

                                                '--database-name', 'nextcloud',

                                                '--database-user', 'nextcloud',

                                                '--database-host', 'localhost',

                                                '--database-port', '3306',

                                                '--admin-user', 'admin',

                                                '--data-dir', '/var/www/nextcloud.example.com/data'])

      # If we get EOF, we probably already installed application, and ran

      # into error at the end since no patterns matched.

      try:

          # Provide database password.

          install_process.expect(u'What is the password to access the database with user.*\?', timeout=10)

          install_process.sendline(u'nextcloud')

          # Provide administrator password.

          install_process.expect(u'What is the password you like to use for the admin account.*\?', timeout=10)

          install_process.sendline(u'admin')

          # Wait for application to finish.

          install_process.expect(pexpect.EOF, timeout=120)

      except pexpect.EOF as e:

          pass

      # Print command output. Has to be done prior to final wait for

      # pexpect.EOF.

      print(install_process.before.encode('utf-8'))

      # Close application. Additional wait for pexpect.EOF prevents the

      # process from getting killed prematurely in case it exits

      # immediatelly (due to wrong command line arguments etc). Some

      # background information can be found at (although it is a very old

      # post):

      #

      # https://www.heikkitoivonen.net/blog/2009/01/28/pexpect-and-inconsistent-exit-status/

      #

      install_process.expect(pexpect.EOF)

      install_process.close()

      # Return same exit code like child process.

      exit(install_process.exitstatus)

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

   :file:`~/mysite/playbooks/web.yml`

   ::

      ---

      - hosts: web

        remote_user: ansible

        become: yes

        roles:

          - common

          - ldap_client

          - mail_forwarder

          - web_server

          - database_server

          - nextcloud

7. Apply the changes::

     workon mysite && ansible-playbook playbooks/site.yml

8. At this point *Nextcloud* has been installed, and you should be

   able to open the URL https://nextcloud.example.com/ and log-in into

   *Nextcloud* with username ``admin`` and password ``admin``.

Deploying a WSGI application (Django Wiki)

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

Next thing up will be to deploy a WSGI Python application.

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

of parameters for configuring the role to keep things simple.

Most of the notes on how a ``php_website`` role is deployed also stand for the

``wsgi_website`` role, but we will reiterate and clarify them a bit just to be

on the safe side:

* 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,

  for example ``web-wiki_example_com``.

* While running the application, application user's umask is set to ``0007``

  (letting the administrator user be able to manage any files created while the

  application is running).

* An administrative user is created as well, and this user should be used when

  running maintenance and installation commands. Similar to application user,

  the name is also derived from the FQDN of website, for example

  ``admin-wiki_example_com``. Administrative user does not have a dedicated

  group, and instead belongs to same group as the application user. As

  convenience, whenever you switch to this user the Python virtual environment

  will be automatically activated for you.

* WSGI applications are executed via *Gunicorn*. The WSGI server listens on a

  Unix socket, making the socket accessible by *Nginx*.

* If you ever need to set some environment variables, this can easily be done

  via the ``environment_variables`` role parameter. This particular example does

  not set any, though.

* You can also specify headers to be modified in incoming client

  request before it gets passed on to the WSGI application using the

  ``http_header_overrides`` parameter.  directive to Gunicorn running

  the application.

* Mails deliverd to local admin/application users are forwarded to ``root``

  account instead (this can be configured via ``website_mail_recipients`` role

  parameter.

* If you ever find yourself mixing-up test and production websites,

  have a look at ``environment_indicator`` role parameter. It lets you

  insert small strip with environment information at bottom of each

  HTML page served by the web server.

* Static content is served directly by *Nginx*.

* Each web application gets distinct sub-directory under ``/var/www``, named

  after the FQDN. All sub-directories created under there are created with

  ``2750`` permissions, with ownership set to admin user, and group set to the

  application's group. In other words, all directories will have ``SGID`` bit

  set, allowing you to create files/directories that will have their group

  automatically set to the group of the parent directory.

* Each WSGI website gets a dedicated virtual environment, stored in the

  sub-directory ``virtualenv`` of the website directory, for example

  ``/var/www/wiki.example.com/virtualenv``.

* Static files are served from sub-directory ``htdocs`` in the website

  directory, for example ``/var/www/wiki.example.com/htdocs/``.

* The base directory where your website/application code should be at is

  expected to be in sub-directory ``code`` in the website directory, for example

  ``/var/www/wiki.example.com/code/``.

* Combination of admin user membership in application group, ``SGID``

  permission, and the way ownership of sub-directories is set-up usually means

  that the administrator will be capable of managing application files, and

  application can be granted write permissions to a *minimum* of necessary

  files.

  .. warning::

     Just keep in mind that some file-management commands, like ``mv``, do *not*

     respect the ``SGID`` bit. In fact, I would recommend using ``cp`` when you

     deploy new files to the directory instead (don't simply move them from your

     home directory).

1. Set-up the necessary directories first::

     mkdir -p ~/mysite/roles/wiki/{tasks,meta,files,handlers}/

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

   :file:`~/mysite/roles/wiki/meta/main.yml`

   ::

      ---

      dependencies:

        - role: wsgi_website

          fqdn: wiki.example.com

          # TLS key and certificate to use for the virtual host.

          https_tls_certificate: "{{ lookup('file', '~/mysite/tls/wiki.example.com_https.pem') }}"

          https_tls_key: "{{ lookup('file', '~/mysite/tls/wiki.example.com_https.key') }}"

          # In many cases you need to have some development packages available

          # in order to build Python packages installed via pip

          packages:

            - build-essential

            - python3-dev

            - libjpeg62-turbo

            - libjpeg-dev

            - libpng16-16

            - libpng-dev

            - libmariadb-dev

            - libmariadb-dev-compat

            - pkg-config

          # Here we specify that anything accessing our website with "/static/"

          # URL should be treated as request to a static file, to be served

          # directly by Nginx instead of the WSGI server.

          static_locations:

            - /static/

          # Again, not mandatory, but it is good to have some sort of policy

          # for assigning UIDs.

          uid: 2001

          admin_uid: 3001

          # These are additional packages that should be installed in the

          # virtual environment.

          virtualenv_packages:

            - django~=4.2.0

            - wiki~=0.10.0

            - mysqlclient

          # This is the name of the WSGI application to

          # serve. wiki_example_com.wsgi will be the Python "module" that is

          # accesed, while application is the object instantiated within it (the

          # application itself). The module is referenced relative to the code

          # directory (in our case /var/www/wiki.example.com/code/).

          wsgi_application: wiki_example_com.wsgi:application

          # Specify explicitly requirements for installing Gunicorn.

          wsgi_requirements:

            - gunicorn==21.2.0

            - packaging==23.2

          wsgi_requirements_in:

            - gunicorn

        - role: database

          db_name: wiki

          db_password: wiki

3. Let's create a dedicated private key/certificate pair for the wiki website:

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

      :file:`~/mysite/tls/wiki.example.com_https.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Exampe Inc. Wiki"

         expiration_days = 365

         dns_name = "wiki.example.com"

         tls_www_server

         signing_key

         encryption_key

   2. Create the keys and certificates for the application::

        certtool --sec-param normal --generate-privkey --outfile ~/mysite/tls/wiki.example.com_https.key

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

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

   to add some custom tasks.

   :file:`~/mysite/roles/wiki/tasks/main.yml`

   ::

      ---

      - name: Create Django project directory

        ansible.builtin.file:

          dest: "/var/www/wiki.example.com/code"

          state: directory

          owner: admin-wiki_example_com

          group: web-wiki_example_com

          mode: 02750

      - name: Start Django project for the Wiki website

        ansible.builtin.command: "/var/www/wiki.example.com/virtualenv/bin/exec django-admin startproject wiki_example_com /var/www/wiki.example.com/code"

        args:

          chdir: "/var/www/wiki.example.com"