Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

explicitly-set host name overridden by environment variables #3069

Open
bberkeyU opened this issue Nov 9, 2024 · 1 comment
Open

explicitly-set host name overridden by environment variables #3069

bberkeyU opened this issue Nov 9, 2024 · 1 comment
Labels
bug something broken P2 considered for next cycle

Comments

@bberkeyU
Copy link

bberkeyU commented Nov 9, 2024

I am running a dash app on a remote AlmaLinux machine. I connect to the remote machine from a Windows 10 computer via a ssh tunnel: "ssh -L 8050:localhost:8050 AlmaLinuxServerName. The AlmaLinux computer has restrictive rules preventing connections on all but a few ports coming in on its external IP interfaces but much less restrictive rules for connections to the localhost interface.

The dash app would start and run on AlmaLinux , but Windows 10 connecting over the SSH tunnel would get ERR_CONNECTION_RESET errors in the web browser and the terminal of the AlmaLinux would get a "channel 3: open failed: connect failed: Connection refused" every time the web browser tried to refresh.

Furthermore no matter what values I put into the host for the dash run() command, I would get:
netstat -ltun | grep 8050
tcp 0 0 AlmaLinuxURL:8050 0.0.0.0:* LISTEN

Where AlmaLinuxURL is the hostname in my AlmaLinux environment variable. Based on the network configuration, I need the result to be something like:
netstat -ltun | grep 8050
tcp 0 0 localhost:8050 0.0.0.0:* LISTEN
Note, other versions of the localhost name would work (127.0.0.1 etc)

  • replace the result of pip list | grep dash below
dash                          2.18.1
dash-core-components          2.0.0
dash-html-components          2.0.0
dash-table                    5.0.0
  • if frontend related, tell us your Browser, Version and OS
    Not relevant but tested with,
    • OS: Windows 10, AlmaLinux
    • Browser: Chrome,Firefox

Describe the bug
OS host environment variable overrides explicitly set host with an app.run_server(debug=True, port=8052,host="localhost") call. This is an issue on my compute host because the external IP interface is locked down to outside connections and will only allow connections to localhost via an ssh tunnel. The hostname in my environment variable points to the locked-down external IP interface. So, it doesn't matter what I put into the run_server call. Dash overwrites this with the locked-down interface, and the Flask app is unavailable.

After a lot of debugging, I was able to get my dash app working I added an
os.environ["HOST"] = "127.0.0.1" call to my code before initializing dash. This allowed me to set the flask host to the one I expected. This didnt solve the issue that I expected to get the host name that I set; but it did let the app run.

Expected behavior

When the host is explicitly set, it should override the default or environment variables. If it is considered desirable to change the host or port via environment variables instead of code, Dash should adopt environmental variables specific to Dash, for example, DASH_HOST and DASH_PORT.

@gvwilson gvwilson changed the title [BUG] Explicit set host name overridden by enviroment variales. explicitly-set host name overridden by environment variables Nov 11, 2024
@gvwilson gvwilson added bug something broken P2 considered for next cycle labels Nov 11, 2024
@gvwilson
Copy link
Contributor

hi @bberkeyU - I spoke with one of our team, who said:

It's an old bug with the build system of conda, seems to be fixed upstream as I couldn't reproduce with latest anaconda3 and the related issues were closed. But the conda ecosystem is varied and some environment uses older or custom/forks versions.

We could change the HOST and PORT variable to be prefixed with DASH_ like the other environment variables we have but that would be a breaking change. Or check the argument variable first, but that would invert the priority order of env > argument.

Hope this helps - @gvwilson

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken P2 considered for next cycle
Projects
None yet
Development

No branches or pull requests

2 participants