no such device or address - server gui
-
@Tom-Elliott how is the fog server referencing the target system by its system name as registered in fog?
Just thinking, the OP could open a command prompt on the FOG server and use
nslookup <target_system_name>as well asping <target_system_name>to confirm if the fog server can reach out to the target system and name resolution works correctly? -
Server: 127.0.0.1 Address: 127.0.0.1#53 ** server can't find soulslay: NXDOMAIN -
@dureal99d I’m not sure what that printout is telling us? Can you post what’s in /etc/resolv.conf?
-
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search soulnet.lan``` -
@dureal99d well that’s going to be a problem if the fog server doesn’t have a DNS forwarder running. What is the dns server (IP address) for your network? The one your dhcp server registers clients on.
And what the heck, to avoid another post turnaround, what device is your dhcp server?
-
@george1421 said in no such device or address - server gui:
ell that’s going to be a problem if the fog server doesn’t have a DNS forwarder running. What is the dns server (IP address)
primary dns server is my router 192.168.1.1
but i do have dnsmasq running on my fog server which is running fine to my knowledge 192.168.1.109
i use a router running ddwrt with the internal dnsmasq disabled as i compiled and run dnsmasq 2.76 on the fog server. -
@dureal99d OK if nslookup is installed on your FOG server, key in the following
nslookup nslookup> server 192.168.1.1 nslookup> <name of one of your devices> nslookup> exitThe server command changes your dns server from 127.0.0.1 (the fog server) to your dns server running on your router. See if that resolves your host name to IP address.
-
@george1421 ```
server 192.168.1.1
Default server: 192.168.1.1
Address: 192.168.1.1#53
soulslay
;; connection timed out; no servers could be reached
soulrevise
;; connection timed out; no servers could be reached -
@dureal99d As Tom said, it sounds like a name resolution issue.
The error message coming back from nslookup was 192.168.1.1 is not responding to the dns query. Is the dns service running on your router? I assume your router is also your dhcp server for your network, where dnsmasq of FOG is only doing dhcpProxy (sorry I feel I should know all of this, but I see way too many posts per day to remember everything)
-
@george1421 said in no such device or address - server gui:
but I see way too many post
You are correct. and i just started having this issue.
-
@dureal99d Well I guess you need to work on getting the fog server (linux) to resolve the name to IP address of your hosts. Something has stopped working. Right now the issue is outside of FOG, but at a network/communication level. Once the linux OS on the fog server can resolve the name to IP address then we can focus on FOG and what its doing.
-
@george1421 said in no such device or address - server gui:
Right now the issue is outside of FOG, but at a network/communication level. Once the linux OS on the fog server can resolve the name to IP address then we can focus on FOG and what its doing
fair enough
-
@dureal99d If you’re using dnsmasq, you might want to comment out the port=0 in the ltsp.conf file. (Basically allowing the fog server to act as a dns server) so the dns information it gets should come from the router.
(If i’m understanding the setup correctly, you have a static dhcp reserved for the fog server, but the fogserver initializes using DHCP.)
-
@Tom-Elliott said in no such device or address - server gui:
but the fogserver initializes
the fog server does not have dhcp installed, but it does use dnsmasq. everything else you said is correct
-
Worked out the issue. It was proxydhcp causing the issue. I cannot tell if the issue was Dnsmasq(router and DHCP server) passing off to dnsmasq (proxy DHCP) and not getting the dns to properly route. However, because dnsmasq is already available on the DHCP server we disabled the proxy DHCP and setup the dnsmasq boot items for efi/legacy on the dd-wrt side. This, as I understand it, change around for supporting efi and legacy was the reason he wanted to use proxydhcp to begin with.
