Update readme with new duckdns info #278
Conversation
| certbot revoke --non-interactive --cert-path /config/etc/letsencrypt/live/"$ORIGDOMAIN"/fullchain.pem --server $REV_ACMESERVER | ||
| fi | ||
| rm -rf /config/etc/letsencrypt/{archive,live,renewal} | ||
| rm -rf /config/etc/letsencrypt/{accounts,archive,live,renewal} |
There was a problem hiding this comment.
This (and line 244) is the only substantial change not related to the readme. I believe this change solves the issue described by a user on discord https://discord.com/channels/354974912613449730/805754854982025246/1029144612687839262
| ### Validation and initial setup | ||
|
|
||
| * Before running this container, make sure that the url and subdomains are properly forwarded to this container's host, and that port 443 (and/or 80) is not being used by another service on the host (NAS gui, another webserver, etc.). | ||
| * If you need a dynamic dns provider, you can use the free provider duckdns.org where the `URL` will be `yoursubdomain.duckdns.org` and the `SUBDOMAINS` can be `www,ftp,cloud` with http validation, or `wildcard` with dns validation. You can use our [duckdns image](https://hub.docker.com/r/linuxserver/duckdns/) to update your IP on duckdns.org. |
There was a problem hiding this comment.
This was just moved up (from a few lines down)
|
I am a bot, here are the test results for this PR: |
|
It is kind of confusing for me to understand what I am supposed to change with my setup to have things continue to function properly DUCKDNSTOKEN is still used but now I am not sure how since it is not mentioned in the docs, what is the ideal config/variable setup for duckdns? I appreciate that functionality seems to be backwards compatible/maybe still working but I would like to update to whatever the ideal setup/config is and find it hard to get a clear answer in the docs so far with the changes Edit: I think the TLDR is I would appreciate the changelog clarifying this sort of stuff in the future "existing users do not need to change anything, or breaking change, etc" instead of a vague wording about the mechanism changing yet variables are no longer in docs, since I like to not have dead unused variables Also I wanted to say thanks for the work on this container, it IS much appreciated! |
We try to avoid breaking changes as much as possible, and with that in mind, technically there are no changes required for existing users running SWAG. The old way of using DuckDNS was:
The new way of using DuckDNS is:
If you use the old way with the current release of SWAG, the init scripts that run will automatically convert the variables to the new way, and write your token to the dns-conf file for you. Since this was not a breaking change, and no action was required from users, I didn't put emphasis on this information in the changelogs. We do normally use a specific set of wording in the changelog history seen here to indicate breaking changes requiring specific updates to config files. This set of changes is related to variables as opposed to config files, but again, no action is required from existing users. |
|
@nemchik thanks for the reply! I think for this particular container, I find the changelog hard to follow because it does not change every release, it keeps the latest changelog update (sometimes for a handful of container releases). I think the changelog/release notes should be cleared/reset for each release, even if they are only "Update linuxserver base image" I am just a bit sensitive to the recent changes to the nginx base image that required a decent amount of maintainance, and having to dig a bit to understand what I need to change. I proactively was digging a bit for this one to understand what these changes actually were instead of them being handed to me in the changelog |
|
Normally if you look at the https://github.com/linuxserver/docker-swag/releases page, any time the In the case of |
Following up from #277
Not adding an additional changelog entry since the previous PR includes a changelog entry mentioning the changes, but this PR adjusts the readme to reflect the changes.
Removing information about
duckdnsvalidation.It was a custom implementation. It worked fine, but I'm working on making all validation consistent in more ways in the future, so using the
duckdnsplugin fits that goal.The old duckdns variables are only being removed from the documentation, and
duckdnsis being listed as an option forDNSPLUGIN. The old variables will continue to work, the logic is not being removed from the scripts, just translated behind the scenes to work with the plugin.