Jump to content
linuxserver.io

[Support] Linuxserver.io - Heimdall

137 posts in this topic Last Reply

Recommended Posts

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 by uaborne

Share this post


Link to post
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.

Share this post


Link to post

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 by jlficken

Share this post


Link to post

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;
    }

 

Share this post


Link to post

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 by jlficken

Share this post


Link to post

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 by Drazzilb

Share this post


Link to post
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

Share this post


Link to post
Posted (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 by mihcox

Share this post


Link to post

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

Share this post


Link to post
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

Share this post


Link to post

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.

Share this post


Link to post

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.