Solved: Debian Jessie letsencrypt-auto fails with cryptic error code


#1

Hi,

first I’d like to say a big “thank you” for your service and efforts to automate the process!
It is a great step forward.

After a successful first run about a month ago which was rather easy and flawless I now tried to elaborate on the possibilities to automate the certificate renewal.
But when I start letsencrypt-auto now all I get is the following cryptic error message:
Updating letsencrypt and virtual environment dependencies......Command "/root/.local/share/letsencrypt/bin/python2.7 -c "import setuptools, tokenize;__file__='/tmp/pip-build-7TC7hy/cryptography/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-vFss2L-record/install-record.txt --single-version-externally-managed --compile --install-headers /root/.local/share/letsencrypt/include/site/python2.7/cryptography" failed with error code 1 in /tmp/pip-build-7TC7hy/cryptography
The base system is an out-of-the-box Debian Jessie installation with latest updates.
I’ve downloaded the latest letsencrypt client version from git -> same result
I’ve moved the /etc/letsencrypt folder to make it appear a fresh start -> same result

Even the following command line causes the same error message:
./letsencrypt-auto --help all

I seems to be something generic so most probably easy - but I have no clue where to start.
Any hints how to proceed are very welcome.

best regards,
Klaus


Python Cryptography Error Message
#2

This looks like a build problem installing the cryptography library. Are you able to run pip install cryptography? Is your system relatively low-memory? Some people have mentioned trouble on low-memory systems.


#3

Hi jsha,

thanks for the rather fast reply.
it’s a virtul server with 2GB of “physical” memory available and only a few things running on it. (apache, dovecot and exim4 basically). No, it is unlikely to be a memory issue in my case.

But… I’ve found the issue… an unresolved dependency…
Since this smelt like something generic I simply applied the following command again (which I found in another thread):
sudo apt-get install build-essential libssl-dev libffi-dev python-dev
and was surprised to see a number of packages being installed.
I executed the client once more and TATAA the fault disappeared.
Not sure what went wrong between the first execution and the second one month later.

I remember that letsencrypt-auto was executing apt-get on its own at first execution - is something missing in this list, may be?

Best regards,
Klaus