Unable to open URL with grist-omnibus docker in TrueNAS

Kenny · March 20, 2023, 9:25am

Hi, there.

Super impressed by what Grist can do and the potential it has. And, I succeeded to deployed the grist-core on my TrueNAS Scale.

However, everyone could login to my grist and get my data if I use my public IP address as APP_HOME_URL. I tried to set the user authentication correctly with auth0 and authentik but failed all the time. These are too difficult for me.

Today, I found the grist-omnibus and tried to deployed on my TrueNAS. After deployed, the website can not be visited.

In the case of http://my.public.IP.address:28484, it showed ‘Bad Gateway’.

In the case of https://my.public.IP.address:28484, it showed ‘404 page not found’.

I have no idea what is wrong with my settings. The followings are my settings:

docker run \
  -p 80:28484 \
  -e URL=http://my.public.IP.address:28484 \ #use DDNS
  -e TEAM=EXAMPLE \
  -e EMAIL=name@example.com \ #a valid email address
  -e PASSWORD=topsecret \
  -v /mnt/Pool/grist/persist:/persist \
  --name grist --rm \
  -it gristlabs/grist-omnibus

Thank you for the time, and I am looking forward to the reply.

paul-grist · March 20, 2023, 12:15pm

Hi Kenny, not sure if this is the problem, but I think the port numbers here may be in the wrong order - you’d want the port number in the “outside world” on the left, so -p 28484:80.

Kenny · March 20, 2023, 2:10pm

Hi Paul, thank you for the reply. The docker in TrueNAS is edited in dialog box, just like the figure I uploaded. I am not familiar with the syntax of the command line, so I gave the port numbers in the wrong order. The setting of the port number in Docker seems correct.

Although the web page cannot be loaded, the Grist icon on the tab page can be loaded (see Fig. 2) in the case of ‘http’. Hope this info helps.

In addition, I tried to define the port number as an environment variable, -e PORT=28484, -p 28484:28484. This setting doesn’t work and the Grist icon on the tab doesn’t load properly in this case.

The problem is still there.

paul-grist · March 20, 2023, 4:10pm

For http, a container port of 80 is correct. The container has a number of services running within it, so setting PORT isn’t effective, the internal ports just get allocated based on a particular algorithm.

I tried your scenario, and it worked for me, except I needed an extra -e INSECURE_COOKIE=true to make one of the services happy to be working on http outside of localhost (without that setting, logins would proceed, but then give a not authorized error). Could you include a screen shot of your environment variables, just to double check? The URL is particularly important.

…Ah, hang on, I had used a different TEAM setting. If your TEAM setting is literally EXAMPLE, then the problem is (this is embarrassing) the capitalization. It needs to be lower case. If you have access to the container logs, there will be a discreet error along the lines of:

ApiError: Domain is not permitted: Domain must include lower-case letters, numbers, and dashes only.
    at HomeDBManager.unwrapQueryResult (/grist/_build/app/gen-server/lib/HomeDBManager.js:2451:15)
    at main (/grist/_build/stubs/app/server/server.js:110:16) {
  status: 400,
  details: undefined
}

Can you try again with a lowercase TEAM? Sorry about that…

Kenny · March 21, 2023, 2:29pm

TEAM setting
I had not noticed the -e TEAM=cool-beans in the example so I used the upper-case letters. The error definitely exists in the log. I replaced it with -e TEAM=example, and it worked.
About Dex and Google
However, the problem still exists. Here are some of the errors from the container log:

No /custom/dex.yaml
Checking dex... at http://kenny***.tpddns.cn:28484/dex/.well-known/openid-configuration
not ready: FetchError: request to http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration failed, reason: connect ECONNREFUSED my.public.ip.address:28484
Checking dex... at http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration
not ready: FetchError: request to http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration failed, reason: connect ECONNREFUSED my.public.ip.address:28484
Checking dex... at http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration
got: 404
Checking dex... at http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration
got: 502
Checking dex... at http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration
got: 502
failed to initialize server: server: Failed to open connector google: failed to open connector: failed to create connector google: failed to get provider: Get "https://accounts.google.com/.well-known/openid-configuration": dial tcp 172.217.160.109:443: i/o timeout
Checking dex... at http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration
got: 502
Welcome to Grist.
In quiet mode, see http://localhost:17100 to use.
For full logs, re-run with DEBUG=1

As for google, I am not sure whether it is associated with GFW. I am worried about the potential sensititive information in the log so I post some of them. Feel free to let me know if you need to get more details of the logs.

Screen shots of my environment variables
Here are the screen shots of the environment variables.

-e PUID=1000
-e PGID=1000
-e TZ=Asia/Shanghai

These environment variables are also used in other containers.

paul-grist · March 21, 2023, 4:17pm

Kenny:

Checking dex... at http://kenny***.tpddns.cn:28484/dex/.well-known/openid-configuration
not ready: FetchError: request to http://kenny****.tpddns.cn:28484/dex/.well-known/openid-configuration failed, reason: connect ECONNREFUSED my.public.ip.address:28484

For the ECONNREFUSED part, is it getting the IP address correct? And is the IP solid, something that will work for connections originating within the container? How confident are you that outgoing connections from the container are working?

Kenny · March 22, 2023, 4:05am

The ip address is the same as that obtained by the router. The ip address is dynamic, and it will change every once in a while (maybe a few days) or when the router is restarted. In the Pod Shell of the container, I tried curl -v www.bing.com, and here is the output:

*   Trying 202.89.233.100...
* TCP_NODELAY set
* Expire in 149996 ms for 3 (transfer 0x55f0d44c2ae0)
* Expire in 200 ms for 4 (transfer 0x55f0d44c2ae0)
* Connected to www.bing.com (202.89.233.100) port 80 (#0)
> GET / HTTP/1.1
> Host: www.bing.com
> User-Agent: curl/7.64.0
> Accept: */*

So the outgoing connections from the container seems to be working.

paul-grist · March 22, 2023, 12:24pm

Great - from within the container, can you try curling:

http://kenny***.tpddns.cn:28484/dex/.well-known/openid-configuration

And:

https://accounts.google.com/.well-known/openid-configuration

Kenny · March 22, 2023, 1:09pm

Yes. I tried curling http://kenny***.tpddns.cn:28484/dex/.well-known/openid-configuration
and the output is:

*   Trying my.public.ip.address...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x558cff437ae0)
* Connected to kenny***.tpddns.cn (my.public.ip.address) port 28484 (#0)
> GET /dex/.well-known/openid-configuration HTTP/1.1
> Host: kenny***.tpddns.cn:28484
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 502 Bad Gateway
< Date: Wed, 22 Mar 2023 12:36:18 GMT
< Content-Length: 11
< Content-Type: text/plain; charset=utf-8
< 
* Connection #0 to host kenny***.tpddns.cn left intact
Bad Gateway#

For https://accounts.google.com/.well-known/openid-configuration, the output is

*   Trying 142.251.43.13...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55a6a59ebae0)
* connect to 142.251.43.13 port 443 failed: Connection timed out
* Failed to connect to accounts.google.com port 443: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to accounts.google.com port 443: Connection timed out

Kenny · March 22, 2023, 2:48pm

Considering the google part may not be sovled, I had another try to deploy Grist with Auth0. I have stuck with the GRIST_SAML_SP_KEY and GRIST_SAML_SP_CERT. I have no idea where I can get these files.

paul-grist · March 22, 2023, 3:41pm

Hi @Kenny , I can replicate the behavior you see by blocking accounts.google.com. Then the piece of middleware responsible for talking to authentication methods (traefik-forward-auth) fails terminally. I can get past this problem by editing dex.yml to completely remove this part:

 - type: google
   id: google
   name: Google
   config:
     issuer: https://accounts.google.com
     clientID: PUT_CLIENT_ID_HERE_PLEASE
     clientSecret: PUT_GOOGLE_CLIENT_SECRET_HERE_PLEASE
     redirectURI: '{{ getenv "APP_HOME_URL" }}/dex/callback'

Then when I make dex.yml available to the container (see end of README at GitHub - gristlabs/grist-omnibus: an opinionated Grist+Dex+Traefik package for first-time self-hosters) everything comes up OK for me. If Microsoft is blocked, you may need to remove that also.

An unfortunate thing is that once you override dex.yml, the EMAIL/PASSWORD env variables don’t do anything anymore, you’d have to add lines like this to dex.yml instead:

enablePasswordDB: true
staticPasswords:
- email: "name@example.com"
  hash: "$2y$10$6ziUA9ubw90VEbbO2I6aaOgnjM7Qhq1UKxdSHfNLf.DHVGDQaMwOS"

Figuring out the hash is a bit annoying, there are notes here: dex/config-dev.yaml at 2bb4896d120efec1adc98f5db178a6d7206c9cc7 · dexidp/dex · GitHub

Huh, all this isn’t very user friendly, sorry! I didn’t realize dex would contact google/microsoft up front. This is all helpful feedback for me, but I realize it is annoying for you.

For SAML, there are Auth0 instructions at SAML - Grist Help Center including a link with instructions on making the key pair used for signing.

Kenny · March 23, 2023, 12:42pm

Hi @paul-grist , Thank you for your sincere reply. According to your solution, I have been able to log in to my self-built Grist. I can protect my data now. In the process of modifying the dex.yaml, two more things should be noted.

The environment variable EMAIL still needs to be set. Otherwise, an error will be reported as:

Error: Please provide an EMAIL, needed for certificates and initial login.

The environment variable PASSWORD does not need to be set.

dex.yaml seems to need to be mapped to its default location, otherwise it will still report No /custom/dex.yaml. You can use the command find / -name "dex.yaml" to search for dex.yaml in the entire docker container. In my case (TrueNAS Scale), the path to dex.yaml is /settings/dex.yaml.

For SAML, according to the instructions at the help center, I successfully made the key pair (where I got stuck) and mapped them to the docker container (a very critical step). Now I can also log in to the self-built Grist by using SAML.

The package grist-omnibus is user friendly where Google is not blocked. A good one for first-time self-hosters. One suggestion I have is to remove the A-Z in the TEAM for clarity: GitHub - gristlabs/grist-omnibus: an opinionated Grist+Dex+Traefik package for first-time self-hosters.

Thanks again for your time and patience in solving my problem. I learned a lot about SAML and container while solving the problem. I can use Grist to manage data now.

Have a nice day!