Letsencrypt-auto openssl module not found EC2


#1

I’m running on a Linux AMI EC2, and I get this:

./letsencrypt-auto
Updating letsencrypt and virtual environment dependencies…
Running with virtualenv: sudo /home/ec2-user/.local/share/letsencrypt/bin/letsencrypt --help
Traceback (most recent call last):
File “/home/ec2-user/.local/share/letsencrypt/bin/letsencrypt”, line 7, in
from letsencrypt.cli import main
File “/home/ec2-user/.local/share/letsencrypt/local/lib/python2.7/dist-packages/letsencrypt/cli.py”, line 15, in
import OpenSSL
ImportError: No module named OpenSSL

I have OpenSSL installed and I can see that the module is available to python2.7
Any ideas or anyone else having the same issue?


Let's Encrypt Client on Amazon Linux - No module named _cffi_backend
#2

I tried to reproduce this on a new Amazon Linux AMI 2015.09.1 x86_64 HVM GP2 instance.

Here’s the exact sequence of commands I ran after first SSHing to the instance:

sudo yum update && sudo yum install git
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
sudo ./letsencrypt-auto --debug

Did not encounter any errors. Do you see any obvious difference to what you ran, or could you try it that way?


#3

for some reason I had to install augeas library and dialog, and now it seems to work


#4

Can you expand on that please @fistofthenorthstar?

yum install augeas

worked, but not sure about the dialog. I’m getting the same error.


#5

Would really appreciate some insight into how this was resolved @fistofthenorthstar. I’m getting the same error.


#6

@pfg can you provide your full output running the commands to do a fresh install on Amazon Linux 2015.09?

I’m encountering similar issues but I think it might be related to using an older AMI. Not entirely sure what the cause is yet.

Update 1:
I am still investigating the issue as we speak, but I think this is somehow related to Python package path issues when running as a user using sudo vs running directly as root.

When I run as root, I think the python package path is different than a user running as sudo and that might explain the issue calling

Update 2:
Doesn’t appear to be caused by using root vs sudo as trying to clone repo as user and running through sudo doesn’t seem to work either. Still debugging. I will be bringing up a fresh EC2 instance and trying to setup.

Update 3:
Brought up two EC2 instances and did the setup as root or using sudo. Results the same - successfully setup.

My problems seem to be related to setting up on an existing instance.


#7

OK so what I think is happening here is that in some cases when Let’s Encrypt is setup on an existing server that may have some old Python configuration, the install is placing the packages for the virtual environment in

/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages

On new servers it’s being installed to:

/root/.local/share/letsencrypt/local/lib/python2.7/site-packages/

That being said, the underlying cause is that the Python path when running either versions does not include the lib64/dist-packages directory. On the existing server where things are getting installed to dist-packages I see the non lib64 dist packages folder as part of the path, but not the lib64 version.

On the FRESH server, the OpenSSL dependency is placed in lib64 site-packages (directory of command prompt is /root/.local/share/letsencrypt):
[root letsencrypt]# find ./ -type d | grep -i openssl
./lib64/python2.7/site-packages/OpenSSL

And here are the python path values:
[’/root/.local/share/letsencrypt/bin’
’/root/.local/share/letsencrypt/local/lib64/python2.7/site-packages’
’/root/.local/share/letsencrypt/local/lib/python2.7/site-packages’
’/root/.local/share/letsencrypt/lib64/python2.7’
’/root/.local/share/letsencrypt/lib/python2.7’
’/root/.local/share/letsencrypt/lib64/python2.7/site-packages’
’/root/.local/share/letsencrypt/lib/python2.7/site-packages’
’/root/.local/share/letsencrypt/lib64/python2.7/lib-dynload’
’/usr/lib64/python2.7’
’/usr/lib/python2.7’]

So OpenSSL is found.

On an EXISTING server, however, the OpenSSL dependency is placed in lib64 dist-packages (directory of command prompt is /root/.local/share/letsencrypt):
[root letsencrypt]# find ./ -type d | grep -i openssl
./lib64/python2.7/dist-packages/OpenSSL

However, the python paths:
[’/root/.local/share/letsencrypt/bin’
’/root/.local/share/letsencrypt/local/lib64/python2.7/site-packages’
’/root/.local/share/letsencrypt/local/lib/python2.7/site-packages’
’/root/.local/share/letsencrypt/lib64/python2.7’
’/root/.local/share/letsencrypt/lib/python2.7’
’/root/.local/share/letsencrypt/lib64/python2.7/site-packages’
’/root/.local/share/letsencrypt/lib/python2.7/site-packages’
’/root/.local/share/letsencrypt/lib64/python2.7/lib-dynload’
’/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages’
’/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages’
’/root/.local/share/letsencrypt/lib/python2.7/dist-packages’
’/usr/lib64/python2.7’
’/usr/lib/python2.7’]

do not contain lib64/python2.7/dist-packages so the module is not found.

Is there some way to force the installation to the correct directories and/or to fix the python path used to include lib64/python2.7/dist-packages?

This is the root of our issue on EC2.


./letsencrypt-auto certonly -d domainname gives error "ImportError: No module named interface"
#8

Possible similar issue, implying this isn’t specific to Let’s Encrypt:
https://forums.aws.amazon.com/thread.jspa?messageID=622623


#9

Issue resolution given here (similar problem):

Long story short, use pip to upgrade pip and virtualenv on AWS as the versions shipped via yum (python27-pip and python27-virtualenv) are out of date and have bugs.