Site URL Keeps Changing to EC2 Host's IP Address

Get Help
1

We are experiencing an issue where the Site URL keeps changing to the IP address of the host EC2 instance. Are there any particular scenarios where this would be the intended behavior? We are currently unable to reproduce the issue and are “alerted” when users Pulses and Public Links stop functioning.

2

Hi @LLL

Are you using EBS or ELB? It seems like there might be a race-condition, where a health-check somehow causes the wrong URL to be defined.
There’s an PR open for that: https://github.com/metabase/metabase/pull/12996

Alternatively try setting the URL via environment variable, which should prevent it from being changed at all:
https://github.com/metabase/metabase/blob/master/docs/operations-guide/environment-variables.md#mb_site_url

3

Thanks for the very helpful response! As we don’t want anyone to change that URL, we’ll likely move forward with setting the environment variable.

4

Hey @flamber! As a follow up on this, I’ve attempted a few different iterations - passing various values through to MB_SITE_URL and none appear to be accepted. If I don’t pass a value, localhost does display - so it leads me to believe that the value is being parsed and then rejected

While I didn’t believe it to be necessary, I’ve added the following lines to the bin/start file:

if [ $MB_SITE_URL ]; then
    export MB_SITE_URL="$MB_SITE_URL"
else
    export MB_SITE_URL="https://metabase.<internal_domain>.com"
fi
printf "MB_SITE_URL: $MB_SITE_URL\n"

and can see that the env var is being set as expected when I run the following:

docker run --rm -it -p 3333:3000 --env "MB_SITE_URL=http://localhost:3333/metabase/" --env MB_SITE_NAME="this name" <internal_repo>/metabase:latest env

However, upon loading the site at first time setup, the field is null and can still be modified.

My expectation is that it’d state USING MB_SITE_URL as it does in the referenced GitHub issue. I’m hoping I’m misconfiguring something and this is an easy fix. Please let me know if you have any thoughts on what I could be doing wrong here!

ref)s):

5

@LLL You’re in the unlucky position, where you’re hitting multiple issues at once - sounds like you’re seeing this:
https://github.com/metabase/metabase/issues/13084 - read my comment

6

Oof - alright, I’ll give that a shot! Thanks for the quick reply.

7

@flamber - unfortunately, those steps didn’t work either.

Steps taken:
initial run:

docker run -it -p 3000:3000 -e MB_SITE_URL="https://localhost:3333/metabase" <internal_org>/metabase:latest

copy h2 database locally:

docker exec -t <container_id> cat /app/metabase.db.mv.db > ~/Desktop/metabase-data/metabase.db.mv.db

relaunch metabase, now using the DB on my desktop to verify it could be read:

docker run -it -p 3333:3000 -v ~/Desktop/metabase-data:/tmp -e MB_DB_FILE="/tmp/metabase.db" -e MB_SITE_URL="http://localhost:3333/metabase" -e MB_DB_TYPE="h2" <internal_org>/metabase:latest

At this point, I was able to verify that the DB file on my desktop was being read in correctly, so I stopped the container and opened the H2 DB file in DBeaver using v1.4.199 of the H2 Driver (v1.4.200 failed left and right). From here I was able to confirm that the settings modified in the UI were being saved and I inserted the k:v of site-url:http://localhost:3333/metabase into the respective fields of the settings table.

Now, if I don’t specify the MB_SITE_URL as an env var, I do see the same value from DBeaver on the Metabase Settings page - it’s not respected, but it is consistent. Unfortunately, it’s still editable - as I would expect, given the MB_SITE_URL env var didn’t exist. Passing the env var MB_SITE_URL when executing a docker run results in the field being empty.

I’ve tried a few variations of this, too and I’m still getting the incorrect results.

Based on the above, do any other thoughts or suggestions come to mind as how to proceed with this?

8

@LLL

Please post “Diagnostic Info” from Admin > Troubleshooting.

We are currently using 1.4.197 as the H2 driver for various reasons.

That being said, I cannot recommend using H2 at all in production, but I’m guessing you’re just using it as an example (it just isn’t clear to me):
https://www.metabase.com/docs/latest/operations-guide/migrating-from-h2.html

If you don’t set envvars, then the setting is editable - that is correct.
If you set envvars, then that should override the setting - but there are a couple of envvars, which seems to not behave as expected, like the issue I linked to.

There’s an issue open about disabling the field and showing the value, when envvars are set:
https://github.com/metabase/metabase/issues/12272 - upvote by clicking :+1: on the first post

Again, I’m quite sure you’re seeing the problem that this PR is trying to fix:
https://github.com/metabase/metabase/pull/12996
So until that is implemented (or something similar), then the only workarounds I can think if is to build your own version with that PR included.

There’s thousands of installations on AWS, so I’m not sure why this is happening to you so often. I have only seen this problem twice.

9

@flamber - Sorry for dropping off and going AWOL. I believe I have found a bug in setting.clj regarding the priority of the Environment variables.

While on the website it states the following:

Many settings in Metabase can be viewed and modified in the Admin Panel, or set via environment variables. The environment variables always take precedence.

This has not been my experience with all environment variables. As such I dug in deeper and came across these lines in setting.clj which were updated around 6mo ago. The post which I had originally referenced above regarding #9764 was for release v0.32.6, and perhaps the PR #12541 accidentally broke the logic as the code changed.

When I flip the order of (db-or-cache-value setting-definition-or-name) and (env-var-value setting-definition-or-name) such that (env-var-value setting-definition-or-name) is first, the env variables I pass through are set as expected when viewing the Admin settings and then upon restarting of Metabase and not passing the env var, the variable(s) can be set (as anticipated).

That said, when passing MB_SITE_URL, the field is empty and shows the "default" empty string of "foo". I was expecting it to state "Using MB_SITE_URL", similar to #9764 and as it does for the Site Name setting. Picture attached below for additional context.

35
35857×339 20.9 KB

10

@LLL That regression is since 0.36.0 like I already stated in this issue, which I already linked to:
https://github.com/metabase/metabase/issues/13084
Try spinning up 0.35.4