UnicodeDecodeError on CentOS6.7

Help
1

I've managed to get a working client install on one CentOS6.7 server, but cannot replicate it again (not even on the same server under new account). This leads me to think the problem is in the virtual environment rather than server environment. Is it safe to just copy an installation to another account or another server running same OS (ie to get this to my production account I would copy entire home dir)

I see similar problem described here.

And there was a recent OpenSSL update on CentOS, but openssl-1.0.1e-42.el6_7.4.x86_64 was installed on March 2, working lets encrypt installed on Mar 14.

As a new user I can neither attach log file nor past full log. This is what is at the very end:

File "/home/securemail/.local/share/letsencrypt/lib/python2.7/site-packages/pip/basecommand.py", line 169, in main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 36: ordinal not in range(128)

2

Here’s the full output as a link on my server

3

Focus on the first error and not the last one:

c/_cffi_backend.c:2:20: error: Python.h: No such file or directory

Try to install python development package (python-devel ?), delete the virtualenv and rerun letsencrypt-auto

4

Thank you. Right now both working and non-working machines have the same python-devel packages installed:

# yum list installed | grep python.*dev
python-devel.x86_64                  2.6.6-64.el6                       @base
python27-python-devel.x86_64         2.7.5-10.el6.centos.alt            @scl
python27-scldevel.x86_64             1.1-16.el6.centos.alt              @scl

I’ve done a fresh git clone and then:

rm -rf ~/.local/share/letsencrypt
scl enable python27 bash
./letsencrypt-auto --help

I have made progress to where I can consistently install the client on the one server where it first worked.

I also have made some progress on the second server where the client has never installed and probably tracked that down to wrong version of libffi. Error now I’m stuck at is

c/_cffi_backend.c:13:17: error: ffi.h: No such file or directory

Working install has:

libffi.x86_64                        3.0.5-3.2.el6                      @anaconda-CentOS-201508042137.x86_64/6.7
libffi-devel.x86_64                  3.0.5-3.2.el6                      @base

Broken install has:

libffi.x86_64                      3.0.10-1                            @SOGo
libffi-devel.x86_64                3.0.10-1                            @SOGo

So that’s on me to sort out. I don’t know if we can downgrade without breaking other things (this a mail server with the SOGo groupware that provides the Exchange ActiveSync features and there are some other options for providing that I am looking at).

Thanks also for pointing me back to the top of the error stack. I’ve beat on this for a couple days and was close on this once before. I now realize I had been inconsistent in invoking the right python, thinking that the ‘scl python27 bash’ command was a one-time step. And now I understand why I had to logout twice :slight_smile:

P.S. Paradox here is that I am installing Let’s Encrypt in part because Outlook doesn’t like self-signed certificates, and I haven’t been able to properly test out SOGo to be sure it is what we need. For that purpose I can probably downgrade, get the certs and then restore.

5

you may have a try on my client : https://github.com/Neilpang/le
pure bash

6

Thank you. I made it work once (the story of my life right now). Except I forgot the importance of adding the autodiscover A record to the certificate. All subsequent attempts to create new certs fail. Clearly the problem is on my end. I’m about to nuke this install and start from scratch. I can’t even clone any more, and the error is also local SSL for some reason. Fresh user checkout and no love.

$ git clone https://github.com/Neilpang/le.git
Initialized empty Git repository in /home/securemail/le/.git/
error:  while accessing https://github.com/Neilpang/le.git/info/refs

fatal: HTTP request failed

I can make that work by doing

git config --global http.sslverify false

Which probably isn’t a good idea.

And on my test box, where I don’t need it, git clone works fine.

Edit: yeah, don’t mess with /etc/pki/tls/certs/ca-bundle.crt. It screws up yum too.

7

Glad to see it works for you.

I just added a new way to install online, no need to use git anymore:

curl https://raw.githubusercontent.com/Neilpang/le/master/le.sh | INSTALLONLINE=1  bash

You must have curl and tar installed.

8

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