miigotu / certbot-dns-godaddy

A godaddy dns plugin using lexicon for cerbot to authenticate and retrieve letsencrypt certificates

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ImportError with latest version

wolfsblu opened this issue · comments

Starting with the latest version from 2023-07-14 there seems to be an issue with the ACME client.py file, e.g. running:

docker run --rm -v /etc/letsencrypt/:/etc/letsencrypt/ -v /var/lib/letsencrypt/:/var/lib/letsencrypt/ miigotu/certbot-dns-godaddy certbot help

yields

Traceback (most recent call last):
  File "/usr/local/bin/certbot", line 5, in <module>
    from certbot.main import main
  File "/usr/local/lib/python3.10/site-packages/certbot/main.py", line 6, in <module>
    from certbot._internal import main as internal_main
  File "/usr/local/lib/python3.10/site-packages/certbot/_internal/main.py", line 28, in <module>
    from certbot import crypto_util
  File "/usr/local/lib/python3.10/site-packages/certbot/crypto_util.py", line 42, in <module>
    from certbot import interfaces
  File "/usr/local/lib/python3.10/site-packages/certbot/interfaces.py", line 21, in <module>
    from acme.client import ClientBase
ImportError: cannot import name 'ClientBase' from 'acme.client' (/opt/certbot/src/acme/acme/client.py)

Looks like this interface was removed from acme in version 2.6.0. I've worked round this issue by editing the certbot dependency in pyproject.toml to be certbot = ">=0.31.0,<2.6.0". I installed by creating and activating a venv, then doing:

pip install 'acme<2.6.0' 'certbot<2.6.0' .

WARNING: Other (I believe unrelated) problems have prevented me from testing this fully! However, certbot does at least now fail in the normal manner.

Wouldn't it simply be better to use ClientV2 instead of ClientBase and limiting the usable Certbot to 1.x.x?

Also, unrelated to this issue: why is this plugin limited to urllib3 <2.0.0? This plugin doesn't use urllib3 directly anywhere and gives me some trouble on Gentoo. I'm removing this plugin from my Gentoo overlay as I believe some maintainer choices are giving me more trouble than it's worth. And limiting the plugin to Certbot 1.x.x is a BIG limitation IMO for something that should be easy to fix.

Feel free to send a PR. I made this plugin a long time ago because I had a personal need for it. I will accept PRs and continue to maintain it administratively, but I currently have no need for it so I can't spend time working on it. I have dozens of other projects that demand my time.

I could change the code, but I wouldn't be able to test it unfortunately, as I don't use any GoDaddy services myself. I only offered the plugin in my Gentoo Overlay.
I wouldn't want to break the plugin any further for other users.

(And I'm also not really familiar with Poetry, so there's that..)

By the way, with regard to the ClientBase vs. ClientV2 thing: I looked at certbot_dns_godaddy.py and it does not even use ClientBase. It's probably due to the fact Certbot is limited to 1.x.x while the acme package is not.

It's limited to 1.x.x in the last release because it was the only way people could get it to work and they asked me to pin it. Using the latest certbot isn't necessary, you just create a virtualenv and install this in it and call certbot with the params inside that venv.

python3 -m venv ~/certbot-env
~/certbot-env/bin/pip install -U certbot-dns-godaddy
~/certbot-env/bin/certbot <parameters>

You don't need to uninstall or overwrite the system certbot. You don't need to uninstall any snaps. You don't need to use docker. pip will install the correct version of certbot and acme for the plugin and it will work.

Also, the virtualenv keeps this install from contaminating the system or user python environment, as well as preventing any changes to the system or user python environment from breaking certbot-dns-godaddy.

It isn't difficult to use, you just have to know how to use python and how to isolate application environments.

This is free software I donated my time on, and released to the public for free. I have no obligation to anyone using it, nor do I owe anyone any guarantees.

I have over a million lines to change in another project, and a couple hundred thousand to write in another, that actually pays me money. If I get bored and start feeling generous I will come back to this and make some change, maybe get the snap working.

It's limited to 1.x.x in the last release

If you do so, you should probably also pin the acme library to 1.x.x.

By the way, if I force the 0.2.2 version of the plugin using pip in a venv, everything works just fine, so I don't even think the pinning of Certbot to 1.x.x is necessary? It's just that acme and certbot need to be aligned to both be v2 or v1.

Not sure what's going on with @wolfsblu Docker though..

I don't think you understand how dependencies work. If certbot is pinned, it also limits the version of acne that is installed because that version of certbot has acme pinned to the versions that work with it.

Apparently nobody wants to use a 3rd party application correctly, because you are ALWAYS supposed to use it with a virtual environment (venv specifically for python3)

Instead of following my instructions, you're telling me how to do it but it obviously isn't working your way, and was not intended to work your way.

You don't install your own certbot or your own acme. This is all you do for installation, entirely.

python3 -m venv /some/path
pip install certbot-dns-godaddy

Then you add that bin path to the profile that is using it.

If you are on a distro where .profile is where your path is set:

echo "export PATH=/some/path/bin:$PATH" | tee -a . profile
source .profile # or log out and back in
|``

Then you use it. It's that simple. You don't need to worry about dependencies, they are handled by the build process. 
and the 

I don't think you understand how dependencies work. If certbot is pinned, it also limits the version of acne that is installed because that version of certbot has acme pinned to the versions that work with it.

The acme library does not have certbot pinned, as it can also be used without Certbot:

https://github.com/certbot/certbot/blob/3e84b94308a9919ef9affe5dac8d5a65554cda67/acme/setup.py

And Certbot has acme pinned with just a >={version}:

https://github.com/certbot/certbot/blob/3e84b94308a9919ef9affe5dac8d5a65554cda67/certbot/setup.py#L39

You could say this is a limitation of Certbot, but they probably never envisioned a situation where one would pin Certbot to an older version. Might be worth opening an issue for on the Certbot repo.

Anyway, currently if you pin Certbot to 1.x.x, pip will happily install acme-2.6.0 for certbot-1.32.0.

But hey, if you know better, best of luck 🙂

It is a bug in certbot, where they set acme>=${version} rather than acme~=${version} or acme^=${version} or acme==${version}, all of which would prevent this issue.

I have pinned both to ~=2.6.0 for now. Hopefully it works because I don''t care to spend any time on this project anymore. The original purpose was certbot required me to match the python versions they set in their requirements, which was >=3.6<4.0. This limited me from requiring newer versions of acme.

Changing the minimum python version to 3.7 like everyone else allows me to use a newer acme and certbot, and idc about their guidelines anymore. I don't use this project or theirs, and I have other projects that actually pay bills lol.

Thanks for taking the time @miigotu, it's appreciated!
Big version jump for pypi 0.2.4 -> 2.6.0 ;o)

Thanks for taking the time @miigotu, it's appreciated! Big version jump for pypi 0.2.4 -> 2.6.0 ;o)

I figured it would be easier to keep track for people if the version of this plugin was the same as the version of certbot/acme it was built with. It also lets me know with one look what version they should all be inside the venv.

@wolviex is it working now?