-
-
Notifications
You must be signed in to change notification settings - Fork 16
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
Multiple networks doesnt work #1020
Comments
All my other *arr-containers are all configured with two networks and working fine.
|
I have the same setup and the same issue… |
In the context of servers, 0.0.0.0 means "all IPv4 addresses on the local machine". If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs. |
I'm no contributor or anything, but I'm failing to understand how a user's network misconfiguration is related to this project ? I've basically got the same archictecture, with nginx, running with no problem whatsoever. Plus you don't provide any useful logs, what's the error ? ECONNREFUSED, sockethangup ? Can you curl the API from the frontend network ? Is 172.19.0.9 pingable from the frontend network ? |
@Nowadays, this is not related to network misconfiguration. The Maintainerr application is only listening on one of the two network interfaces. Therefore I can't use Traefik to reverse proxy into the application. To make this work, the Maintainerr application need to listen on all interfaces (0.0.0.0). 172.19.0.9 is not pingable from the frontend network (and should not be). |
I have the same issue as the OP and is has nothing to do with any network misconfiguration. The Maintainerr container only listens on the first of my two configured networks which happens to be the "fallback" one for direct container access. It does not listen on the second one used in conjunction with Nginx as reverse proxy. Nginx error is a simple "Connect() failed (connection refused)" resulting in a "502 Bad Gateway" in the browser. |
So for me this works...:
The Basic Auth is created using this:
Replacing all $ by $$ (eg: $apr1$c99/GTZt$EasfS/xasd6dXggSeJ.JwRj1 becomes $$apr1$$c99/GTZt$$EasfS/xasd6dXggSeJ.JwRj1) I also tried it with and without modifying
That actually results in this:
But even without line 15 it works totally fine behind traefik.... Well, ok, maybe because I only have web, not a second network... Greets |
@MikeMatau Sure, this works. Because you are just using one network (web) for the container, even though you defined two in the compose file. ;-) However, OP and I attach two (!) networks to the container and this does not work (just one of them works). |
I added the second network:
I also still have the line 15 in /etc/supervisord.conf changed to include HOSTNAME=0.0.0.0:
And it works totally fine.... For you to test: Create a file
below the data folder... |
In PR #1104, @MikeMatau's workaround was incorporated in the default supervisord.config. This will be available in the next release. |
Ideally we should use |
Describe the bug
One I bind multiple networks to the container the application only available on one of them.
I have one networks for all frontend-applications, that I want exposed through traefik, that network is called "frontend".
I have one network for communication between all *arr-containers, that network is called "arr".
It looks like the application is only listening for requests coming from the "arr"-network. This is also the ip-address that is logged to the terminal when the application is started.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The application should be available on all networks.
Screenshots
Device (please complete the following information):
The text was updated successfully, but these errors were encountered: