Apologies for submitting changes and then immediately undoing some of them. I made a mistake previously by assuming that letsdebug.net tests were sufficient to confirm that this setup was working. But, it turns out that my site was still failing to get valid SSL certs. After digging into the Lego docs I realized I needed to be using different environment variables, which I added here. Once I deployed these changes to a fresh VPS on a different domain with a more straightforward configuration, I confirmed that HTTPS connections to the Traefik dashboard worked just fine.
Please let me know if there's anything else I can do to verify these fixes so I can be extra-super-sure that it's good to go. I'm still new to a lot of this and clearly have lots to learn.
As a treat, I also added generate=false flags to the DNS secrets for other providers, as discussed in my previous PR. Cheers!
I have deployed and tested my changes
Deployed on a fresh VPS, confirmed that HTTPS connections work after deploying these changes
I have made my environment variable changes backwards compatible
This does remove the two environment variables that I introduced in my prior PR. Since those haven't been picked up in a release, I'm hoping this is an acceptable regression. Those two variables are both perfectly valid, they just require an account-wide API token which is unnecessarily risky in my opinion. But if we want to keep them in, I'm happy to put things back as they were :)
<!--
Thank you for doing recipe maintenance work!
Please mark all checklist items which are relevant for your changes.
Please remove the checklist items which are not relevant for your changes.
Feel free to remove this comment.
-->
Apologies for submitting changes and then immediately undoing some of them. I made a mistake previously by assuming that letsdebug.net tests were sufficient to confirm that this setup was working. But, it turns out that my site was still failing to get valid SSL certs. After digging into the Lego docs I realized I needed to be using different environment variables, which I added here. Once I deployed these changes to a fresh VPS on a different domain with a more straightforward configuration, I confirmed that HTTPS connections to the Traefik dashboard worked just fine.
Please let me know if there's anything else I can do to verify these fixes so I can be extra-super-sure that it's good to go. I'm still new to a lot of this and clearly have lots to learn.
As a treat, I also added `generate=false` flags to the DNS secrets for other providers, as discussed in my previous PR. Cheers!
* [x] I have deployed and tested my changes
Deployed on a fresh VPS, confirmed that HTTPS connections work after deploying these changes
* [x] I have [updated relevant versions in `abra.sh`](https://docs.coopcloud.tech/maintainers/upgrade/#updating-versions-in-the-abrash)
No version update needed
* [x] I have made my environment variable changes [backwards compatible](https://docs.coopcloud.tech/maintainers/upgrade/#backwards-compatible-environment-variable-changes)
This does remove the two environment variables that I introduced in my prior PR. Since those haven't been picked up in a release, I'm hoping this is an acceptable regression. Those two variables are both perfectly valid, they just require an account-wide API token which is unnecessarily risky in my opinion. But if we want to keep them in, I'm happy to put things back as they were :)
* [x] I have added a [release note entry](https://docs.coopcloud.tech/maintainers/upgrade/#creating-new-release-notes)
Not necessary
It's all good, thanks for following up! One minor comment again but otherwise, it's looking good to me. I think the only way to truly verify things work is for you to just keep plugging away at it 😆 We'll get there ✅
It's all good, thanks for following up! One minor comment again but otherwise, it's looking good to me. I think the only way to truly verify things work is for you to just keep plugging away at it 😆 We'll get there ✅
I would go for something shorter in the naming, e.g. cf_dns_token/cf_zone_token, because of this really annoying limitation.
I would go for something shorter in the naming, e.g. `cf_dns_token`/`cf_zone_token`, because of this [really annoying limitation](https://docs.coopcloud.tech/maintainers/handbook/#r015-long-secret-names).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Apologies for submitting changes and then immediately undoing some of them. I made a mistake previously by assuming that letsdebug.net tests were sufficient to confirm that this setup was working. But, it turns out that my site was still failing to get valid SSL certs. After digging into the Lego docs I realized I needed to be using different environment variables, which I added here. Once I deployed these changes to a fresh VPS on a different domain with a more straightforward configuration, I confirmed that HTTPS connections to the Traefik dashboard worked just fine.
Please let me know if there's anything else I can do to verify these fixes so I can be extra-super-sure that it's good to go. I'm still new to a lot of this and clearly have lots to learn.
As a treat, I also added
generate=falseflags to the DNS secrets for other providers, as discussed in my previous PR. Cheers!Deployed on a fresh VPS, confirmed that HTTPS connections work after deploying these changes
abra.shNo version update needed
This does remove the two environment variables that I introduced in my prior PR. Since those haven't been picked up in a release, I'm hoping this is an acceptable regression. Those two variables are both perfectly valid, they just require an account-wide API token which is unnecessarily risky in my opinion. But if we want to keep them in, I'm happy to put things back as they were :)
Not necessary
It's all good, thanks for following up! One minor comment again but otherwise, it's looking good to me. I think the only way to truly verify things work is for you to just keep plugging away at it 😆 We'll get there ✅
@@ -9,3 +9,1 @@- cf_email- cf_api_key- cf_dns_api_tokenI would go for something shorter in the naming, e.g.
cf_dns_token/cf_zone_token, because of this really annoying limitation.Fixed! Maybe someday we'll have computers that can handle strings with more than 64 characters /s
7d5d6efa29tobe739f2c73be739f2c73to47d8260f34