Python Errors in Official Client 0.5 on FreeBSD

Help
1

I’m having issues with the latest client, and I’m not sure if it’s a client issue, if it’s a client issue on FreeBSD, a Python 2.7 issue, or whether I’ve done something else stupid to my server to cause the problem.

The client on my machine spouts errors, no matter what I’m trying to do. I discovered this when my weekly renew cron emailed me the results. It looked like this:

Traceback (most recent call last):
  File "/usr/local/bin/letsencrypt", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3141, in <module>
    @_call_aside
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3127, in _call_aside
    f(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3154, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 642, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 655, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 833, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (cryptography 1.0.2 (/usr/local/lib/python2.7/site-packages), Requirement.parse('cryptography>=1.3'), set(['PyOpenSSL']))

I get the same output whether I run “letsencrypt renew”, “letsencrypt --help”, or just “letsencrypt”. The whole client appears broken.

The error message made me think I had a broken python 2.7 install, so I completely reinstalled python and it’s dependencies (“portmaster -r python27”) but I’m still getting the same output. Of course, I’ve also tried reinstalling the client.

My certs were created with client v0.3 and I’ve also successfully run 0.4 and 0.4.2, but 0.5 appears broken for me. I’m running Python 2.7 on FreeBSD 10.2. I updated the client from 0.4.2 but didn’t use it until my weekly renew cron ran.

Nobody else seems to be having this issue, so I’m wondering if I’m missing something obvious. Any suggestions would be appreciated!

2

The last line tells it all: your version of the cryptography library is too old. But apparently, FreshPorts only has 1.0.2…

3

Bugger. I didn’t think I’d done anything too stupid. I did see the “version conflict” message but I thought it was talking about the python packages, hence my effort to rebuild python and everything it links to (including anything crypto).

Well, I guess I’m outta luck with the port of the official client for now. I’m going to have to figure out how to get a bash client to renew the certs I already have. So far, there are only two clients available in the ports tree.

EDIT: And I just checked, and I’m running the latest version of py-cryptography (1.0.2_4). Any chance of 0.5.2 allowing me to use the same library as 0.4.2? :kissing_heart:

4

Probably worth trying one of the bash clients from the alternate clients list

5

It’s actually a requirement of PyOpenSSL… Not Let’s Encrypt specifically. In October 2015, the requirement was only >=0.7, but on March 10, 2016 it was bumped to >=1.2.

I don’t know if setup.py is leading, but Let’s Encrypt 0.5.0 requires cryptography-0.7. Although the letsencrypt-auto script tries to install cryptography 1.2.3.

So no clue what’s actually required… :stuck_out_tongue: Perhaps you could downgrade PyOpenSSL to a version not requiring cryptography-1.3? (I.e., before March 10 2016.)

6

Not only two.

The acme.sh client is also working for BSD.

And much more smart and easy-to-use.

7

Ah, thanks for the tip, I'll try that :slight_smile:

Still, I'm surprised the Ports tree would update that one port but not the other - how useful is py-cryptography if PyOpenSSL won't talk to it?! :stuck_out_tongue_winking_eye:

8

Thanks Neil, but there are only two clients available in the ports tree :wink:

I try to avoid installing things outside of ports if I can help it. Linux distros and software tends to put things in places they shouldn’t go - there isn’t the clear delineation between system files, installed third party software, and user files like there is in the BSDs.

That said, if the other client in ports doesn’t suit me (and I can’t imagine changing clients will be pleasant regardless of which one I switch to), I’ll try yours. I didn’t realised you changed the name from le.sh!

I know I’m being prissy, but I want to simply update the certs I have, not create new certs and adjust all my conf files. Also, it’s really irksome to have the script install and run from a home directory! :anguished:

9

Hi @DarkSteve,

Installing to home dir is just for non-root users. acme.sh does’t require to be run as root.

And you can use --home parameter to specify a new home dir when installing, and all the future operations will automatically use the customized home dir.

And we even have a --certhome parameter when installing, in which you can specify a dir to save all the issued certs. By default, the certhome will be same as home.

10

Excellent :grin:

Your script just jumped to the top of the list of replacement clients!

11

Ok, problem solved. I simply reverted to an earlier version of security/py-openssl.

The latest version is py27-openssl-0.16.0, and I’m now running py27-openssl-0.15.1. Letsencrypt 0.5 is now working again perfectly.

First, I installed ports-mgmt/portdowngrade, then used it to revert security/py-openssl to revision r389892 (17 June 2015). Instantly everything worked again :slight_smile:

Sorry Neil, maybe next time! And after stressing for a few days, my certs still don’t need renewing yet anyway :stuck_out_tongue_closed_eyes:

EDIT: I have no idea why the port is “py-” but it installs “py27-”. That took me longer than it should have to notice. I was pulling my hair out going “THERE IS NO @#!*%#@! py27-openssl in the ports tree!!!”

12

Oh, for crying out loud. py-cryptography just updated to 1.3.1, making all my stress and questions and solution moot.

Argh! :rage:

13

Just tried latest FBSD letsencrypt and got the same error. The recent “upgrade” installed the same versions as reported above. Accordingly I tried installing py27-openssl-0.15.1 over py27-openssl-16.0.0 but still got the error.

The last error in the stack trace was:
…
pkg_resources.ContextualVersionConflict: (cryptography 1.0.2 (/usr/local/lib/python2.7/site-packages), Requirement.parse(‘cryptography>=1.3’), set([‘PyOpenSSL’]))

Digging further, it’s kind of confusing. Turns out using the pkg command to install py27-openssl-0.15.1 doesn’t actually replace py27-openssl-16.0.0, both are there. IOW letsencrypt isn’t affected at all. (Usually installing a particular version of a program will remove any existing versions.)

Using pkg delete py27-letsencrypt-0.5.0 and installing py27-letsencrypt-0.4.1 also installs py27-openssl-16.0.0 rather than the prior version. Not sure what’s going on, I’ll have to look into it some more.

Seems like pkg dependencies for letsencrypt have gotten kind of jumbled. Probably it will get straightened out soon and not an emergency for me, but I’m looking at other clients just in case.

Installing from ports presents another set of issues in constrained vps environment, so haven’t yet determined if that’s an option.

14

Oh, bummer. Sorry, I should have been more explicit with what I did.

I deinstalled py27-openssl-0.16.0 via ports before installing py27-openssl-0.15.1. Portdowngrade dropped the downgraded port in root's home directory, and I installed from there.

If I tried to delete py27-openssl-0.16.0 via pkg, it also wanted to remove everything that depended on it. Deinstalling via ports was a little more simple. However py-cryptography has since updated to 1.3.1, so my original problem dissolved anyway.

Yeah, I think they got out of sync for a few days, almost a week. I had similar issues when the letsencrypt client hit the ports tree in the beginning, when it still had "dev" as part of the port name. It loaded a huge number of py extensions, some of which conflicted with each other. But the problems went away once the port hit 0.1, and by 0.3 I was confident enough in it to start using it in "production".

The re-emergence of this issue was a surprise, and I started looking at other clients, too. Particularly NeilPang's acme.sh client, since it's one of the older and more mature clients (and based on bash and hard to mess up and go wrong!)

Once I successfully reverted to py27-openssl-0.15.1 all my issues went away, and then within hours of reverting py-cryptography updated (via ports) to be compatible with py27-openssl-0.16.0, making it all moot!

Good luck with that (seriously, not sarcastically!) I almost exclusively use ports to install and pkg to manage, and I kind of (wrongly) assume others do too. I also assumed ports are an intrinsically core part of the OS, I can't imagine it being unavailable.

I hope you get it sorted!

15

Talk about timing. Just to be sure, ran ‘pkg upgrade’ again, and py27-cryptography-1.3.1 was available! Installed it and ‘letsencrypt’ runs just fine. At least it doesn’t immediately error out. I’ll attempt to renew certs but anticipate it will work as expected.

Thanks for the hints, I may yet need them!

16

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