We tried removing the host option and adding the ports for each service. But nginx-proxy-manager doesnt connect to the db and pihole has a conflict on port 53. Any tips?
I think you may need to tinker a little bit in the sources.
nginx-proxy-manager is a configuration file
proxy/config.json that defines a mysql host as
This works when running in
network_mode: host because it can see the port exposed by the
db service on the host OS.
If you’re dropping the
network_mode: host, the loopback device no longer refers to the HostOS.
network_mode: host, the
proxy service should be running on the same network as the
Changing the mysql host entry to
db so it will use the container directly, rather than the loopback device, should work then.
Strictly speaking, you shouldn’t even need the exposed port on the
db service in this scenario (but it causes no harm).
I don’t have a solution for port 53 (DNS) (yet) as I’ve never worked with pihole before.
Thanks for the suggestion @tjvv, I wasn’t aware that nginx-proxy-manager hardcoded the database address so that’s good to know!
Pi-hole still requires the host network since exposing port
53:53 via docker-compose will result in attempting to bind to 53 on all interfaces, but this will conflict with the hostOS dnsmasq service. You will see logs similar to this if you try binding port
53:53 for any service (not just Pi-hole).
Nov 11 14:04:14 pihole balenad: time="2021-11-11T14:04:14.904055785Z" level=error msg="Handler for POST /containers/79192fc3d6fbc53853a91052471a281ebb4b1a1e34e9dcdb906378c83c3bcedf/start returned error: driver failed programming external connectivity on endpoint pihole_4230096_1977002 (fa4dfa73f8c17e9afa72955647b3aac36fc7d7e2d71d1cdc6b319d0bc0f62875): Error starting userland proxy: listen tcp 0.0.0.0:53: bind: address already in use" Nov 11 14:04:14 pihole f1867163f3fd: [error] Scheduling another update attempt in 256000ms due to failure: Error: Failed to apply state transition steps. (HTTP code 500) server error - driver failed programming external connectivity on endpoint pihole_4230096_1977002 (fa4dfa73f8c17e9afa72955647b3aac36fc7d7e2d71d1cdc6b319d0bc0f62875): Error starting userland proxy: listen tcp 0.0.0.0:53: bind: address already in use Steps:["start"]
A workaround for single device deployments is to hardcode the desired external interface in docker-compose, but this obviously isn’t scalable unless you have the same static IP for every device in the fleet.
services: # https://hub.docker.com/r/pihole/pihole pihole: build: pihole privileged: true volumes: - "pihole_config:/etc/pihole" - "dnsmasq_config:/etc/dnsmasq.d" dns: - "127.0.0.1" - "126.96.36.199" # network_mode: host ports: - "192.168.1.100:53:53/tcp" - "192.168.1.100:53:53/udp" labels: io.balena.features.dbus: "1"
eth0 IP address is 192.168.1.100, this configuration avoids conflicts and allows bridge networking.
If you keep Pi-hole in host networking mode and set the
WEB_PORT environment variable to something other than
80 you should be able to avoid conflicts. Let us know if this works!
db instead of
127.0.0.1 did the trick for nginx-proxy-manager. And setting the
WEB_PORT for a different port enabled us to use host networking mode.
We’re almost there. But for some reason pihole is now conflicting with balena-engine’s dnsmasq. Inside the device, if I stop dnsmasq with
systemctl stop dnsmasq everything works.
So only challenge left is: why is pihole suddenly conflicting with the engine’s dnsmasq?
Hey @luandro, I’m working on a better solution to this but for now make sure that you have the
DNSMASQ_LISTENING=single environment variables for the Pi-hole service and it should avoid conflicts.
We are specifically setting the Pi-hole dnsmasq instance to
bind-interfaces which should avoid it binding to all and instead bind to the provided interface only.
@klutchell I owe you a beer That did the trick, thank you very much!
Glad to hear it worked out! Let me know next time you’re in Canada and we’ll talk!
Hey @klutchell I’ve shifting from Pi-Hole to using AdGuard Home, which I’ve seen you have also worked on.
I’m experiencing a similar problem to what I was having with Pi-Hole around conflict on port 53:
adguard [fatal] couldn't start forwarding DNS server: starting listeners: listening to tcp socket: listen tcp 0.0.0.0:53: bind: address already in use
Having AdGuard as host doesn’t seem to be solving the problem, any suggestions?
This is the repository I’m working from:
Hey @luandro , you should be able to run in host networking mode but as part of the initial setup you need to only bind to port 53 on a specific interface, like eth0 or wlan0, to avoid conflicting with ports on the resin VPN interface.
Check out the initial setup, step 3, on my README.
If you try to bind ports in the format
53:53 it will fail as one of the interfaces has that port in use, and if you use host networking and use the default option of “all interfaces” you will have the same issue.