look-up the mail server information. We have also defined the mail group for

   limitting which users get mail service. However, we don't have any

   user/domain information yet. So let's change that, using the ``ldap_entries``

   option from LDAP server role.

   .. warning::

      Long-term, you probably want to manage these entries manually or through

      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

      changes (especially the user passwords/info). Backups of LDAP directory on

      regular basis are important. We will get to that at a later point.

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

   ::

      ldap_entries:

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

        # "mail" attribute for them.

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

          attributes:

            objectClass:

              - inetOrgPerson

            uid: johndoe

            cn: John Doe

            sn: Doe

            userPassword: johndoe

            mail: john.doe@example.com

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

          attributes:

            objectClass:

              - inetOrgPerson

            uid: janedoe

            cn: Jane Doe

            sn: Doe

            userPassword: janedoe

            mail: jane.doe@example.com

        # Let's register our domain in LDAP directory.

        - dn: dc=example.com,ou=domains,ou=mail,ou=services,dc=example,dc=com

          attributes:

            objectClass: dNSDomain

            dc: "example.com"

          # Finally, for the lolz, let's also add the standard postmaster alias

          # for our domain. This one will also receive any undeliverable bounced

          # mails.

        - dn: cn=postmaster@example.com,ou=aliases,ou=mail,ou=services,dc=example,dc=com

          attributes:

            objectClass: nisMailAlias

            cn: postmaster@example.com

            rfc822MailMember: john.doe@example.com

5. Once again, before we apply the configuration, we must make sure the

   necessary TLS private keys and certificates are available. In this particular

   case, we need to set-up separate key/certificate pair for both the SMTP and

   IMAP service:

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

      :file:`~/mysite/tls/comms.example.com_smtp.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Exampe Inc. SMTP Server"

         expiration_days = 365

         dns_name = "comms.example.com"

         tls_www_server

         signing_key

         encryption_key

      :file:`~/mysite/tls/comms.example.com_imap.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Exampe Inc. IMAP Server"

         expiration_days = 365

         dns_name = "comms.example.com"

         tls_www_server

         signing_key

         encryption_key

   2. Create the keys and certificates for SMTP/IMAP services based on the templates::

        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

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

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

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

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

7. Let's add the two users to the mail group (otherwise, the mail

   directly to make our life a bit easier::

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

   accounts - ``john.doe@example.com``, with password ``johndoe``, and

   ``jane.doe@example.com``, with password ``janedoe``. In this particular

   set-up, the mail addresses are used as usernames. If you want to test it out,

   simply install ``swaks`` on your Ansible machine, and run something along the

   lines of

   ::

     swaks --to john.doe@example.com --server comms.example.com

     swaks --to jane.doe@example.com --server comms.example.com

  Of course, free feel to also test out the mail server using any mail client of

  your choice. When doing so, use port 587 for SMTP. Port 25 is reserved for

  unauthenticated server-to-server mail deliveries.

  If you face issues with ISPs or hotels blocking the two ports listed above,

  you can also use alternative ports 26 (redirected to port 587) and 27

  (redirected to port 25).

  TLS has also been hardened on port 587 to allow only TLSv1.2 and PFS ciphers

  (you can override TLS versions/ciphers via role configuration). TLS

  configuration on port 25 has been left unchanged for maximum

  interoperability with other servers.

Setting-up mail relaying from web and backup servers

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

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

server on web and backup servers 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 those two servers goes through our anti-virus scanner.

1. Update the list of roles for web and backup server to include the mail

   forwarder role.

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

   ::

      ---

      - hosts: web

        remote_user: ansible

        become: yes

        roles:

          - common

          - ldap_client

          - mail_forwarder

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

   ::

      ---

      - hosts: backup

        remote_user: ansible

        become: yes

        roles:

          - common

          - mail_forwarder

2. The next thing is to set-up the configuration for the new role. We can define

   this globally for all servers

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

   ::

      # Define what X.509 certificates should be used for validating

      # the certificate of server we are relaying the mails through.

      smtp_relay_truststore: "{{ lookup('file', '~/mysite/tls/truststore.pem') }}"

      # Make sure any mails directed to localhost root account get

      # forwarded to one of our mail users as well.

      local_mail_aliases:

        root: root john.doe@example.com

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

      # communications server. Don't forget to specify your own IP address (or

      # FQDN) here. Without this option, the SMTP would send out the mails

      # directly.

      smtp_relay_host: comms.example.com

3. Although we have told our web and backup servers to use the communications

   server as relay for non-local mail, the communications server is not aware of

   this. This would result in the communications server refusing all relay

   attempts (if not, it would be an open relay, which is bad).

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

   for exactly this purpose.

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

   ::

      # We want to allow relaying of mails from our web and backup servers

          - mail_server

          - xmpp_server

2. Configure the role.

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

   ::

      # Set the TLS private key and certificate.

      xmpp_tls_certificate: "{{ lookup('file', '~/mysite/tls/comms.example.com_xmpp.pem') }}"

      xmpp_tls_key: "{{ lookup('file', '~/mysite/tls/comms.example.com_xmpp.key') }}"

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

      xmpp_administrators:

        - john.doe@example.com

      # Unfortunately, XMPP can't look-up domains via LDAP, so we need to be

      # explicit here.

      xmpp_domains:

        - example.com

      # Simply point the XMPP server to base DN of LDAP server, and let it use

      # specific directory structure it expects.

      xmpp_ldap_base_dn: dc=example,dc=com

      # Password for logging-in into the LDAP directory.

      xmpp_ldap_password: prosody

      # Where the LDAP server is located at. Full-blown LDAP URIs are _not_

      # supported!

      xmpp_ldap_server: comms.example.com

3. Now, like in case of the mail server role, we need to set-up authentication

   for the XMPP service. In this particular case a single consumer is present -

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

   to use the service.

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

   ::

      # 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

      # passwords. Keep in mind password for prosody user must match with

      # password specified under xmpp_ldap_password.

      ldap_server_consumers:

        - name: postfix

          password: postfix

        - name: dovecot

          password: dovecot

        - name: prosody

          password: prosody

      # And simply append a new group here...

      ldap_server_groups:

        - name: mail

        - name: xmpp

4. Do you know what comes next? Yes! Create some more TLS private keys

   and certificates, this time for our XMPP server ;)

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

      :file:`~/mysite/tls/comms.example.com_xmpp.cfg`

      ::

         organization = "Example Inc."

         country = SE

         cn = "Exampe Inc. XMPP Server"

         expiration_days = 365

         dns_name = "example.com"

         tls_www_server

         signing_key

         encryption_key

   2. Create the keys and certificates for XMPP service based on the template::

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

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

5. Apply the changes::

     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!

   ::

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