"Temporary failure in name resolution" (?)

derroman commented 6 years ago

Hi! I really love this little cool helper - when I run my config with "local" everything runs fine, but as soon as I switch to "staging" and therefore start talking to let's encrypt, if fails as follows:

https-portal_1  | [fix-attrs.d] 00-runscripts: exited 0.
https-portal_1  | [fix-attrs.d] done.
https-portal_1  | [cont-init.d] executing container initialization scripts...
https-portal_1  | [cont-init.d] 00-welcome: executing... 
https-portal_1  | 
https-portal_1  | ========================================
https-portal_1  | HTTPS-PORTAL v1.2.1
https-portal_1  | ========================================
https-portal_1  | 
https-portal_1  | [cont-init.d] 00-welcome: exited 0.
https-portal_1  | [cont-init.d] 10-setup: executing... 
https-portal_1  | 2018/01/14 15:13:48 [notice] 136#136: signal process started
https-portal_1  | Signing certificates from https://acme-staging.api.letsencrypt.org ...
https-portal_1  | Parsing account key...
https-portal_1  | Parsing CSR...
https-portal_1  | Registering account...
https-portal_1  | Traceback (most recent call last):
https-portal_1  |   File "/bin/acme_tiny", line 198, in <module>
https-portal_1  |     main(sys.argv[1:])
https-portal_1  |   File "/bin/acme_tiny", line 194, in main
https-portal_1  |     signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)
https-portal_1  |   File "/bin/acme_tiny", line 85, in get_crt
https-portal_1  |     "agreement": json.loads(urlopen(CA + "/directory").read().decode('utf8'))['meta']['terms-of-service'],
https-portal_1  |   File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
https-portal_1  |     return opener.open(url, data, timeout)
https-portal_1  |   File "/usr/lib/python2.7/urllib2.py", line 429, in open
https-portal_1  |     response = self._open(req, data)
https-portal_1  |   File "/usr/lib/python2.7/urllib2.py", line 447, in _open
https-portal_1  |     '_open', req)
https-portal_1  |   File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
https-portal_1  |     result = func(*args)
https-portal_1  |   File "/usr/lib/python2.7/urllib2.py", line 1241, in https_open
https-portal_1  |     context=self._context)
https-portal_1  |   File "/usr/lib/python2.7/urllib2.py", line 1198, in do_open
https-portal_1  |     raise URLError(err)
https-portal_1  | urllib2.URLError: <urlopen error [Errno -3] Temporary failure in name resolution>
https-portal_1  | ================================================================================
https-portal_1  | Failed to sign sub.mydomain.com, is DNS set up properly?
https-portal_1  | ================================================================================
https-portal_1  | Failed to obtain certs for sub.mydomain.com
https-portal_1  | 2018/01/14 15:14:08 [notice] 146#146: signal process started
https-portal_1  | [cont-init.d] 10-setup: exited 0.
https-portal_1  | [cont-init.d] 20-set-docker-gen-status: executing... 
https-portal_1  | [cont-init.d] 20-set-docker-gen-status: exited 0.
https-portal_1  | [cont-init.d] done.
https-portal_1  | [services.d] starting services
https-portal_1  | [services.d] done.
https-portal_1  | Starting crond ...

Here's the part of my docker-compose config:

https-portal:
  image: steveltn/https-portal:latest
  ports:
    - "80:80"
    - "443:443"
  links:
    - otherService
  restart: always
  environment:
    DOMAINS: 'sub.mydomain.com -> http://otherService:8090'
    STAGE: 'staging'
    FORCE_RENEW: 'true'

Am I missing something? Any help is highly appreciated. Thanks!

SteveLTN commented 6 years ago

Hi, this issue is most common when your DNS isn't set up correctly or it is not yet fully propagated. Does nslookup sub.mydomain.com return the correct IP address?

derroman commented 6 years ago

Yes, it does. The IP address returned is correct.

(BTW: thanks for the ultra fast response!)

SteveLTN commented 6 years ago

What about on server itself? This is a failure on a pre-flight check, where the container tries to access http://sub.mydomain.com:80. When it fails, it means either the DNS is not propagated, or the port 80 is blocked somehow. (Local mode doesn't do the check).

On Sun, Jan 14, 2018 at 4:26 PM, roman notifications@github.com wrote:

Yes, it does. The IP address returned is correct.

(BTW: thanks for the ultra fast response!)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SteveLTN/https-portal/issues/114#issuecomment-357519191, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfAZ2tR2LLS1HJaMe4cybsWaYpe41Jwks5tKhyxgaJpZM4RdoLr .

derroman commented 6 years ago

mh... there is an automated redirect to https (port 443) when I hit port 80 (http)

SteveLTN commented 6 years ago

That sounds normal. But somehow port 80 of the given domain is not accessible from within the container. If you just set up the DNS, wait for a while for it to fully propagate. I'm afraid I can't help you with more than that.

On Sun, Jan 14, 2018 at 4:36 PM, roman notifications@github.com wrote:

mh... there is an automated redirect to https (port 443) when I hit port 80 (http)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SteveLTN/https-portal/issues/114#issuecomment-357519927, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfAZ6ViUiDX6KJHbad3m7oAVH4KEjIzks5tKh8ZgaJpZM4RdoLr .

derroman commented 6 years ago

Okay, I've used the same config locally, created a subdomain to my local computer (opening ports and stuff in my local router, etc) --- it worked out like a charm. Registering works.

But unfortunately I have absolutely no idea, why the same docker-compose config does not work on this specific server.

I will investigate a little bit more testing, and will report if I find the error.

derroman commented 6 years ago

I've found the issue! The reason is my firewall configuration:

I've created the following json file (couple of months ago), to prevent docker from bypassing any UFW firewall rules.

/etc/docker/daemon.json

{
    "iptables": false
}

Together with UFW this worked out fine (Source: https://svenv.nl/unixandlinux/dockerufw/). UFW enables ports 80 and 443 (both TCP) Everything was okay, until I wanted to start using https-portal.

What does not work:

UFW enabled + daemon.json + https-portal ==> fail
UFW disabled + daemon.json + https-portal ==> fail

What does work:

UFW disabled + no daemon.json + https-portal ==> success
UFW enabled + no daemon.json + https-portal ==> success

But without the config json, preventing docker from bypassing UWF rules, it seems not correct.

derroman commented 6 years ago

okay. So, we can close this for now: I've followed the instructions by svenv.nl again and now everything works fine. Thanks.

SteveLTN commented 6 years ago

Glad you solved this!

On Sun, Jan 14, 2018 at 8:36 PM, roman notifications@github.com wrote:

okay. So, we can close this for now: I've followed the instructions by svenv.nl again and now everything works fine. Thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SteveLTN/https-portal/issues/114#issuecomment-357535824, or mute the thread https://github.com/notifications/unsubscribe-auth/AAfAZ_U9_Ru1RHrUAtrozj5va8CwesiJks5tKlcggaJpZM4RdoLr .

SteveLTN / https-portal

"Temporary failure in name resolution" (?) #114