live4soccer7

One thing to note, I did change the ports back to 443. I wanted to change back to 444 or something different, however when I did this by changing it in the nextcloud docker container (444), the nextcloud config.php, and the nextcloud.subdomain.conf, I was presented with a 502 bad gateway. Is there another file that would need adjusted that I'm simply not seeing?

I got it! It just hit me. It seemed like the subdomain.conf was not getting read, so I though well maybe the subfolder inclusion in the letsencrypt default conf was actually over-riding or taking priority/preference over the subdomain.conf inclusion. It came with both uncommented. I commented out the subfolder and voila. # enable subfolder method reverse proxy confs #include /config/nginx/proxy-confs/*.subfolder.conf; Again, this is in: letsencrypt/nginx/site-confs/default I suppose it is possible that I uncommented this somehow without realizing it, but I'm pretty sure it came with both uncommented.

I just changed the container port to 443, adjusted nextcloud.subdomain.conf to 443 and same with nextcloud's config.php. The result was the same. It is simply loading the letsencrypt index.html, so nexcloud's proxy is not getting passed. In the readme within proxy-confs for letsencrypt, the following lines standout to me. Is there really nothing to do within the default site config? ### Configure your default site config Make sure that your default site config contains the following lines in the appropriate spots as seen in the default version: 1) For subfolder methods: `include /config/nginx/proxy-confs/*.subfolder.conf;` 2) For subdomain methods: `include /config/nginx/proxy-confs/*.subdomain.conf;`

Are you referring to the container port? I have changed the port that the nexcloud container uses to 444 (why my subdomain.conf and config.php reflect this). You're saying to leave it at 443 and then adjust the subdomain.conf and config.php back to 443 for the container port? I still don't think this would be the issue because I tried setup the subdomain for sonarr with lets encrypt as well and my results are the exact same as with nextcloud. Yes, I have created a custom network that nextcloud and letsencrypt are on. I really appreciate everyone's time on this. I have been pulling my hair out over this for the last week and a half.

It is commented out, so essentially no change. You can see where it is commented out. Yes, I restarted everything. Otherwise everything is 100% stock in this file. I commented out my addition, so it has no effect.

Thank you very much. I have definitely expended many many many hours getting this setup, so it isn't a lack of effort. I am no expert either. I think that something has changed in the latest versions released by LSIO as I'm seeing my stock files included are just a little different than others' files on the thread. Hopefully, with your configs I may be able to piece something together.

Are you referring to the router's WAN IP that would be provided in a DDNS service such as duckdns? If so, that is correct. If it weren't then it wouldn't load back to the server from an external source and load the index.html page that is shown. I'm confident that is setup properly. I'm thinking that it would be something in the default.conf file within let's encrypt. I am attaching it now. ## Version 2020/03/05 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default # redirect all traffic to https server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 https://$host$request_uri; } # main server block server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; root /config/www; index index.html index.htm index.php; server_name _; # enable subfolder method reverse proxy confs include /config/nginx/proxy-confs/*.subfolder.conf; # enable subdomain method reverse proxy confs #include /config/nginx/proxy-confs/*.subdomain.conf; # all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; # enable for ldap auth #include /config/nginx/ldap.conf; client_max_body_size 0; location / { try_files $uri $uri/ /index.html /index.php?$args =404; } location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } # sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp" # notice this is within the same server block as the base # don't forget to generate the .htpasswd file as described on docker hub # location ^~ /cp { # auth_basic "Restricted"; # auth_basic_user_file /config/nginx/.htpasswd; # include /config/nginx/proxy.conf; # proxy_pass http://192.168.1.50:5050/cp; # } } # sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above # notice this is a new server block, you need a new server block for each subdomain #server { # listen 443 ssl http2; # listen [::]:443 ssl http2; # # root /config/www; # index index.html index.htm index.php; # # server_name cp.*; # # 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; # proxy_pass http://192.168.1.50:5050; # } #} # sample reverse proxy config for "heimdall" via subdomain, with ldap authentication # ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info # notice this is a new server block, you need a new server block for each subdomain #server { # listen 443 ssl http2; # listen [::]:443 ssl http2; # # root /config/www; # index index.html index.htm index.php; # # server_name heimdall.*; # # include /config/nginx/ssl.conf; # # include /config/nginx/ldap.conf; # # client_max_body_size 0; # # location / { # # the next two lines will enable ldap auth along with the included ldap.conf in the server block # auth_request /auth; # error_page 401 =200 /login; # # include /config/nginx/proxy.conf; # resolver 127.0.0.11 valid=30s; # set $upstream_app heimdall; # set $upstream_port 443; # set $upstream_proto https; # proxy_pass $upstream_proto://$upstream_app:$upstream_port; # } #} # enable subdomain method reverse proxy confs include /config/nginx/proxy-confs/*.subdomain.conf; # enable proxy cache for auth proxy_cache_path cache/ keys_zone=auth_cache:10m; This is the part that is the most interesting and seems like the culprit at this point. # enable subdomain method reverse proxy confs include /config/nginx/proxy-confs/*.subdomain.conf; as you can see, I have added it in toward the beginning of this file, but it creates a can not connect to server error when I do this (typical message seen within a browser).

In my opinion it seems that the subdomain.conf isn't even getting read yet by letsencrypt. It it were and the subdomain.conf wasn't setup properly then I would think there simply would be a gateway error and not the default letsencyrpt index.html page. It simply seems that letsencrypt is not being told to read the subdomain.conf and therefore not pointing to the container location where that container's file would then be served from by the webserver.

Sorry, I was obscuring my info. The subdomain is my correct subdomain in that location

Here is the nextcloud config.php <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'instanceid', 'passwordsalt' => 'passalt', 'secret' => 'mysecret key', 'trusted_domains' => array ( 0 => 'nextcloud ip:port', 1 => 'mysub.duckdns.org', ), 'dbtype' => 'mysql', 'version' => '18.0.4.2', 'dbname' => 'dbname', 'dbhost' => 'mariadb ip:port', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'dbuser', 'dbpassword' => 'mypass', 'installed' => true, 'trusted_proxies' => 'letsencrypt', 'overwrite.cli.url' => 'https://mysub.duckdns.org', 'overwritehost' => 'mysub.duckdns.org', 'overwriteprotocol' => 'https', );

Here is the nextcloud.subdomain.conf (I have removed the .sample) server { listen 443 ssl; listen [::]:443 ssl; server_name subdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app nextcloud; set $upstream_port 444; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_max_temp_file_size 2048m; } }

You can see the screenshot here. It is the same when I go to the letsencrytp UI from the docker page and when I visit the subdomain I have setup from outside the network.

I'm pretty sure my issue is a setting in let's encrypt that is not passing along the necessary place to look to serve the files for nextcloud since it is serving the default let's encrypt index.html file. I have attempted to setup sonarr as well and it resulted in the same response. I have noticed that in the Let's Encrypt Subdomain conf files are different than what is in spaceinvader's videos and even what people have posted in this thread. It must be an update to the let's encrypt container that's fairly new??? You can see the upstream in most people's files goes at follows: $set upstream_nextcloud nextcloud; You can see how my default nextcloud.subdomain.conf file looks. server { listen 443 ssl; listen [::]:443 ssl; server_name subdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app nextcloud; set $upstream_port 444; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_max_temp_file_size 2048m; } } Edit: I have confirmed that I indeed have both the nextcloud and letsencrypt LSIO versions installed. hmm...... any ideas? I'm still convinced that the nextcloud.subdomain.conf still isn't being utilized by let's encrypt or I would at least get an error and not the default index.html page when visiting the subdomain via the web. That leads me to believe it must be something in the default site-conf for let's encrypt. ## Version 2020/03/05 - Changelog: https://github.com/linuxserver/docker-letsencrypt/commits/master/root/defaults/default # redirect all traffic to https server { listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 https://$host$request_uri; } # main server block server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; root /config/www; index index.html index.htm index.php; server_name _; # enable subfolder method reverse proxy confs include /config/nginx/proxy-confs/*.subfolder.conf; # enable subdomain method reverse proxy confs #include /config/nginx/proxy-confs/*.subdomain.conf; # all ssl related config moved to ssl.conf include /config/nginx/ssl.conf; # enable for ldap auth #include /config/nginx/ldap.conf; client_max_body_size 0; location / { try_files $uri $uri/ /index.html /index.php?$args =404; } location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } # sample reverse proxy config for password protected couchpotato running at IP 192.168.1.50 port 5050 with base url "cp" # notice this is within the same server block as the base # don't forget to generate the .htpasswd file as described on docker hub # location ^~ /cp { # auth_basic "Restricted"; # auth_basic_user_file /config/nginx/.htpasswd; # include /config/nginx/proxy.conf; # proxy_pass http://192.168.1.50:5050/cp; # } } # sample reverse proxy config without url base, but as a subdomain "cp", ip and port same as above # notice this is a new server block, you need a new server block for each subdomain #server { # listen 443 ssl http2; # listen [::]:443 ssl http2; # # root /config/www; # index index.html index.htm index.php; # # server_name cp.*; # # 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; # proxy_pass http://192.168.1.50:5050; # } #} # sample reverse proxy config for "heimdall" via subdomain, with ldap authentication # ldap-auth container has to be running and the /config/nginx/ldap.conf file should be filled with ldap info # notice this is a new server block, you need a new server block for each subdomain #server { # listen 443 ssl http2; # listen [::]:443 ssl http2; # # root /config/www; # index index.html index.htm index.php; # # server_name heimdall.*; # # include /config/nginx/ssl.conf; # # include /config/nginx/ldap.conf; # # client_max_body_size 0; # # location / { # # the next two lines will enable ldap auth along with the included ldap.conf in the server block # auth_request /auth; # error_page 401 =200 /login; # # include /config/nginx/proxy.conf; # resolver 127.0.0.11 valid=30s; # set $upstream_app heimdall; # set $upstream_port 443; # set $upstream_proto https; # proxy_pass $upstream_proto://$upstream_app:$upstream_port; # } #} # enable subdomain method reverse proxy confs include /config/nginx/proxy-confs/*.subdomain.conf; # enable proxy cache for auth proxy_cache_path cache/ keys_zone=auth_cache:10m;

I have a quick question. I have successfully setup letsencrypt, received my cert, setup nextcloud and can go to my domain/subdomain, however it always returns the index.html page contents in the browser that are found in the letsencrypt www folder. It's like it isn't using the let's encrypt proxy-conf file that I've configured: nextcloud.subdomain.conf Please help me with what I'm missing here. I know it has to be something very simple. This is my nextcloud config.php file I have changed some of the values to keep them private, but you should get the gist. <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'instanceid', 'passwordsalt' => 'passalt', 'secret' => 'mysecret key', 'trusted_domains' => array ( 0 => 'nextcloud ip:port', 1 => 'mysub.duckdns.org', ), 'dbtype' => 'mysql', 'version' => '18.0.4.2', 'dbname' => 'dbname', 'dbhost' => 'mariadb ip:port', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'dbuser', 'dbpassword' => 'mypass', 'installed' => true, 'trusted_proxies' => 'letsencrypt', 'overwrite.cli.url' => 'https://mysub.duckdns.org', 'overwritehost' => 'mysub.duckdns.org', 'overwriteprotocol' => 'https', ); Here is my nextcloud.subdomain.conf again, i changed some of the values to keep privacy. Since I have redirected port 443 to a port 8054, should I change the listening port in the below file? server { listen 443 ssl; listen [::]:443 ssl; server_name subdomain.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_app nextcloud; set $upstream_port 444; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_max_temp_file_size 2048m; } } I appreciate any assistance. These were really the only two files I edited, so if there is something else that needs changed, please shout out and I'll take a look. EDIT: I found in the readme: ### Configure your default site config Make sure that your default site config contains the following lines in the appropriate spots as seen in the default version: 1) For subfolder methods: `include /config/nginx/proxy-confs/*.subfolder.conf;` 2) For subdomain methods: `include /config/nginx/proxy-confs/*.subdomain.conf;` Are they talking about adding that in to the default site conf of nextcloud or in letsencrypt? I see that letsencrypt already has them included. I would imagine this could be my issue.

I've been using the MQTT one for years and have never had an issue with it.

Thanks! It's for controlling a pellet stove. It is a bit important as I start it early in the morning for the space I work in (several hours before I wake up).

The node red dash is absolutely perfect for what I need! Thanks for the suggestion. I have a question regarding node red DELAY node. What is the maximum delay that can be set in this delay node? I have up to 24 hr delays that are feeding in to it, however I just had one that didn't pass through anything after the delay should have run out. I'm thinking that it may have a maximum time delay. Everything else I've done with it on shorter times for testing always passes through my value. Even the other day when I had it setup for maybe 3-4hrs it passed through the msg. On the longer one I just did (8hrs roughly) nothing passed through and there were not messages on the debug resulting in this failure of the output of the delay timer.

Thanks! I'll have to do some thinking and find the best way forward. I appreciate your input as to providing some quality options. I trust your judgement.

Thanks again! Any recommendations for an interactive dash or a separate interactive software? I don't really use lights, but I do have a couple things I switch on and off or put on a timer to turn on most days. Most of my items are sensors collecting data (Temp, humidity), but I'm sure I'll incorporate a few other things over the years. Are you running each of these through unraid dockers? mqtt -> node red -> influxdb -> graphana (dashboard)

Wow, looking grafana... That looks a very intriguing setup! May I ask, do you interface with your sensors or anything on your home network (ie, input for turning lights on/off, switches, or whatever)? If so, what are you using to interact with those objects?

Thanks! I really appreciate it.

What does your guys' data flow look like mostly? I see you have a couchDB spants, where are you fitting that in the picture? I'm overhauling my system since it has been a couple years and I've moved physical locations and trying to get a good handle on a solid way for everything to flow. Device --> MQTT (direct to node red, if not MQTT device) --> Node-Red --> End User Dash?

I'm trying to get this installed on my unraid install, however everything I've tried results in the following when I go to access the webUI. Any Ideas? I have tried bridged and host connection. Would it be better to just run HA in a linux VM of some sort? This site can’t be reached 192.168.5.150 refused to connect. Try: Checking the connection Checking the proxy and the firewall ERR_CONNECTION_REFUSED

Can dashing accept user input to pass on to the MQTT broker? or is it really just for displaying data?

I got it updated. How do I import new libraries? I figured I would go to Menu -- Import -- Library --- Choose file. Do I need to put the file in the docker directory first for it to show up there? It has been so long since I did this that I can't recall what I did back then.