My team has ran into a possible issue with letsencrypt. Let me guide you through our process.
First we create a new project called project1. It’s project structure looks as follows:
project1/
- site/
- trellis/
We then use trellis to provision and deploy project1. Next, we start project2 with the same structure as above. Using trellis we provision and deploy to the same server that project1 resides on. I believe that the letsencrypt cron file is getting overwritten during provisioning or deployment of project2.
Here is an example of what I am referring to:
/var/lib/letsencrypt/renew-certs.py
# sample lines
letsencrypt_cert_ids = {'example2.com': u'cda32c9'}
for site in ['example2.com']:
Notice in the above lines there is a dictionary and list with names that refer to the second project only. This means that when the letsencrypt cron runs it will only renew the second project’s certs.
I would think (at least in our use case) that this bit of code should somehow be project independent. It might be worth somehow keeping an inventory of enabled SSL certs (along with a date when it was installed) on a server so that the letsencrypt cron knows which certs to renew. In our case we may have one to many wordpress projects residing on the same server.
This structure does not make sense when serving multiple clients. Ideally, I would like to keep our clients site code isolated into its own repository. With the above, I would need to maintain a monolithic codebase containing code from many clients. Any suggestions?
Note that you could use three separate repos for site-1, site-2, and trellis. If doing so, you’d need to comment out repo_subtree_path for the respective sites.
In my case I have production sites and staging sites on the same server for a particular client. Having multiple sites on the same server is no problem, except when production and staging are mixed. When I run ansible-playbook server.yml -e env=production --tags letsencrypt, that will overwrite any letsencrypt renewal settings for staging, and vice-versa. In this case, I can work around it by listing all sites (staging and production) in production/wordpress_sites.yml, and just ignore staging/wordpress_sites.yml. I just wonder if I’m missing something here or if there is a better way to handle this?
Yes, I have experienced this as well. What I have done in the meantime is to create a unique renew-certs-sitename.py (add the site and cert ID correctly) and add a new cron.d task to point to this, you need to confirm the permissions are the same as well. Do this for each site that you have a trellis setup for. Also, if you have any domains that no longer point to this server, you might have an issue for all sites since it might trigger a renewal error.