https://netmaker.org logo
Powered by
network_mode host setup issues - DNS not propegati...
# server
b
network_mode host setup issues - DNS not propegating
maybe this s better in the "install" channel as its a new setup, but I'm having difficulty figuring out what the correct current config looks like for a 
network_mode: host
setup - based on issue #1112, both 
PORT_FORWARD_SERVICES
and 
MANAGE_IPTABLES
need to be removed from the 
docker-compose.hostnetwork.yml
file thats on master right now (which I've done - tho I've also switched it to traefik as I have much more experience with that + an external DB), however DNS is still not propagating to my endpoints running netclient (no population of /etc/hosts) - any idea what I'm missing? (docker-compose below)
j
hmmm DNS_MODE=on should be it...the network mode shouldn't have an impact on dns propagation
b
maybe its some sort of client thing? the client seems to work fine, but it shows as status "ERROR" in the web UI, even tho I cant find any upset-looking logs anywhere so not sure why
this same client was previously working with netclient on a non-hostmode setup (and /etc/hosts was getting filled in)
j
ahhh yes, it sounds like MQ is likely not working then, in which case it would not be recieving dns updates
b
in the MQ logs I can see the client connecting, and on the client I can see 
checkin for <NETWORK NAME> complete
might it be the server is unable to connect to MQ? - if so, where in logs etc might I see why that is?
b
in the mq logs you should see a connection to 1883 -- that is netmaker connecting to the broker
b
hmmm ok I'm seeing 
connecting to mq broker at mq:1883
in the netmaker logs, but not seeing any connections over that port in MQ so I think that might be it
it's working! at first I tried removing both MQ_HOST and MQ_PORT from the docker-compose as those aren't present in the 
docker-compose.hostnetwork.yml
but then I could see in the logs that netmaker was trying to connect to MQ over 1883 via the public IP (which it's purposefully not bound to as per the port mappings) so I added 
MQ_HOST: localhost
and success!
update: removing MQ_PORT actually broke joining new clients, as apparently that config var is the one used by clients for their MQ connection... I have to say, the fact that MQ_HOST and MQ_PORT serve completely unrelated configuration purposes is incredibly un-intuitive, but I can see how it ended up that way haha
b
indeed ... the first iteration of MQ had everyone connecting via tcp (no encryption, no certs) to 1883. much easier for testing but not very secure
11 Views
PreviousNext
Powered by