This is particularly painful when using multisite. If we add a new domain under site_hosts and redeploy, letsencrypt certificates will _not_ be updated. Trying to access the new domain will yield a NET::ERR_CERT_AUTHORITY_INVALID error in Chrome (or SEC_ERROR_UNKNOWN_ISSUER in Firefox) thus due to HSTS rendering the site completely inaccessible.
The workaround mentioned here does not work. It seems the only way around it is to completely wipe the server and start over every time we add a new domain.
Thank you. If you're interested, could you let us know whether #630 resolves the issue for you?
I am unsure whether it works, because the patch creates numerous other issues.
First I had to ssh into the deployed server and manually update wp-cli to nightly (using wp --allow-root cli update --nightly), because deployment would crash otherwise.
I was then able to run the deployment script (./deploy.sh production example.com), but nothing changed even after rebooting the server. The SSL issue is still there.
I am now trying to run ansible-playbook server.yml -e env=production --tags "letsencrypt", however I get the following error:
TASK [letsencrypt : Create needed Nginx confs for challenges] ******************
System info:
Ansible 2.1.1.0; Linux
Trellis at "Require Ansible 2.0.2 and remove deploy_helper"
---------------------------------------------------
[u"{{ lookup('pipe', 'curl -4 -s https://api.ipify.org') }}"]:
lookup_plugin.pipe(curl -4 -s https://api.ipify.org) returned 6
fatal: [example.com]: FAILED! => {"failed": true}
EDIT: It finally worked after I wiped all the letsencrypt related files (rm -rf /var/lib/letsencrypt /usr/local/letsencrypt /srv/www/letsencrypt /etc/nginx/ssl/letsencrypt /etc/ssl/certs/lets-encrypt-x3-cross-signed.pem) and re-provisioned the server (ansible-playbook server.yml -e env=production).
@vercotux: Thank you for testing. 馃憤
I'm not sure what the wp-cli issue was, but it sounds like you've handled it.
server.yml playbook (for provisioning) with the letsencrypt tag.The returned 6 error with the curl -4 -s https://api.ipify.org command is quite unexpected, given that its use in the ip_whitelist variable only comes into play in the ferm and fail2ban roles that you did not run. I don't recall ever seeing returned 6 but I'm guessing it is a connectivity issue with curl, in which case trying again later is often the solution, as dissatisfying as that may be. #630 didn't adjust any related code, but if that particular error persists, you could add -vvvv to the end of the ansible-playbook command to get more verbose debug output.
Most importantly, I notice this line in your system info:
Trellis at "Require Ansible 2.0.2 and remove deploy_helper"
There have been many updates to Trellis since that particular CHANGELOG entry. Testing #630 would probably only be worthwhile on top of a fully up-to-date version of Trellis.
I am unsure how I can update trellis when it is bundled with a project that is already in production. This is not documented anywhere.
You are under no obligation to test further, of course, and I realize you've resolved your initial problem. In any case, here are some ideas for how to update Trellis.
Test on staging. First, I would set up a staging site for testing, using a new separate server in hosts/staging and set up your group_vars/staging similar to your group_vars/production. I would avoid Let's Encrypt rate limits by specifying the staging letsencrypt_ca in group_vars/staging/main.yml. This allows you to update Trellis (see below) and get server.yml running without errors. However, it is not a real certificate authority, so your browser will post a warning when you visit the staging site.
After you've updated Trellis and tested that the playbook completes without errors, you will know what changes your production site will need to accommodate the Trellis updates. Make a backup of your production server/files, then make the changes to production and run server.yml and everything should work (because you've practiced on staging).
Git. If you originally git cloned Trellis and have been committing your changes, you can use git to merge in updates from upstream Trellis. If your Trellis git project only includes Trellis, you may find some guidance at https://discourse.roots.io/t/2440/12. Alternatively, if your project is set up like roots/roots-example-project.com (includes roots/bedrock and roots/sage), you may find some guidance at https://discourse.roots.io/t/best-practices-to-update-trellis/5386.
Manually. I strongly recommend using git, but I've heard that some people update Trellis by just getting a fresh copy of Trellis and pasting in their edited hosts and group_vars files. Using this approach, you would need to check upstream Trellis for updates to group_vars and manually apply the changes (e.g., #622 added a new group_vars/all/helpers.yml file and adjusted formatting for site_hosts, etc.). Of course, if you have customized files outside of the hosts and group_vars directories, you would need to add your customizations to the corresponding new files as well.
May I suggest adding this type of info to the main documentation page (perhaps under the topic called "Updating Trellis")? It would be enormously helpful to everyone! Thank you for all the amazing work!
@fullyint this is done right?
Yep! Should be resolved by #630.
Most helpful comment
You are under no obligation to test further, of course, and I realize you've resolved your initial problem. In any case, here are some ideas for how to update Trellis.
Test on staging. First, I would set up a staging site for testing, using a new separate server in
hosts/stagingand set up yourgroup_vars/stagingsimilar to yourgroup_vars/production. I would avoid Let's Encrypt rate limits by specifying the stagingletsencrypt_caingroup_vars/staging/main.yml. This allows you to update Trellis (see below) and getserver.ymlrunning without errors. However, it is not a real certificate authority, so your browser will post a warning when you visit the staging site.After you've updated Trellis and tested that the playbook completes without errors, you will know what changes your production site will need to accommodate the Trellis updates. Make a backup of your production server/files, then make the changes to production and run
server.ymland everything should work (because you've practiced on staging).Git. If you originally
git cloned Trellis and have been committing your changes, you can use git to merge in updates from upstream Trellis. If your Trellis git project only includes Trellis, you may find some guidance at https://discourse.roots.io/t/2440/12. Alternatively, if your project is set up like roots/roots-example-project.com (includes roots/bedrock and roots/sage), you may find some guidance at https://discourse.roots.io/t/best-practices-to-update-trellis/5386.Manually. I strongly recommend using git, but I've heard that some people update Trellis by just getting a fresh copy of Trellis and pasting in their edited
hostsandgroup_varsfiles. Using this approach, you would need to check upstream Trellis for updates togroup_varsand manually apply the changes (e.g., #622 added a newgroup_vars/all/helpers.ymlfile and adjusted formatting forsite_hosts, etc.). Of course, if you have customized files outside of thehostsandgroup_varsdirectories, you would need to add your customizations to the corresponding new files as well.