Leonard's picture

Hi, I am having this error while trying to get certificate, appreciate if you can help, thanks.

Traceback (most recent call last):

File "/usr/bin/confconsole", line 600, in loop new)dialog = method()

File "/usr/lib/confconsole/plugin.py", line 87, in run ret =self.module.run()

file "/usr/lib/confconsole/plugin/d/lets_encrypt/get_certificate.py", line 83, in run

except ConnectionError:

NameError: global name 'ConnectionError' is not defined.


Jeremy Davis's picture

That is an issue I have come across before. Could you please confirm which TurnKey version this is (if you're not sure run 'turnkey-version') and where/how you are running it?

Judging from what you've posted, I'm guessing it's hit some sort of connection error, which is triggering a secondary error that was not anticipated or accounted for. So understanding how your server is set up would assist with understanding the root of the problem.

It's also worth noting that I'm currently working on a major change to the Git Lab appliance (specifically, the way that we install GitLab). If you're interested in that, you can read more in this thread. Unfortunately, I've been dragged away from that by other stuff, but I hope to get back to it really soon.

Jeremy Davis's picture

Can you please also post the log output. That might give me some insight into what might be going wrong. The log file should be /var/log/confconsole/letsencrypt.log.

Jeremy Davis's picture

FWIW, I tested our Confconsole Let's Encrypt plugin with a v15.1 LAMP server today and it worked fine. I wonder if the issue (as reported by Leonard & Helmut) are specifically related to the Nginx web server? That certainly seems to be the case as both GitLab and Nginx both use the Nginx web server (rather than Apache - as per my tests today).

I'll try to find time to spin up a Nginx server soon to test this possibility.

Jeremy Davis's picture

I could be wrong, but I'm pretty sure your issue is unrelated. I say that mostly because it appears you are using Certbot. TurnKey implements Let's Encrypt certificates via an alternate path (we use the Dehydrated ACME client rather than Certbot).

Although I guess there is a possibility that there is a common cause? It seems likely though if that were the case, it would be related to either changes in the supported protocols (and the client is no longer compatible and needs updating) or some sort of issue on the remote end. The fact that it worked OK for me today (with Apache) suggests that if it were the latter, it was either an intermittent issue, or has been resolved.

Add new comment