Checking for new version…
Creating virtual environment…
Installing Python packages…
Installation succeeded.
Requesting root privileges to run letsencrypt…
/root/.local/share/letsencrypt/bin/letsencrypt certonly -d fryingpanadventures.com
Traceback (most recent call last):
File “/root/.local/share/letsencrypt/bin/letsencrypt”, line 7, in
from letsencrypt.main import main
File “/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/letsencrypt/main.py”, line 11, in
import zope.component
File “/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/zope/component/init.py”, line 16, in
from zope.interface import Interface
ImportError: No module named interface
Still, shouldn’t there also be an authentication method specified? The output shows the fryingpanadventures domain but not authentication method. I’d assumed that the python errors were due to “no named import” (that it was missing a command line argument).
Well, technically, they have. (Certbot is now with the EFF!) But I've had trouble with some of the python modules myself, and the vague error messages make it hard to identify exactly what the problem is.
I can totally understand why people are using third party clients.
@noc_amaeya never responded to our questions, so it’s hard to tell if his issues are the same as yours (even if the errors look the same).
When I had my python problems, it was due to letsencrypt (0.5) requiring more recent versions of python libraries than was available through ports (I’m on FreeBSD). I was able to solve the issue by downgrading letsencrypt to 4.2, everything worked fine after that. (I’ve since been able to upgrade again.)
As silly as it sounds, have you tried going backwards? (To an earlier version?)
I believe this is a similar issue as before with Amazon Linux path issues being all out of whack. Amazon has never been able to get Python working correctly since day one so this doesn't surprise me.
It appears that this is just another case of lib64 vs lib and path issues.
Manually installing pip deletes the /usr/bin version and puts it under /usr/local/bin, even on an upgrade, so you have to fix that up manually. I'm not entirely sure what will happen if Amazon ever bothers to update it, but this definitely needs to be part of the Amazon-specific script.
If you don't set the links back up, then it needs hash -r to run pip at all, and stops working with sudo.