Ansible playbook

If you want to set up multiple mail servers then automation is your friend. Nowadays Ansible is commonly used for that purpose. If you are dealing with system administration you should have such a tool in your toolbox.

I have created an Ansible playbook on Github that you can download and use. Using it is pretty simple:

apt install ansible git
git clone https://github.com/Signum/ispmail-bullseye-ansible.git
cd ispmail-bullseye-ansible/ansible
ansible-playbook ispmail.yml -c local

By default the playbook determines your external IP address and uses the .nip.io domain to use for setting up your mail server. I just realized that nip.io does not handle IPv6 correctly. So I’ll have to switch to a more versatile domain like sslip.io soon.

8 thoughts on “Ansible playbook”

  1. I get this error:
    TASK [ispmail-packages : install software packages] ****************************************************************************************************************************************************************************************
    fatal: [ispmail.fritz.box]: FAILED! => {“changed”: false, “msg”: “Failed to lock apt for exclusive operation: Failed to lock directory /var/lib/apt/lists/: E:Could not get lock /var/lib/apt/lists/lock. It is held by process 1986 (python3)”}

    Can I just ignore it?

        1. Daniél Lecoq

          Okay, I figured out what “AHOFF” meant by running from either laptop or local, but not both.
          Since my VPS was without root login, only users + sudo, I assumed that if I connected to it with SSH, it would count as local, but apparently not. So I got all those errors “AHOFF” had above. I guess that count as “both”, eg ssh from the “laptop” (okay, I’m on a linux desktop) to the “local”. If you use local, you have to sit at that hardware, not connect to it remotely. So what I did was to first reinstall the VPS to remove whatever half done things that were there, then UNSAFELY allow root login via ssh, because however I tried to change in the ansible.cfg to my username instead of rot, it didn’t work.
          When running ispmail ansible on my home computer and applying it on the VPS, it worked without errors.

          I do have some issues though. Domain names… Let’s say that my VPS has the URL webmail.example.com other things like http://www.example.com or forum.example.com are going to other servers.
          If I set it in the /ansible/group_vars/all to be “ispmail_fqdn: webmail.example.com”. The certificates, apache2, webmail and all works. but the sample email address becomes “john@webmail.example.com”.
          If I set “ispmail_fqdn: example.com” the sample email address is correct with “john@example.com”, but let’s encrypt, apache2, webmail and so won’t work, because https://example.com isn’t pointing to that server… It doesn’t even exist. Only www. webmail. forum. I’ve tried to point *.example.com to the VPS, but it doesn’t help either.
          Any ideas?
          I guess I’ll go through the guide instead, I’ve done it a few times and I know it works, but I thought that I might as well test ansible this time, to learn how it works.

  2. Eben van Deventer

    There appears to be an issue with calling certbot in the ansible playbook. Having edited ./group_vars/all to point to my fqdn_id, I have run the ansible playbook and it errors when restarting postfix (could not find cert files). running it again, it seems to ignore this and gets to apache2 restart, which again has the same issue. Manually running certbot at this point and running it again allows it to complete, but it won’t access the webadmin?
    Perhaps we need better documentation on ./group_vars/all?

  3. I forked this project on my gitlab repo and corrected /enhanced it : https://gitlab.com/baptisterichard/ispmail-bullseye-ansible/-/tree/main

    – the server FQDN vs email domain remak by Daniel Lecoq above is corectly handled
    – the certificate is waaaaay better handled (removed all links to an external project, added a simple task instead)
    – added the support for plus-aliases, wildcard aliases and catchall adresses
    – automated DKIM signing
    – Enhanced security so only predefined IP adresses can SSH and access rspamd webUI
    – Added some scripts to CRUD (well, CD only, RU mad ?) the database

    Feel free to take a look and copy any part you wish. I’m using the same licence anyway.

    1. Christoph Haas

      Excellent. Very nice work. I just need to understand the new alias logic that you added. Could you elaborate on that? Would be nice to merge your fixes while keeping the playbook matching the actual guide.

      1. Sure thing.

        plus-aliases are reallwy widespread now. Basically, anything between the ‘+’ and the ‘@’ sign should be ignored/removed for delivery. This way, john+workaround@example.org and john+linuxtips@example.org are both delivered to john@example.org, without any configuration whatsoever (as long as the mailbox john@example.com exists, of course). These are also called subaliasing, as they don’t need to actually create any form of alias.

        The downside of these subaliases (or plus-aliases) if that the ‘+’ character is sometimes not recognized as valid in various systems. In some cases, I also encountered systems that actually stripped the ‘+something’ before recording the address, nullifying the filtering effect.

        Now that’s when wildcard aliases come in handy.

        Wildcard aliases need to be created, and use one astersisk ‘*’ as a wildcard or joker character, matching _anything_.
        If I make an alias “jack.*@example.com” pointing to john@example.com, any email sent to jack.(anythingGoesThere)@example.com is delivered to john@example.com, without the sender’s knowledge that this email was rerouted (kinda like a forward in a way). The neat part is that you can use any “standard” characters instead of the ‘+’.

        I use a dot ‘.’ as separator between the “prefix” and the “wildcard part”, but it’s merely an habit and is in no way required. Aliasing “jack*@example.com” or “jack_*@example.com” would have worked just as well.

        All I’ve done still matches the actual guide (except that I now display the DKIM public key). I’ve corrected some things that were meant to work but didn’t quite well, and added some others, but did not essentially break the way anything worked.

        As for merging, I’m not sure how I could do that between my gitlab and your github.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to Top