Certbot-auto renew fails AWS Linux

Please fill out the fields below so we can help you better.

My domain is:


I ran this command:

./certbot-auto renew

It produced this output:

Creating virtual environment…
Installing Python packages…
Installation succeeded.
Traceback (most recent call last):
File “/root/.local/share/letsencrypt/bin/letsencrypt”, line 7, in
from certbot.main import main
File “/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/certbot/main.py”, line 12, 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

My operating system is (include version):

NAME="Amazon Linux AMI"
ID_LIKE=“rhel fedora”

My web server is (include version):

Node.js App.

So far my investigations…

which recommend the script:-

# pip install pip --upgrade
# pip install virtualenv --upgrade
**# virtualenv -p /usr/bin/python27 venv27 **
**# . venv27/bin/activate **
# git clone https://github.com/letsencrypt/letsencrypt
# cd letsencrypt
# ./letsencrypt-auto certonly --debug --standalone -d

or possibly just…

# pip install --upgrade pip
# pip install virtualenv --upgrade
# ./certbot-auto renew

However #pip install --upgrade pip returns the error:-

File “/usr/bin/pip”, line 5, in
from pkg_resources import load_entry_point
File “/usr/lib/python2.7/dist-packages/pkg_resources/init.py”, line 3020, in
working_set = WorkingSet._build_master()
File “/usr/lib/python2.7/dist-packages/pkg_resources/init.py”, line 616, in _build_master
return cls._build_from_requirements(requires)
File “/usr/lib/python2.7/dist-packages/pkg_resources/init.py”, line 629, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File “/usr/lib/python2.7/dist-packages/pkg_resources/init.py”, line 807, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: pip==6.1.1

(The message varies depending on sudo or sudo -i, or sudo -s)

I made some progress..

sudo /usr/local/bin/pip install --upgrade pip // (to upgrade pip)
sudo /usr/local/bin/pip install virtualenv --upgrade // (to upgrade virtualenv)

(as sudo -i)
virtualenv -p /usr/bin/python27 venv27
. venv27/bin/activate

cd letsencrypt
git pull (upgrade letsencrypt)

(and finally...)
./certbot-auto renew --debug

However now I get...

Installing Python packages...
Installation succeeded.
./certbot-auto: line 959: /root/.local/share/letsencrypt/bin/letsencrypt: No such file or directory

If I mkdir /root/.local/share/letsencrypt/bin/letsencrypt prior to running certbot-auto renew --debug the dir is gone and the error above appears!!


The Forum Software want’s this to be different from the anwser to another post, so I’ll explain why…

I think the letsencrypt project is sound, and I’ve supported the KickStarter. I have a couple of sites using the service, and it’s been pretty OK. BUT, with 9 days to go before cert expiry I tried ./cerbot-auto renew on AWS platform. There were a number of issues, which resulted in this post. There was no response after > 24Hrs, so I re-posted without the update to see if anyone responds. In the meantime I tried a few more things and got it to work so updated the re-post, and then was here to update the original. This is to help anyone else who might bump into the same issue.

Guys - you have a good idea, but constructing a swiss-army knife solution might be classically DRY, but it’s adding so much complexity that the implementations are going to be expensive to maintain, and the verity of platforms your knife will need to support will mean that the solutions will be littered with edge cases which will break unexpectedly.

Since cert issuance is such a critical part of a servers base requirements this will result in only the brave choosing this route.

I suggest you review your approach.

Anyway…hope that’s different enough for the Forum S/Ware, here’s the solution response…

Jeeze - that was tricky…turned out the permissions on /webroot folder needed to be change, so…

sudo chmod 777 webroot

was the last piece of the puzzle.

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