Letsencrypt Issue after installing some dependency

These Dependency were installed after which Letsencrypt stopped working

|Webmin version|2.101 |Usermin version|2.001|

|Virtualmin version|7.8.2 |Authentic theme version|21.04 |
|Time on system|Monday, November 20, 2023 3:38 AM|Kernel and CPU|Linux 5.4.0-166-generic on x86_64|
|Processor information|AMD EPYC 7282 16-Core Processor, 4 cores|System uptime|8 days, 0 hours, 34 minutes|

request failed : Web-based validation failed :
/bin/letsencrypt:6: DeprecationWarning: pkg_resources is deprecated as an API. See Package Discovery and Resource Access using pkg_resources - setuptools 68.2.2.post20231119 documentation
from pkg_resources import load_entry_point
/usr/lib/python3/dist-packages/requests/init.py:89: RequestsDependencyWarning: urllib3 (2.1.0) or chardet (3.0.4) doesn’t match a supported version!
warnings.warn("urllib3 ({}) or chardet ({}) doesn’t match a supported "
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/requests_toolbelt/_compat.py”, line 49, in
from requests.packages.urllib3.contrib import appengine as gaecontrib
ImportError: cannot import name ‘appengine’ from ‘urllib3.contrib’ (/usr/local/lib/python3.8/dist-packages/urllib3/contrib/init.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/bin/letsencrypt”, line 11, in
load_entry_point(‘certbot==0.40.0’, ‘console_scripts’, ‘certbot’)()
File “/usr/local/lib/python3.8/dist-packages/pkg_resources/init.py”, line 536, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File “/usr/local/lib/python3.8/dist-packages/pkg_resources/init.py”, line 2931, in load_entry_point
return ep.load()
File “/usr/local/lib/python3.8/dist-packages/pkg_resources/init.py”, line 2518, in load
return self.resolve()
File “/usr/local/lib/python3.8/dist-packages/pkg_resources/init.py”, line 2524, in resolve
module = import(self.module_name, fromlist=[‘name’], level=0)
File “/usr/lib/python3/dist-packages/certbot/main.py”, line 20, in
from certbot import client
File “/usr/lib/python3/dist-packages/certbot/client.py”, line 14, in
from acme import client as acme_client
File “/usr/lib/python3/dist-packages/acme/client.py”, line 16, in
from requests_toolbelt.adapters.source import SourceAddressAdapter
File “/usr/lib/python3/dist-packages/requests_toolbelt/init.py”, line 12, in
from .adapters import SSLAdapter, SourceAddressAdapter
File “/usr/lib/python3/dist-packages/requests_toolbelt/adapters/init.py”, line 12, in
from .ssl import SSLAdapter
File “/usr/lib/python3/dist-packages/requests_toolbelt/adapters/ssl.py”, line 16, in
from …_compat import poolmanager
File “/usr/lib/python3/dist-packages/requests_toolbelt/_compat.py”, line 51, in
from urllib3.contrib import appengine as gaecontrib
ImportError: cannot import name ‘appengine’ from ‘urllib3.contrib’ (/usr/local/lib/python3.8/dist-packages/urllib3/contrib/init.py)

That’s a mess for Python experts, if you have to solve it with those libraries installed like that, I think. But, I can make some recommendations:

I see you have Python libs in /usr/local/lib, which is a weird (dangerous) thing to do on a production system. And, because /usr/local/lib is probably before /usr/lib in the include path, you’re using non-standard libraries for all of your software, not just the ones that need those extra libraries.

So, the right way to install non-system Python dependencies is to create a virtualenv for them (and not install those dependencies for the whole system!), using python -m venv (see docs: venv — Creation of virtual environments — Python 3.12.0 documentation), and install your dependencies there. Best practice is to do this as the non-root user that needs to use these libraries and whatever app depends on them. This will not break all the rest of the Python apps on the system.

The way I would solve this is I’d delete all the crap in /usr/local/lib. On my systems, I don’t allow any software to be installed system-wide that doesn’t come from a system package. That’s a hard rule. If I have to have something not in the OS repos and I need it to be system-wide, I make a package of it, and optionally put it into a repository if it’s needed across many systems.

Then, as the user that needs to run whatever has all these dependencies, I’d create a virtualenv for the app. Some Python apps have a pip or poetry or whatever configuration that allows this to be done relatively easily. e.g. the pipenv command installs all dependencies into a venv and you can switch to it with pipenv shell or run commands in it with pipenv run. There are some newer tools for this, and I can’t remember their names. Python is a gd mess with regard to packaging, and it always has been. There’s so many competing ways to do things, and they all suck and are half-assed and broken for some use cases.

The other side effect i See in my Postfix Email Queue

delivery temporarily suspended: conversation with alt1.aspmx.l.google.com[] timed out while receiving the initial server greeting

I don’t see how that could be related. Python isn’t in our mail stack anywhere, unless you’re using Pyzor, but even that is only used on delivery unless you configured it yourself.

I just cleared the folders inside /usr/local/lib

it works …

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.