2

I am running Ubuntu (12.04) on Virtual Box and want my machine to be able to lookup its own hostname, the same way other VMs will do in this network (I am trying to build virtual cluster). There is no DNS server, IP are assigned by VirtualBox, and I just map them in /etc/hosts.

The machine name is node1 and I have /etc/hosts like that:

user@node1-VirtualBox:~$ cat /etc/hosts
127.0.0.1   localhost 
192.168.56.103  node1-VirtualBox.cs.ucl.ac.uk node1-VirtualBox
#10.0.2.15  node1-VirtualBox

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

So I would assume that

  1. Fully qualified hostname would be node1-VirtualBox.cs.ucl.ac.uk
  2. node1 and node1-VirtualBox.cs.ucl.ac.uk would resolve to 192.168.56.103 (and vice versa)

From hostname I am getting this:

$hostname ->  node1-VirtualBox   (OK)

$hostname --fqdn -> node1-VirtualBox.cs.ucl.ac.uk (OK)

$hostname --A -> node1.local node1.cs.ucl.ac.uk (OK i guess)

hostname looks promising, but when I try to get IP addresses using host, it doesn't work...

user@node1-VirtualBox:~$ host -v -t A node1-VirtualBox
Trying "node1-VirtualBox.cs.ucl.ac.uk"
Trying "node1-VirtualBox"
Host node1-VirtualBox not found: 3(NXDOMAIN)
Received 110 bytes from 127.0.0.1#53 in 1 ms

user@node1-VirtualBox:~$ host -v -t A 192.168.56.103
Trying "103.56.168.192.in-addr.arpa"
Host 103.56.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
Received 108 bytes from 127.0.0.1#53 in 2 ms

Any idea why this isn't working? From what I read and see in config, if DNS is done on localhost, it should just check /etc/hosts... and everything is there, right? And SSH is working, so clearly this file is correct?


Below my configuration:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat group:          compat shadow:         compat

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 networks:       files

protocols:      db files services:       db files ethers:         db files rpc:            db files

netgroup:       nis

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 cs.ucl.ac.uk

ifconfig:
eth0      Link encap:Ethernet  HWaddr 08:00:27:da:a1:bc  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:feda:a1bc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:169 errors:0 dropped:0 overruns:0 frame:0
          TX packets:176 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:123968 (123.9 KB)  TX bytes:21551 (21.5 KB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:99:65:51  
          inet addr:192.168.56.103  Bcast:192.168.255.255  Mask:255.255.0.0
          inet6 addr: fe80::a00:27ff:fe99:6551/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:268 errors:0 dropped:0 overruns:0 frame:0
          TX packets:252 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:78333 (78.3 KB)  TX bytes:71866 (71.8 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:12527 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12527 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:23857104 (23.8 MB)  TX bytes:23857104 (23.8 MB)

POST MORTEM:

Ok, it turns out the "host" command not resolving was a bit of red herring for my original problem - it couldn't work because it doesn't look into /etc/hosts, as explained in answers below.

The original issue was lack of canonical hostname i.e. hostname --fqdn was returning localhost. To fix it i had to have this: 192.168.56.103 node1-VirtualBox.cs.ucl.ac.uk node1-VirtualBox as second line in my /etc/hosts.

However for making it actually work i had to restart my machines and reinstall Cloudera on my cluster.

1

You are doing everything right like putting the entries in /etc/hosts, server address in /etc/resolv.conf, the /etc/nsswitch.conf looks good too.

The problem you are having is due to the understanding of a very specific term "nameserver". All the commands used to resolve IP address to hostname and vice versa used the nameserver addresses from /etc/resolv.conf unless mentioned explicitly. You have put nameserver 127.0.0.1 which is not a valid name server because it is not configured as a nameserver. It is there because of dnsmasq which acts as a DNS cacher (and DHCP server) but host, dig, nslookup take data from a valid, configured nameserver only.

As the host, nslookup, dig commands will use the "nameserver" mentioned in /etc/resolv.conf (unless specified), hostname resolution will not work using these in your case. Although the programs that use /etc/nsswitch.conf or read /etc/hosts will resolve the hostname to IP addresses and vice versa.

If you want to resolve hostnames from /etc/hosts the you need to use getent. For example to resolve "node1-VirtualBox", you need the following command :

getent hosts node1-VirtualBox
  • " It can merely resolve hostnames that are put in the /etc/hosts file, nothing more nothing less. " but this is exactly what I want to do! But seems to be not working... (at least according to my "hosts" command and java utilities that Hadoop apparently uses). As for having 127.0.0.1, this is whats there by default, according to this ("Using dnsmasq as local resolver by default on desktop installations") stgraber.org/2012/02/24/dns-in-ubuntu-12-04 , it just forwards it to this dnsmasq - maybe this guy is just ignoring my /etc/hosts/ for DNS purposes? – Kranach Feb 6 '15 at 16:58
  • @Kranach: I have further clarified it, check my edits. – heemayl Feb 6 '15 at 17:14
  • weird, the comment i put here before disappeared... Anyway, getent worked as you said, and the whole "host not working" problem turned out to be red herring (I guess Cloudera documentation doesn't take into account unusual Ubuntu behavior). Seeing that "everything seems correct", i restarted machine and reinstalled my cluster distribution and it worked! I guess restart and reinstall was what was needed after i fixed my /etc/hosts. Thanks for help! – Kranach Feb 6 '15 at 21:51
  • You should not need to restart after fixing the /etc/hosts. I uses getent hosts to check the way my machine looks up names and IP-addresses, look in man page for what else it looks up, like password database etc. So it uses clib:s way of looking up names, not only one of /e/hosts, /e/resolve.conf etc, but as specified in /etc/nsswitch.conf. So use getent to test that /e/nsswitch.conf works as wanted. Use host, dig or nslookup to check settings in /e/resolv.conf. – Anders Feb 7 '15 at 6:28
0

host/nslookup command utilities try to resolve dns queries directly using nameservers. They do not use /etc/hosts. But the applications do. For example, ping should work. That is, "ping node1-VirtualBox" should resolve to 192.168.56.103 in your case. What do you want to do exactly?

  • You are right, ping resolves node1-VirtualBox to 192.168.56.103. – Kranach Feb 6 '15 at 16:43
  • What i exactly want to do in big picture is to install Cloudera Manager Hadoop cluster on my virtual machines. But for some reasons evne though i tell installer to search for node1-VirtualBox.cs.ucl.ac.uk and it finds it correctly, later it sees it as "localhost" (and sends hostname "localhost" to other nodes within the cluster). According to this cloudera.com/content/cloudera/en/documentation/cdh4/latest/… I should be getting correct ip for host -v -t A hostname but i get "DNX domain not found", so i wonder how to make this 1 work – Kranach Feb 6 '15 at 16:48
  • Indeed, looks like the real problem was elsewhere, I was misleaded because CDH documentation lists "host"/"nslookup" test as standard diagnostic for troubleshooting such problems. Thanks for help! – Kranach Feb 6 '15 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.