CHBMB Posted August 11, 2018 Share Posted August 11, 2018 40 minutes ago, ZipsServer said: I couldn't find a README It's linked on the very first post. On both dockerhub and github. Quote Link to comment
RockDawg Posted August 11, 2018 Share Posted August 11, 2018 9 hours ago, CHBMB said: That's interesting, I use Namecheap and up until this week used their nameservers and never had an issue. Switched to cloudflare now, just so I can get a wildcard cert, nothing to do with performance. Yeah. I don't really know what the deal is. All I know is it has worked without any issue since making the change. I'm just glad to have it sorted out. It was really driving me nuts. Quote Link to comment
ZipsServer Posted August 12, 2018 Share Posted August 12, 2018 On 8/11/2018 at 3:22 PM, CHBMB said: It's linked on the very first post. On both dockerhub and github. Thanks for the reply. Yes I read the main README, but it do not seem to specify how to use a DNS provider other than the ones listed. It seems that I am missing something obvious or that it is not possible. Quote Link to comment
CHBMB Posted August 13, 2018 Share Posted August 13, 2018 Thanks for the reply. Yes I read the main README, but it do not seem to specify how to use a DNS provider other than the ones listed. It seems that I am missing something obvious or that it is not possible. Namecheaps API isn't compatible with DNS Auth, I changed my DNS provider to Cloudflare and used their DNS plugin.Sent from my Mi A1 using Tapatalk Quote Link to comment
chiaramontef Posted August 13, 2018 Share Posted August 13, 2018 Can anyone help with this? I updated letsencrypt today and now nothing is working. No other changes have been made. It's as if everything is trying to go over 8443 (which is what my UNRAID server is set to since there was a conflict between letsencrypt 443 and UNRAID 443. This is the error I'm getting: 2048 bit DH parameters presentSUBDOMAINS entered, processingSUBDOMAINS entered, processingSub-domains processed are: -d nextcloud.xxx.com -d office.xxx.com -d apps.xxx.comE-mail address entered: [email protected]http validation is selectedGenerating new certificateSaving debug log to /var/log/letsencrypt/letsencrypt.logPlugins selected: Authenticator standalone, Installer NoneObtaining a new certificateSaving debug log to /var/log/letsencrypt/letsencrypt.logPlugins selected: Authenticator standalone, Installer NoneObtaining a new certificatePerforming the following challenges:http-01 challenge for apps.xxx.comhttp-01 challenge for xxx.comhttp-01 challenge for nextcloud.xxx.comhttp-01 challenge for office.xxx.comWaiting for verification...Cleaning up challengesFailed authorization procedure. apps.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, office.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, nextcloud.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443IMPORTANT NOTES:- The following errors were reported by the server:Domain: apps.xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Domain: office.xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Domain: nextcloud.xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Domain:xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443 Quote Link to comment
CHBMB Posted August 13, 2018 Share Posted August 13, 2018 Can anyone help with this? I updated letsencrypt today and now nothing is working. No other changes have been made. It's as if everything is trying to go over 8443 (which is what my UNRAID server is set to since there was a conflict between letsencrypt 443 and UNRAID 443. This is the error I'm getting: 2048 bit DH parameters presentSUBDOMAINS entered, processingSUBDOMAINS entered, processingSub-domains processed are: -d nextcloud.xxx.com -d office.xxx.com -d apps.xxx.comE-mail address entered: [email protected]http validation is selectedGenerating new certificateSaving debug log to /var/log/letsencrypt/letsencrypt.logPlugins selected: Authenticator standalone, Installer NoneObtaining a new certificateSaving debug log to /var/log/letsencrypt/letsencrypt.logPlugins selected: Authenticator standalone, Installer NoneObtaining a new certificatePerforming the following challenges:http-01 challenge for apps.xxx.comhttp-01 challenge for xxx.comhttp-01 challenge for nextcloud.xxx.comhttp-01 challenge for office.xxx.comWaiting for verification...Cleaning up challengesFailed authorization procedure. apps.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, office.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, nextcloud.xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443, xxx.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://xxx.unraid.net:8443/.well-known/acme-challenge/xxx: Invalid port in redirect target. Only ports 80 and 443 are supported, not 8443IMPORTANT NOTES:- The following errors were reported by the server:Domain: apps.xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Domain: office.xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Domain: nextcloud.xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Domain:xxx.comType: connectionDetail: Fetchinghttps://xxx.unraid.net:8443/.well-known/acme-challenge/xxx:Invalid port in redirect target. Only ports 80 and 443 aresupported, not 8443Post your docker run command and screenshots of your port forwarding.Sent from my Mi A1 using Tapatalk Quote Link to comment
chiaramontef Posted August 13, 2018 Share Posted August 13, 2018 Originally, I only had 443 and 32400, but I've since added 80 & 81 to troubleshoot the issue. No luck. Here are the screenshots you requested. Thanks for taking a look. Quote Link to comment
saarg Posted August 13, 2018 Share Posted August 13, 2018 51 minutes ago, chiaramontef said: Originally, I only had 443 and 32400, but I've since added 80 & 81 to troubleshoot the issue. No luck. Here are the screenshots you requested. Thanks for taking a look. Your port forwarding for port 80 is wrong. You should forward 80 from outside to 81. That is probably why it's answering with the unraid.net adress. Quote Link to comment
ijuarez Posted August 13, 2018 Share Posted August 13, 2018 52 minutes ago, chiaramontef said: Originally, I only had 443 and 32400, but I've since added 80 & 81 to troubleshoot the issue. No luck. Here are the screenshots you requested. Thanks for taking a look. So you have port 81 (external internet facing) port forwarded to port 81 on your unraid and inside the container is port 80, is that correct? 1 minute ago, saarg said: Your port forwarding for port 80 is wrong. You should forward 80 from outside to 81. That is probably why it's answering with the unraid.net adress. saarg beat me to it. 1 Quote Link to comment
chiaramontef Posted August 13, 2018 Share Posted August 13, 2018 Great catch. That was a facepalm moment, thanks for the help! Quote Link to comment
gshlomi Posted August 14, 2018 Share Posted August 14, 2018 Hi folks. Had to start over (too much messing around with the conf files and default)... So I've downloaded a new copy of LetsEncrypt (called it letsencrypt-temp, saved to an appdata folder by the same name) to create a new configuration, and noticed the sample files added for subdomains, which is a very elegant and helpful solution to what I need. The problem I'm having is with: Quote These confs also assume that the letsencrypt container can reach other containers via their dns hostnames (defaults to container name) resolved via docker's internal dns All of my containers are defined with capitalization of their name (OCD anyone? ?) and I really want to keep it that way. I've tried for instance to change the "transmission.subdomain.conf" file to point $upstream_transmission to "Transmission" instead of "transmission", but it doesn't work. I get the error: Quote transmission could not be resolved (3: Host not found), client: 192.168.1.1, server: tr.*, request: "GET /favicon.ico HTTP/1.1", host: "tr.my.domain", referrer: "https://tr.my.domain/transmission/web/" in the error log. Any help would be appreciated. Quote Link to comment
CHBMB Posted August 14, 2018 Share Posted August 14, 2018 You also need to create a custom docker network so the DNS name resolution works. Quote Link to comment
gshlomi Posted August 14, 2018 Share Posted August 14, 2018 (edited) Thanks for the quick reply. I did create the custom network (as mentioned in _readme) and doing a DNS resolution inside the letsencrypt container returns: root@2610736c55ba:/$ nslookup Transmission 127.0.0.11 Server: 127.0.0.11 Address 1: 127.0.0.11 Name: Transmission Address 1: 172.18.0.3 Transmission.docknet root@2610736c55ba:/$ nslookup transmission 127.0.0.11 Server: 127.0.0.11 Address 1: 127.0.0.11 nslookup: can't resolve 'transmission': Name does not resolve Edited August 14, 2018 by gshlomi Quote Link to comment
MyKroFt Posted August 15, 2018 Share Posted August 15, 2018 (edited) ok, please be kind, my brain is moosh trying to go thru 92 pages, and search didnt help either am trying to setup subdomain medusa, there is no sample avail so here is my try, but I am getting bad gateway, I know its something simple., but I Just cant see it atm # make sure that your dns has a cname set for medusa # to enable password access, uncomment the two auth_basic lines server { listen 443 ssl; server_name medusa.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { # auth_basic "Restricted"; # auth_basic_user_file /config/nginx/.htpasswd; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_medusa binhex-medusa; proxy_pass http://$upstream_medusa:8082; } } yes, i am using binhex still - but am planing on moving over soon.... Error log shows: 2018/08/14 20:28:11 [error] 386#386: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: medusa.*, request: "GET /favicon.ico HTTP/1.1", upstream: "http://172.18.0.4:8082/favicon.ico", host: "medusa.townecrier.extensionhidden", referrer: "https://medusa.townecrier.extensionhidden/" Please help me, thanks Myk Edited August 15, 2018 by MyKroFt Quote Link to comment
Gog Posted August 15, 2018 Share Posted August 15, 2018 ok, please be kind, my brain is moosh trying to go thru 92 pages, and search didnt help either am trying to setup subdomain medusa, there is no sample avail so here is my try, but I am getting bad gateway, I know its something simple., but I Just cant see it atm # make sure that your dns has a cname set for medusa# to enable password access, uncomment the two auth_basic linesserver { listen 443 ssl; server_name medusa.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / {# auth_basic "Restricted";# auth_basic_user_file /config/nginx/.htpasswd; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_medusa binhex-medusa; proxy_pass http://$upstream_medusa:8082; }} yes, i am using binhex still - but am planing on moving over soon.... Error log shows: 2018/08/14 20:28:11 [error] 386#386: *6 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: medusa.*, request: "GET /favicon.ico HTTP/1.1", upstream: "http://172.18.0.4:8082/favicon.ico", host: "medusa.townecrier.extensionhidden", referrer: "https://medusa.townecrier.extensionhidden/" Please help me, thanks Myk You added it to the subdomain variable and registered a cname with your domain provider? You also have the custom network interface? Sent from my SM-G930W8 using Tapatalk Quote Link to comment
MyKroFt Posted August 15, 2018 Share Posted August 15, 2018 14 minutes ago, Gog said: You added it to the subdomain variable and registered a cname with your domain provider? You also have the custom network interface? Sent from my SM-G930W8 using Tapatalk yes I have my own domain name, nextcloud and others are working just fine. I: can access medusa via local ip, but when I try https://medusa.townecrier.domain I get bad gateway Quote Link to comment
Gog Posted August 15, 2018 Share Posted August 15, 2018 2 hours ago, MyKroFt said: yes I have my own domain name, nextcloud and others are working just fine. I: can access medusa via local ip, but when I try https://medusa.townecrier.domain I get bad gateway I'm far from a nginx expert but everything I check seems OK. Found @CHBMB's config problems on github but the only directive that seems to be needed, outside of the standard proxy.conf, is proxy_pass. Sorry... Quote Link to comment
MyKroFt Posted August 15, 2018 Share Posted August 15, 2018 9 minutes ago, Gog said: I'm far from a nginx expert but everything I check seems OK. Found @CHBMB's config problems on github but the only directive that seems to be needed, outside of the standard proxy.conf, is proxy_pass. Sorry... Ya I found that as well, but am still at a loss of why I: am getting Bad Gateway, hopefully someone who know more than I do, will see this and can push me in the right direction. Thanks Quote Link to comment
aptalca Posted August 15, 2018 Share Posted August 15, 2018 1 hour ago, MyKroFt said: Ya I found that as well, but am still at a loss of why I: am getting Bad Gateway, hopefully someone who know more than I do, will see this and can push me in the right direction. Thanks Binhex-medusa's internal port is 8081 1 Quote Link to comment
MyKroFt Posted August 15, 2018 Share Posted August 15, 2018 1 hour ago, aptalca said: Binhex-medusa's internal port is 8081 Thank you very much, that is what it was, I was using the external port instead of internal. I am now understanding this much more. Appreciated! Quote Link to comment
mikeyw Posted August 16, 2018 Share Posted August 16, 2018 I just got letsencrypt working again (long story) but now I have a question: how can I reverse proxy into a container on a different unraid server? I am running multiple servers and now need to use the letsencrypt docker on one of them and reverse proxy into the other server from the outside it kinda looks like this in my head: couchpotato >>> internet >> letsencrypt >>>>> tower 1 (this works fine) | | unifi controller >>> internet >>> >>>>> tower 2 (this one not so good) So I think that I have to somehow connect the two different docker networks( on tower1 and tower2) together so that the correct stuff gets sent to the right place. Tried a few things, but thought I should ask before I make a really big mess here. Took a look at the "docker network" command but couldn't make heads or tails of it I think because I don' t know why?. just need a little direction. ThanX Michael Quote Link to comment
aptalca Posted August 16, 2018 Share Posted August 16, 2018 7 hours ago, mikeyw said: I just got letsencrypt working again (long story) but now I have a question: how can I reverse proxy into a container on a different unraid server? I am running multiple servers and now need to use the letsencrypt docker on one of them and reverse proxy into the other server from the outside it kinda looks like this in my head: couchpotato >>> internet >> letsencrypt >>>>> tower 1 (this works fine) | | unifi controller >>> internet >>> >>>>> tower 2 (this one not so good) So I think that I have to somehow connect the two different docker networks( on tower1 and tower2) together so that the correct stuff gets sent to the right place. Tried a few things, but thought I should ask before I make a really big mess here. Took a look at the "docker network" command but couldn't make heads or tails of it I think because I don' t know why?. just need a little direction. ThanX Michael If the containers are on separate servers, then simply use the host ip and port to reverse proxy Quote Link to comment
Kaizac Posted August 18, 2018 Share Posted August 18, 2018 I'm trying to use the Cloudflare DNS + HTTP proxy which I can't seem to get working as I want. What I have is a Let's Encrypt set up, in Cloudflare I created CNAME's which redirect to my DuckDNS domain. When I put off the proxy mode in Cloudflare my personal domain and subdomains resolve to the right dockers. However, when I put on the HTTP proxy in Cloudflare, the (sub)domain can't resolve anymore. Should what I'm trying to do work, or is it impossible? I'd prefer not to put my WAN IP out in the open, so the HTTP proxy would be very useful. Quote Link to comment
ijuarez Posted August 19, 2018 Share Posted August 19, 2018 I'm trying to use the Cloudflare DNS + HTTP proxy which I can't seem to get working as I want. What I have is a Let's Encrypt set up, in Cloudflare I created CNAME's which redirect to my DuckDNS domain. When I put off the proxy mode in Cloudflare my personal domain and subdomains resolve to the right dockers. However, when I put on the HTTP proxy in Cloudflare, the (sub)domain can't resolve anymore. Should what I'm trying to do work, or is it impossible? I'd prefer not to put my WAN IP out in the open, so the HTTP proxy would be very useful.If your ISP is not blocking port 80 why are you trying to use DNS? Sent from my BND-L34 using Tapatalk Quote Link to comment
Kaizac Posted August 19, 2018 Share Posted August 19, 2018 4 hours ago, ijuarez said: If your ISP is not blocking port 80 why are you trying to use DNS? Sent from my BND-L34 using Tapatalk I might have not been clear. I have a personal domain (not the duckdns). So that domain needs DNS settings for the CNAME's, which I like Cloudlfare's interface for. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.