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

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_attr -a "dn=cn=xmpp,ou=groups,dc=example,dc=com state=present name=uniqueMember values=uid=johndoe,ou=people,dc=example,dc=com" communications

      workon mysite && ansible --become -m ldap_attr -a "dn=cn=xmpp,ou=groups,dc=example,dc=com state=present name=uniqueMember values=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. `The Bug Genie <http://thebuggenie.org/>`_ - an issue tracker. To keep

      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.

   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 (The Bug Genie)

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

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 take *The Bug Genie* as an example.

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 we'll be using for the PHP part:

* 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-tbg_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-tbg_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.

* Mails delivered 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 (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/tbg.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/tbg/{tasks,meta,files}/

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

   easier.

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

   ::

      ---

      dependencies:

        # Ok, so this role helps us set-up Nginx virtual host for serving our

        # app.

        - role: php_website

          # Our virtual host will for PHP website will respond to this name.

          fqdn: tbg.example.com

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

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

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

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

          packages:

            - php-gd

            - php-curl

            - php-mbstring

            - php-xml

            - git

            - php-mysql

            - php-apcu

            - php-zip

          # Set-up URL rewriting. This is based on public/.htaccess file from

          # TBG.

          php_rewrite_urls:

            - ^(.*)$ /index.php?url=$1

          # We don't necessarily need this, but in case you have a policy on

          # uid/gid usage, this is useful. Take note that below value is used

          # for both the dedicated uid and gid for application user.

          uid: 2000

          admin_uid: 3000

        # And this role 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: tbg

          # This will be the password of our user 'tbg' for accessing the

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

          db_password: tbg

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/tbg.example.com_https.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Exampe Inc. Issue Tracker"

         expiration_days = 365

         dns_name = "tbg.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/tbg.example.com_https.key

        certtool --generate-certificate --load-ca-privkey ~/mysite/tls/ca.key --load-ca-certificate ~/mysite/tls/ca.pem --template ~/mysite/tls/tbg.example.com_https.cfg --load-privkey ~/mysite/tls/tbg.example.com_https.key --outfile ~/mysite/tls/tbg.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 at this point we need to.

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

   ::

      ---

      - name: Define TBG version

        set_fact:

          tbg_version: "4.3.1"

          tbg_archive_checksum: "45de72b1ef82142ad46686577d593375ba370156df4367d17386b4e26a37f342"

      - name: Download the TBG archive

        get_url:

          url: "https://github.com/thebuggenie/thebuggenie/archive/v{{ tbg_version }}.tar.gz"

          dest: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}.tar.gz"

          sha256sum: "{{ tbg_archive_checksum }}"

        become: yes

        become_user: admin-tbg_example_com

      - name: Download Composer

        get_url:

          url: "https://getcomposer.org/download/1.10.19/composer.phar"

          dest: "/usr/local/bin/composer"

          sha256sum: "688bf8f868643b420dded326614fcdf969572ac8ad7fbbb92c28a631157d39e8"

          owner: root

          group: root

          mode: 0755

      - name: Unpack TBG

        unarchive:

          src: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}.tar.gz"

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

          copy: no

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

        become: yes

        become_user: admin-tbg_example_com

      - name: Allow use of lib-pcre version 10 (since PHP is built against it in Debian Buster)

        lineinfile:

          dest: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}/{{ item }}"

          state: present

          regexp: '.*"lib-pcre".*'

          line: '        "lib-pcre": ">=8.0",'

        with_items:

          - "composer.json"

          - "composer.lock"

      - name: Create TBG cache directory

        file:

          path: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}/cache"

          state: directory

          mode: 02770

        become: yes

        become_user: admin-tbg_example_com

      - name: Set-up the necessary write permissions for TBG directories

        file:

          path: "{{ item }}"

          mode: g+w

        with_items:

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

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

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

      - name: Create symbolic link to TBG application

        file:

          src: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}/public"

          path: "/var/www/tbg.example.com/htdocs"

          state: link

          owner: "admin-tbg_example_com"

          group: "web-tbg_example_com"

        become: yes

        become_user: admin-tbg_example_com

      - name: Install TBG dependencies

        composer:

          command: install

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

        become: yes

        become_user: admin-tbg_example_com

      - name: Deploy database configuration file for TBG

        copy:

          src: "b2db.yml"

          dest: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}/core/config/b2db.yml"

          mode: 0640

          owner: admin-tbg_example_com

          group: web-tbg_example_com

      - name: Install pexpect package

        apt:

          name: python3-pexpect

          state: present

      - name: Deploy expect script for installing TBG

        copy:

          src: "tbg_expect_install"

          dest: "/var/www/tbg.example.com/tbg_expect_install"

          mode: 0750

          owner: admin-tbg_example_com

          group: web-tbg_example_com

      - name: Run TBG installer via expect script

        command: /var/www/tbg.example.com/tbg_expect_install

        args:

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

          creates: "/var/www/tbg.example.com/thebuggenie-{{ tbg_version }}/installed"

        become: yes

        become_user: admin-tbg_example_com

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

   :file:`~/mysite/roles/tbg/files/b2db.yml`

   ::

      b2db:

          username: "tbg"

          password: "tbg"

          dsn: "mysql:host=localhost;dbname=tbg"

          tableprefix: ''

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

   :file:`~/mysite/roles/tbg/files/tbg_expect_install`

   ::

      #!/usr/bin/env python3

      import pexpect

      # Spawn the process.

      install_process = pexpect.spawnu('./tbg_cli', args = ["install",

                                                                        "--accept_license=yes",

                                                                        "--url_subdir=/",

                                                                        "--use_existing_db_info=yes",

                                                                        "--enable_all_modules=no",

                                                                        "--setup_htaccess=yes"])

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

      # into error at the end since no patterns matched.

      try:

          # First confirmation.

          install_process.expect(u'Press ENTER to continue with the installation: ', timeout=5)

          install_process.sendline(u'')

          # Second confirmation.

          install_process.expect(u'Press ENTER to continue: ', timeout=5)

          install_process.sendline(u'')

          # Wait for application to finish.

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

      except pexpect.EOF as e:

          pass

      # Close application.

      install_process.close()

      # Print text output.

      print(install_process.before)

      # 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

          - tbg

7. Apply the changes::

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

8. At this point *The Bug Genie* has been installed, and you should be able to

   open the URL https://tbg.example.com/ and log-in into *The Bug Genie*

   with username ``administrator`` 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 passed on via Nginx ``proxy_set_header``

  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

          # Specify that Python 3 should be used for the application

          python_version: 3

          # 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~=2.2.0

            - wiki~=0.5.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==20.0.4

          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

        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

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

        args:

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

          creates: "/var/www/wiki.example.com/code/wiki_example_com"

        become: yes

        become_user: admin-wiki_example_com

      - name: Deploy settings for wiki website

        copy:

          src: "{{ item }}"

          dest: "/var/www/wiki.example.com/code/wiki_example_com/{{ item }}"

          mode: 0640

          owner: admin

          group: web-wiki_example_com

        with_items:

          - settings.py

          - urls.py

        notify:

          - Restart wiki

      - name: Deploy project database and deploy static files

        django_manage:

          command: "{{ item }}"

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

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

        become: yes

        become_user: admin-wiki_example_com

        with_items:

          - migrate

          - collectstatic

      - name: Deploy the superadmin creation script

        copy:

          src: "create_superadmin.py"

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

          owner: admin-wiki_example_com

          group: web-wiki_example_com

          mode: 0750

      - name: Create initial superuser

        command: "/var/www/wiki.example.com/virtualenv/bin/exec ./create_superadmin.py"

        args:

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

        become: yes

        become_user: admin-wiki_example_com

        register: wiki_superuser

        changed_when: "wiki_superuser.stdout ==  'Created superuser.'"

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

   ::

      ---

      - name: Restart wiki

        service:

          name: wiki.example.com

          state: restarted

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

   tasks. Let's create them as well.

   :file:`~/mysite/roles/wiki/files/settings.py`

   ::

      """

      Django settings for wiki_example_com project.

      For more information on this file, see

      https://docs.djangoproject.com/en/2.2/topics/settings/

      For the full list of settings and their values, see

      https://docs.djangoproject.com/en/2.2/ref/settings/

      """

      import os

      ]

      WSGI_APPLICATION = 'wiki_example_com.wsgi.application'

      # Database

      # https://docs.djangoproject.com/en/2.2/ref/settings/#databases

      DATABASES = {

          'default': {

              'ENGINE': 'django.db.backends.mysql',

              'NAME': 'wiki',

              'USER': 'wiki',

              'PASSWORD': 'wiki',

              'HOST': '127.0.0.1',

              'PORT': '3306',

          }

      }

      # Password validation

      # https://docs.djangoproject.com/en/2.2/ref/settings/#auth-password-validators

      AUTH_PASSWORD_VALIDATORS = [

          {

              'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',

          },

          {

              'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',

          },

          {

              'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',

          },

          {

              'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',

          },

      ]

      # Internationalization

      # https://docs.djangoproject.com/en/2.2/topics/i18n/

      LANGUAGE_CODE = 'en-us'

      TIME_ZONE = 'Europe/Stockholm'

      USE_I18N = True

      USE_L10N = True

      USE_TZ = True

      # Static files (CSS, JavaScript, Images)

      # https://docs.djangoproject.com/en/2.2/howto/static-files/

      STATIC_URL = '/static/'

      STATIC_ROOT = '/var/www/wiki.example.com/htdocs/static'

      SITE_ID = 1

      LOGIN_REDIRECT_URL = reverse_lazy('wiki:get', kwargs={'path': ''})

   :file:`~/mysite/roles/wiki/files/urls.py`

   ::

      from django.contrib import admin

      from django.urls import path, include

      urlpatterns = [

          path('admin/', admin.site.urls),

          path('notifications/', include('django_nyt.urls')),

          path('', include('wiki.urls'))

      ]

   :file:`~/mysite/roles/wiki/files/create_superadmin.py`

   ::

      #!/usr/bin/env python

      import os

      from django import setup

      os.environ['DJANGO_SETTINGS_MODULE']='wiki_example_com.settings'

      setup()

      from django.conf import settings

      from django.contrib.auth.models import User

      User.objects.all()

      if len(User.objects.filter(username="admin")) == 0:

          User.objects.create_superuser('admin', 'john.doe@example.com', 'admin')

          print("Created superuser.")

6. Time to add the new role to our web server.