While attempting to provision a remote (trellis provision production, in this case), I get the following error at the very beginning of the process (right after Running command => ansible-playbook server.yml -e env=production):
ERROR! the role 'TypistTech.trellis-cloudflare-origin-ca' was not found in /Users/username/Websites/sitename/trellis/roles:/Users/username/Websites/sitename/trellis/vendor/roles:/Users/username/Websites/sitename/trellis
The error appears to be in '/Users/username/Websites/sitename/trellis/server.yml': line 35, column 7, but may be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- { role: wordpress-setup, tags: [wordpress, wordpress-setup, letsencrypt, cloudflare-origin-ca] }
- { role: TypistTech.trellis-cloudflare-origin-ca, tags: [cloudflare-origin-ca, wordpress-setup], when: sites_using_cloudflare_origin_ca | count }
^ here
exit status 1
Interestingly, I do see what appears to be a correctly installed role in trellis/vendor/roles:
This behavior is now visible in 2 projects that have been in Dev for a while and are ready to go to remote:
Trellis CLI = 1.8.0
Trellis = 1.18.0
Bedrock = 1.21.0
trellis-cloudflare-origin-ca = 0.8.0
Attempted thus far:
Reviewed https://github.com/TypistTech/trellis-cloudflare-origin-ca (all settings/changes present in both projects)
Ran trellis galaxy install (got Cloudflare (0.8.0) is already installed, skipping.)
Deleted vendors
vagrant destroy, vagrant up
trellis init --force
Other than the above, the only recent changes on one of the two projects I’m describing are fixes recommended by @swalkinshaw at Can't deploy locally: TASK [wp-cli : Install WP-CLI], which I added after TASK [wp-cli : Install WP-CLI] failed almost exactly as reported in that thread.
Minor update to share: Disabling all cloudflare-origin-ca settings in the project allowed error-free provisioning and deployment (except for an unrelated SatisPress/Composer issue for which I already have a workaround).
I imagine this is no surprise, but it’s nice to have confirmation that the issue is in my cloudflare-origin-ca implementation, and not something deeper that might prevent progress overall.
That said, I’d like to go back to Cloudflare certs because I’d love to avoid whatever dance might still be required these days with unproxying the Cloudflare A Record to enable LE renewal.
Update: I’m now getting the same behavior on a second machine with a different (third) project.
This second machine is an older iMac with Trellis CLI 1.7.0. Both machines have successfully provisioned remotes with cloudflare-origin-ca in the past (in other projects), and there is nothing new in the configuration of either box (AFAIK).
@TangRufus, any ideas about what I might be missing?
If I cannot use the role on new servers, I’d still prefer to use manually downloaded Cloudflare certs via ssl: > provider: manual in place of LE certs.
Unless someone can convince me otherwise? In the past, if I remember correctly, LE renewals required the applicable A Record to be unproxied for renewal. Even at a little less than every 90 days instead of 30, this seems like trouble. Unless, of course, there is a workflow these days that avoids that dance…
Question: Wouldn’t reprovisioning an existing server with Cloudflare SSL (using cloudflare-origin-ca) cause the same incomplete provisioning issue with that existing server?
