.. contents:: :local:

          value: /etc/ssl/certs/truststore.pem

          value: /etc/ssl/certs/truststore.pem

   5. And just one more small tweak - we need to provide a truststore PEM file

      containing all CA certificates in the chain. In this particular case we

      have a super-simple hierarchy (root CA is also issuing the end entity

      certificates), so simply make a copy of the ``ca.pem``. The

      ``truststore.pem`` file is picked-up automatically by many other roles::

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

         - "~/mysite/tls/truststore.pem"

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

setting-up a mail server host (with authenticated IMAP, SMTP etc), and one for

setting-up a mail forwarder (for having the rest of your servers relay through

the mail server host).

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

``comms.example.com``, but some modifications will be necessary to

configuration.

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

role.

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

      ---

      - hosts: communications

        remote_user: ansible

        sudo: yes

        roles:

          - common

          - ldap_client

          - ldap_server

          - mail_server

2. Let's configure the role next.

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

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

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

      # Here we need to point to the base DN of LDAP server. A bunch of entries

      # will need to exist under it for service to function correctly, though.

      mail_ldap_base_dn: dc=example,dc=com

      # Separate LDAP entries are used for Postfix/Dovecot

      # authentication. Therefore we have two passwords here.

      mail_ldap_postfix_password: postfix

      mail_ldap_dovecot_password: dovecot

      # Setting uid/gid is optional, but you might have a policy on how to

      # assign UIDs and GIDs, so it is convenient to be able to change this.

      mail_user_uid: 5000

      mail_user_gid: 5000

      # Finally, 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 server ;)

      smtp_allow_relay_from:

         - 10.32.64.20

3. There are two distinct mail services that need to access the LDAP directory -

*Postfix* (serving as an SMTP server), and *Dovecot* (serving as an IMAP

server). These two need their own dedicated LDAP entries on the LDAP server in

order to log-in. Luckily, it is easy to create such entries through the options

provided by the LDAP server role. In addition to this, the Postfix and Dovecot

services will check if users are members of ``mail`` group in LDAP directory

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

comes with a simple option for creating groups.

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

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

      # under for mail_ldap_postfix_password/mail_ldap_dovecot_password.

      ldap_server_consumers:

         - name: postfix

           password: postfix

         - name: dovecot

           password: dovecot

      ldap_server_groups:

         - name: mail

4. Ok, so now our SMTP and IMAP service can log-in into the LDAP server to

   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. Keep in mind that you shold

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

   :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

            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

            objectClass:

              - inetOrgPerson

            uid: janedoe

            cn: Jane Doe

            sn: Doe

            userPassword: janedoe

            mail: jane.doe@example.com

          # Now, let's add the two users to the mail group. Observe that we use

          # the "state: append" option. This is a bit of a cheat since 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

          # the two users).

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

            uniqueMember:

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

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

            state: append

          # Let's register our domain in LDAP directory.

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

            objectClass: dNSDomain

            dc: "example.com"

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

          # for our domain.

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

            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 SMATP/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::

     ansible-playbook playbooks/site.yml

7. 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 yout 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 test out the mail server using mail client of your

choice.