uaborne Posted September 5, 2019 Share Posted September 5, 2019 (edited) 24 minutes ago, aptalca said: Do you have htpasswd file in both letsencrypt and heimdall? If so, delete the one in heimdall. If not, clarify what you're doing. It's not clear where you're running the htpasswd command and where you're deleting the default file. I just found these errors in letsencrypt log so i was just about to ask where the htpasswd file should be. I only had it in heimdall so i should copy it to the letsencrypt config folder instead? for reference i ran docker exec -it heimdall htpasswd -c /config/nginx/.htpasswd <username> in the unraid console/terminal and I deleted the default file from the heimdal folder /nginx/site-confs. 2019/09/05 12:15:05 [error] 378#378: *9 open() "/config/nginx/.htpasswd" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: links.*, request: "GET / HTTP/2.0", host: "x.x.com" Edited September 5, 2019 by uaborne Quote Link to comment
aptalca Posted September 6, 2019 Share Posted September 6, 2019 On 9/5/2019 at 1:40 PM, uaborne said: I just found these errors in letsencrypt log so i was just about to ask where the htpasswd file should be. I only had it in heimdall so i should copy it to the letsencrypt config folder instead? for reference i ran docker exec -it heimdall htpasswd -c /config/nginx/.htpasswd <username> in the unraid console/terminal and I deleted the default file from the heimdal folder /nginx/site-confs. 2019/09/05 12:15:05 [error] 378#378: *9 open() "/config/nginx/.htpasswd" failed (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: links.*, request: "GET / HTTP/2.0", host: "x.x.com" Then you enabled http auth in heimdall. Don't enable it in letsencrypt. Doubling up will cause issues. Quote Link to comment
chazzzle Posted October 18, 2019 Share Posted October 18, 2019 Currently seeing a 502 Bad Gateway on the latest container update. Quote Link to comment
jlficken Posted November 11, 2019 Share Posted November 11, 2019 (edited) It's a great plugin that I'm using as a landing page for my website, however, I keep getting this error after a few refreshes. Any thoughts? ETA: I have found that if I go delete cookies/history/etc from the browser then it works again for awhile. var/www/localhost/heimdall/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/VerifyCsrfToken.php * * @return bool */ public function shouldAddXsrfTokenCookie() { return $this->addHttpCookie; } /** * Add the CSRF token to the response cookies. * * @param \Illuminate\Http\Request $request * @param \Symfony\Component\HttpFoundation\Response $response * @return \Symfony\Component\HttpFoundation\Response */ protected function addCookieToResponse($request, $response) { $config = config('session'); $response->headers->setCookie( new Cookie( 'XSRF-TOKEN', $request->session()->token(), $this->availableAt(60 * $config['lifetime']), $config['path'], $config['domain'], $config['secure'], false, false, $config['same_site'] ?? null ) ); return $response; } /** * Determine if the cookie contents should be serialized. * * @return bool */ public static function serialized() { return EncryptCookies::serialized('XSRF-TOKEN'); } } Arguments "Call to a member function setCookie() on null" One thing that I see is that it is referring to user "abc" which isn't a user of mine. Server/Request Data USER "abc" HOME "/config" HTTP_COOKIE "remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d=eyJpdiI6IkVLQXc3VFo3T1lGWWtkR0lPcHk2U3c9PSIsInZhbHVlIjoiYWdvMDE2Qmc1NzU2UEZXZGcydkJldk91VUFiZGJxUExxWndScV ▶" HTTP_ACCEPT_LANGUAGE "en-US,en;q=0.9" HTTP_ACCEPT_ENCODING "gzip, deflate, br" HTTP_SEC_FETCH_MODE "navigate" HTTP_SEC_FETCH_SITE "none" HTTP_ACCEPT "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3" HTTP_SEC_FETCH_USER "?1" HTTP_USER_AGENT "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36" HTTP_UPGRADE_INSECURE_REQUESTS "1" HTTP_DNT "1" HTTP_X_FORWARDED_SSL "on" HTTP_X_FORWARDED_HOST "home.mydomain.info" HTTP_X_FORWARDED_PROTO "https" HTTP_X_FORWARDED_FOR "192.168.5.1" HTTP_X_REAL_IP "192.168.5.1" HTTP_HOST "home.mydomain.info" PHP_AUTH_PW "" PHP_AUTH_USER "" SCRIPT_FILENAME "/var/www/localhost/heimdall/public/index.php" REDIRECT_STATUS "200" SERVER_NAME "_" SERVER_PORT "443" SERVER_ADDR "172.17.0.4" REMOTE_PORT "33070" REMOTE_ADDR "172.17.0.1" SERVER_SOFTWARE "nginx/1.16.1" GATEWAY_INTERFACE "CGI/1.1" HTTPS "on" REQUEST_SCHEME "https" SERVER_PROTOCOL "HTTP/1.1" DOCUMENT_ROOT "/var/www/localhost/heimdall/public" DOCUMENT_URI "/index.php" REQUEST_URI "/" SCRIPT_NAME "/index.php" CONTENT_LENGTH "" CONTENT_TYPE "" REQUEST_METHOD "GET" QUERY_STRING "" FCGI_ROLE "RESPONDER" PHP_SELF "/index.php" REQUEST_TIME_FLOAT 1573516169.3208 REQUEST_TIME 1573516169 APP_NAME "Heimdall" APP_ENV "local" APP_KEY "base64:TaZDqEor6EbObZWuK1w0P4wcG1bW/2fwbZIvkgGuFjY=" APP_DEBUG "true" APP_LOG_LEVEL "debug" APP_URL "http://localhost" DB_CONNECTION "sqlite" DB_DATABASE "app.sqlite" BROADCAST_DRIVER "log" CACHE_DRIVER "file" SESSION_DRIVER "file" SESSION_LIFETIME "120" QUEUE_DRIVER "database" REDIS_HOST "127.0.0.1" REDIS_PASSWORD "null" REDIS_PORT "6379" MAIL_DRIVER "smtp" MAIL_HOST "smtp.mailtrap.io" MAIL_PORT "2525" MAIL_USERNAME "null" MAIL_PASSWORD "null" MAIL_ENCRYPTION "null" PUSHER_APP_ID "" PUSHER_APP_KEY "" PUSHER_APP_SECRET "" PUSHER_APP_CLUSTER "mt1" SHELL_VERBOSITY 0 Environment Variables APP_NAME "Heimdall" APP_ENV "local" APP_KEY "base64:TaZDqEor6EbObZWuK1w0P4wcG1bW/2fwbZIvkgGuFjY=" APP_DEBUG "true" APP_LOG_LEVEL "debug" APP_URL "http://localhost" DB_CONNECTION "sqlite" DB_DATABASE "app.sqlite" BROADCAST_DRIVER "log" CACHE_DRIVER "file" SESSION_DRIVER "file" SESSION_LIFETIME "120" QUEUE_DRIVER "database" REDIS_HOST "127.0.0.1" REDIS_PASSWORD "null" REDIS_PORT "6379" MAIL_DRIVER "smtp" MAIL_HOST "smtp.mailtrap.io" MAIL_PORT "2525" MAIL_USERNAME "null" MAIL_PASSWORD "null" MAIL_ENCRYPTION "null" PUSHER_APP_ID "" PUSHER_APP_KEY "" PUSHER_APP_SECRET "" PUSHER_APP_CLUSTER "mt1" SHELL_VERBOSITY 0 Registered Handlers 0. Whoops\Handler\PrettyPageHandler Edited November 11, 2019 by jlficken Quote Link to comment
jlficken Posted November 12, 2019 Share Posted November 12, 2019 It is behind the Nginx reverse proxy as well. Here is my conf file contents (bolded lines were adding while trying to troubleshoot): # make sure that your dns has a cname set for heimdall server { listen 443 ssl; listen [::]:443 ssl; server_name heimdall.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_heimdall heimdall; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass_header Set-Cookie; proxy_pass https://192.168.5.40:2443; } Quote Link to comment
jlficken Posted November 15, 2019 Share Posted November 15, 2019 (edited) Is there anyway to download version 2.1.13 as the latest version just doesn't seem to work right for me? Figured it out.... 1) Go to https://hub.docker.com/r/linuxserver/heimdall/tags 2) Find the version that you want 3) Find the Pull Command on the right side of the screen...it will look like - docker pull linuxserver/heimdall:2.1.13-ls45 4) Copy out the "linuxserver/heimdall:2.1.13-ls45" 5) Replace the "Repository" field in the Docker config 6) Click Apply It's not too back so now I get to see if 2.1.13 works as that was the version I was told to use on Github. Edited November 15, 2019 by jlficken Quote Link to comment
Drazzilb Posted December 25, 2019 Share Posted December 25, 2019 (edited) I'm sure I'm setting something up wrong here. I've set up my reverse proxy through Spaceinvader One's excellent tutorial on how to set up Nextcloud and how to have it visible over the internet. (which I've gotten other containers visible over the domain URL, however, they do not use 80/443, such as Ombi) I'm sorry I need to preface this as I'm not super skilled in this realm. If you're asking me to do something, explain like I'm five. The issue I have is trying to get heimdall visible over the internet through my subdomain server.myserver.com However, when I try to access that I get the Letsencrypt's welcome screen. However, If I place the port I opened up in the firewall at the end of the domain URL I can get in. It appears I need some way to make the system know which port to direct me to automatically, which I'm not sure how to do. I obviously changed the default ports from 80 and 443 as these are already used. The only change I made to heimdall.subdomain.conf file is to change it from heimdall.* to server.* Edit: not sure what I did other than remove the information for port 80 in the container edit screen and left 443's port Edited December 25, 2019 by Drazzilb Quote Link to comment
Gog Posted January 7, 2020 Share Posted January 7, 2020 On 12/25/2019 at 4:49 PM, Drazzilb said: I'm sure I'm setting something up wrong here. I've set up my reverse proxy through Spaceinvader One's excellent tutorial on how to set up Nextcloud and how to have it visible over the internet. (which I've gotten other containers visible over the domain URL, however, they do not use 80/443, such as Ombi) I'm sorry I need to preface this as I'm not super skilled in this realm. If you're asking me to do something, explain like I'm five. The issue I have is trying to get heimdall visible over the internet through my subdomain server.myserver.com However, when I try to access that I get the Letsencrypt's welcome screen. However, If I place the port I opened up in the firewall at the end of the domain URL I can get in. It appears I need some way to make the system know which port to direct me to automatically, which I'm not sure how to do. I obviously changed the default ports from 80 and 443 as these are already used. The only change I made to heimdall.subdomain.conf file is to change it from heimdall.* to server.* Edit: not sure what I did other than remove the information for port 80 in the container edit screen and left 443's port You should not have to open a port in the firewall, your reverse proxy should pick up the request on 443 and send the request to the heimdall's port. That is the whole point of a reverse proxy, to block your internal ports from direct access from the internet. It seems you need to configure heimdall in the letsencrypt config folder. Take a look at the samples the linuxserver team already has ready: https://github.com/linuxserver/reverse-proxy-confs Quote Link to comment
mihcox Posted January 9, 2020 Share Posted January 9, 2020 (edited) Can anyone explain how the "tag" functionality works. I have setup a few tabs with a separate tag. After doing that, i expected to be able to sort the main menu by tags, is that possible? I would love to group them on the home page so that unraid, and other links can be kept separate Edited January 9, 2020 by mihcox Quote Link to comment
caplam Posted January 18, 2020 Share Posted January 18, 2020 Hi, with the latest version (i don't know the number) the container is broken, nginx won't start i have the following error: nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4 nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4 i pulled 2.2.2-ls68 and it's back to normal Quote Link to comment
aptalca Posted January 18, 2020 Share Posted January 18, 2020 1 hour ago, caplam said: Hi, with the latest version (i don't know the number) the container is broken, nginx won't start i have the following error: nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4 nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /config/nginx/site-confs/default:4 i pulled 2.2.2-ls68 and it's back to normal Update again. That was already fixed last night Quote Link to comment
caplam Posted January 19, 2020 Share Posted January 19, 2020 I think there might be a synchronisation problem. With 2.2.2-ls68 tag it was ok. Having read you post i updated container with latest tag. It was not ok. I then tried with 2.2.2-ls70 (which is supposed at this time to be the latest) and it was ok. I retried with latest tag and it was broken. So for now i'm with 2.2.2-ls70 tag. Quote Link to comment
Tzundoku Posted February 21, 2020 Share Posted February 21, 2020 Hey there, thanks for the great work. Any way I can configure the search engine options? I.e. remove the ones I never use and add "custom" ones from specific sites I search through often? Quote Link to comment
jlficken Posted February 22, 2020 Share Posted February 22, 2020 I still have the problem that I mentioned earlier in this thread. Does anyone have any ideas? Quote Link to comment
dbinott Posted March 15, 2020 Share Posted March 15, 2020 (edited) UPDATE 3: I wasn't using organizr2 anymore, so I commented that out in letsencrypt and also put back the server 80 https redirect and somehow it is working now. Guess it was jiving with the organizr2 code even tho the container was not on. UPDATE 2: Back to the 502 error. Quote 2020/03/15 14:40:14 [error] 401#401: *10 connect() failed (111: Connection refused) while connecting to upstream, client: 70.xxx.xxx.8, server: dashboard.*, request: "GET / HTTP/1.1", upstream: "https://172.18.0.16:4442/", host: "dashboard.example.com" Changed back to default heimdall subdomain Quote 2020/03/15 14:49:48 [error] 403#403: *17 connect() failed (111: Connection refused) while connecting to upstream, client: 70.xxx.xxx.8, server: heimdall.*, request: "GET /favicon.ico HTTP/1.1", upstream: "https://172.18.0.16:4442/favicon.ico", host: "heimdall.example.com", referrer: "https://heimdall.example.com/" UPDATE: I saw on the heimdal github that subfolders are not supported, changed to subdomain but it just goes to the default nginx page. Fixed that. conf file was not saving after changing subdomain name So, I am trying to get this going but keep getting 502 externally. The error log for letsencrypt nginx says: Quote 2020/03/15 14:23:06 [error] 395#395: *490 connect() failed (111: Connection refused) while connecting to upstream, client: 174.xxx.xxx.146, server: _, request: "GET /heimdal/ HTTP/1.1", upstream: "http://172.18.0.16:5849/heimdal/", host: "xxxxx.com" I have tried bridge mode also. same affect. I have tried http and https. (changed in letsencrypt heimdal conf). There are no other errors in any of the logs. I am also using http auth, but commented that to see. Nothing. root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='heimdall' --net='dabworx' -e TZ="America/Toronto" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -p '5849:80/tcp' -p '4442:443/tcp' -v '/mnt/user/appdata/heimdall':'/config':'rw' 'linuxserver/heimdall' Edited March 16, 2020 by dbinott Quote Link to comment
luizmont Posted March 17, 2020 Share Posted March 17, 2020 (edited) Hello everyone! I've installed and configured Heimdall and it works perfectly fine through the webui. However, if I try to use it with letsencrypt, the page that opens is broken. Other people in this topic had similar issues, but the fix wasn't explained. What might be happening? Everything else works fine with letsencrypt. Ps. I'm using the default .conf file # make sure that your dns has a cname set for heimdall server { listen 443 ssl; listen [::]:443 ssl; server_name heimdall.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #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; } } Ps2. I'm accessing through https://heimdall.domain.com:PORT, because my 443 port is blocked by ISP. TIA Edited March 17, 2020 by luizmont clarification Quote Link to comment
greg_gorrell Posted April 18, 2020 Share Posted April 18, 2020 Anyone know why every item I create on the page ends up with a hyperlink of "10.0.0.2:8443/10.0.0.100:80" instead of simply the address to the container or URI the item is for, 10.0.0.100:80 in this instance? I have tried completely wiping the container and various ways of entering the correct information, as well as searching for some file to edit in the configs with no luck. Quote Link to comment
mikeylikesrocks Posted April 18, 2020 Share Posted April 18, 2020 2 hours ago, greg_gorrell said: Anyone know why every item I create on the page ends up with a hyperlink of "10.0.0.2:8443/10.0.0.100:80" instead of simply the address to the container Are you just entering just the IP address or the full “http://10.0.0.100:80”? I was having the same problem till I put in http:// Quote Link to comment
greg_gorrell Posted April 20, 2020 Share Posted April 20, 2020 On 4/18/2020 at 2:47 AM, mikeylikesrocks said: Are you just entering just the IP address or the full “http://10.0.0.100:80”? I was having the same problem till I put in http:// Well I tried both, but it was going in and editing existing entries and adding the http/https to beginning of link. It didn't work until I removed the container and appdata and reinstalled. Only then was I able to use http for each link and have it work. Thanks for the reply! Quote Link to comment
TwoFive5 Posted April 23, 2020 Share Posted April 23, 2020 I have been able to get everything set up and it is running great. I'm using the letsencrypt docker for reverse proxy and everything works. The only issue I have, is that I have no problem adding a link to another docker container from my server to the homepage of heimdall, provided it is set up as a subfolder, however I can not figure out how, or if its even possible, to add a link to something set up as a subdomain. For example if something was set up as myserveraddresss.com/plex I would just add /plex in heimdall to link it. But if I wanted to add plex.myserveraddress.com it doesn't really have the functionality to add something this way. I just want to be sure I'm not missing something obvious, and if not maybe it could be added in future releases to use subdomains as well as subfolders. Thanks. Quote Link to comment
cpshoemake Posted April 25, 2020 Share Posted April 25, 2020 On 4/23/2020 at 6:20 PM, TwoFive5 said: The only issue I have, is that I have no problem adding a link to another docker container from my server to the homepage of heimdall, provided it is set up as a subfolder, however I can not figure out how, or if its even possible, to add a link to something set up as a subdomain. https://plex.mydomain.com works fine for me. Quote Link to comment
marshy919 Posted April 27, 2020 Share Posted April 27, 2020 On 4/18/2020 at 2:05 PM, greg_gorrell said: Anyone know why every item I create on the page ends up with a hyperlink of "10.0.0.2:8443/10.0.0.100:80" instead of simply the address to the container or URI the item is for, 10.0.0.100:80 in this instance? I have tried completely wiping the container and various ways of entering the correct information, as well as searching for some file to edit in the configs with no luck. Same issue - even putting http first Reinstalled, wiped appdata folder without any success Is there a different fix for this issue? Quote Link to comment
acosmichippo Posted May 22, 2020 Share Posted May 22, 2020 (edited) hi all, tried searching for this but didn't see anything about it. apologies if I missed it. Is it possible to use Jackett as a default search provider for the dashboard? I see it's an option on the dashboard, but not an option for a default in Heimdall's settings. Thanks! Edited May 22, 2020 by acosmichippo Quote Link to comment
Cpt. Chaz Posted June 18, 2020 Share Posted June 18, 2020 hey guys, read through the thread here and saw folks dealing with a few reverse proxy problems, but didn't see a solution for me. i've kept my setup fairly simple with a custom domain "mysite.com". i've got no issues getting this to work for other cname instances, but can't seem to get it working for heimdall. i'm using linux's letsencrypt default subdomain config: # make sure that your dns has a cname set for heimdall server { listen 443 ssl; listen [::]:443 ssl; server_name heimdall.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; 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; } } here's a screenshot of my container config: i've got heimdall setup and working just fine on lan, just can't get it on the reverse proxy side. during troubleshooting, i tried changing upstream to match the container 2443: set $upstream_port 2443 but it didn't make any difference, so i reverted back to default 443 until i get some guidance. i've triple checked my cname in cloudfare at heimdall.mysite.com. Any help is much appreciated, thanks! Quote Link to comment
aptalca Posted June 19, 2020 Share Posted June 19, 2020 2 hours ago, Cpt. Chaz said: hey guys, read through the thread here and saw folks dealing with a few reverse proxy problems, but didn't see a solution for me. i've kept my setup fairly simple with a custom domain "mysite.com". i've got no issues getting this to work for other cname instances, but can't seem to get it working for heimdall. i'm using linux's letsencrypt default subdomain config: # make sure that your dns has a cname set for heimdall server { listen 443 ssl; listen [::]:443 ssl; server_name heimdall.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; 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; } } here's a screenshot of my container config: i've got heimdall setup and working just fine on lan, just can't get it on the reverse proxy side. during troubleshooting, i tried changing upstream to match the container 2443: set $upstream_port 2443 but it didn't make any difference, so i reverted back to default 443 until i get some guidance. i've triple checked my cname in cloudfare at heimdall.mysite.com. Any help is much appreciated, thanks! See here https://blog.linuxserver.io/2019/04/25/letsencrypt-nginx-starter-guide/ 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.