Update Dynu code and .ini file #483
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thanks for opening this pull request! Be sure to follow the pull request template!
|
dynu is a different plugin and it's abandoned |
|
I am a bot, here are the test results for this PR:
|
|
According to docker logs |
|
I am a bot, here are the test results for this PR:
|
|
I'm also using dynudns and can confirm these changes have to be made to be able to use the dynu plugin. |
|
I am a bot, here are the test results for this PR:
|
|
This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions. |
There was a problem hiding this comment.
Noting that https://pypi.org/project/certbot-dns-dynudns/ and https://github.com/DustyRah/certbot-dns-dynudns/ do not mention the new config file name, but I'm guessing the old plugin that was deprecated in #439 was due to not being updated to newer code standards in certbot, and the new plugin introduced in #463 may have been a fork of the original that updated the code but maybe did not update the readme. I'm not positive, but the rename makes sense given how other current plugins work with the config naming.
|
This change is not desired. There are two separate dynu plugins. One is old and abandoned ( The old and abandoned plugin force downgrades a bunch of the certbot dependencies because it has old deps hardcoded. We do not want that because it affects everyone, not just dynu users. It seems the real issue here is, when the dynu employees forked the abandoned plugin and published it under a different name, they only changed the name externally (package name). Internally it still uses the old references. This requires putting in an exception to use the new plugin package but with the old internal name. I'm short on time these days and have no ability to test and trouble shoot so it will have to come from someone else. EDIT: I take it back. While most of what I wrote above is true, I took another look at the full log and now see that it still has the new plugin installed, but it references the old plugin's name. I assumed it would force install the old plugin on startup but doesn't. So while not a proper solution, I guess it would work. |
Yeah it looks like we removed the old plugin in #439 and added the new plugin in #463 but there was some confusion on our part. 4b4c103 added Apparently even if we had done the above correctly, the new dynudns the correct naming we need here is just dynu.
|
There was a problem hiding this comment.
Merge conflicts need to be resolved.
The changes in README.md can be completely reverted (no need to fix the merge conflict in this file, if you just revert it entirely our build system will update README.md from readme-vars.yml).
readme-vars.yml needs a changelog entry.
|
To be honest I'm kind of confused which approach we'll take now so I can make the appropriate adjustments. |
I pushed some adjustments for you to resolve the merge conflict and add a changelog entry. |
|
I am a bot, here are the test results for this PR:
|
Description:
Running SWAG for the first time I got errors while setting it up to work with Dynu DNS challenge. The code for
DNSPLUGINflag was wrongly named and the .ini config file had the wrong name.Benefits of this PR and context:
If it's not fixed, every single Dynu DNS user will have to make the same adjustments.
How Has This Been Tested?
I kept making adjustments to
docker-compose.ymland the filesystem until there were no errors shown.Source / References: