Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

After restarting a headless CentOS 6.3 machine, it lost outbound internet connectivity, i.e. I can still connect to the server via SSH (ssh root@**.126.18.56), but stuff such as ping google.com gives google.com: unknown host, and yum list some_package gives a lot of network errors.

This is what ifconfig gives:

eth0      Link encap:Ethernet  HWaddr 00:25:90:78:2D:5D  
          inet addr:**.126.18.56  Bcast:**.126.18.255  Mask:255.255.255.0
          inet6 addr: fe80::225:90ff:fe78:2d5d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:75594 errors:0 dropped:0 overruns:0 frame:0
          TX packets:787 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7074741 (6.7 MiB)  TX bytes:144391 (141.0 KiB)
          Interrupt:20 Memory:f7a00000-f7a20000 

eth1      Link encap:Ethernet  HWaddr 00:25:90:78:2D:5C  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:16 Memory:f7900000-f7920000 

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:16436  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:504 (504.0 b)  TX bytes:504 (504.0 b)

I have absolutely no clue how to debug this, and I find it very strange since I can still connect via ssh.

EDIT: Weirdly, /etc/resolv.conf does not contain any entries, or none that I can make sense of:

# Generated by NetworkManager
search sui-inter.net


# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# DOMAIN=lab.foo.com bar.foo.com

So is it possible that rebooting the server erased that file? It worked before at least! And how do I solve this?

By the way, pinging an IP address works.

share|improve this question
    
Can you check the DNS settings? (Note that if you connect to the server via ssh then you use your own (local) DNS) –  Hennes Dec 19 '12 at 9:48
    
Sure, but how do I check the DNS settings of the server machine? Networking is not my favourite hobby... –  wnstnsmth Dec 19 '12 at 9:50
1  
ssh to the server, then check /etc/resolv.conf for nameserver entries. (e.g. it may contain a line such as nameserver 8.8.8.8.). Then try pinging that IP (it should be reachable). If it is not then the external nameserver is down or otherwise unreachable. -- Note that if you can ping a server on the net by IP (but not by name) then you have not lost all internet connectivity (in which case: edit the post). Also, this might fit better on another site. –  Hennes Dec 19 '12 at 9:54
    
I edited my post. –  wnstnsmth Dec 19 '12 at 10:17

4 Answers 4

up vote 2 down vote accepted

Ok You can edit the below file to prevent from overwriting resolv.conf

file name is /etc/sysconfig/network-scripts/ifcfg-eth0

Value to set is PEERDNS=no

share|improve this answer
    
This is the accepted answer because editing that file prevented NetworkManager or whatever program from resetting resolv.conf at boot time. Now, DNS values specified in either resolv.conf or ifcfg-eth0 will stay in resolv.conf. –  wnstnsmth Dec 19 '12 at 14:30

I think your file /etc/resolv.conf is not present or no entries in that. Generally it contains the nameserver address which is nothing but DNS server address. All domain names like google.com etc will be resolved by using that DNS server.

Incase of ssh root@**.126.18.56, it is working because here you are giving direct IP address instead of name.

share|improve this answer
    
Yes, that is true. See my above updated post. But do not confuse my local machine which works fine with my remote server machine. ssh root@myservermachine.tld works as well, so the hostname of the server gets resolved correctly. –  wnstnsmth Dec 19 '12 at 10:19

I seems that CentOS rebuilds /etc/resolv.conf on boot, using values found in the scripts in /etc/sysconfig/network-scripts. Those are probably missing, simply not set or maybe corrupt.

So is it possible that rebooting the server erased that file? It worked before at least!

It recreated it with new, up to date values. Except that something went wrong. (e.g. because it had no values to set)

And how do I solve this?

Quick workaround: echo "nameservers 8.8.8.8" > /etc/resolv.conf

Proper solution: Configure the network properly. Start by looking at the Networkmanager. ( I can not go in detail here since I have no CentOS experience. )

share|improve this answer
    
Thanks for your answer, it helped me understand a bit how CentOS handles resolv.conf. I accepted the other answer since it concretely specifies the solution to the problem. –  wnstnsmth Dec 19 '12 at 14:29

Don't allow NetworkManager to manage your server's NIC.

Edit /etc/sysconfig/network-scripts/ifcfg-eth0. Find the line:

NM_CONTROLLED=yes

Change it to read:

NM_CONTROLLED=no

If the line doesn't exist, just add it.

share|improve this answer
    
So should this also solve the above problems with resetting DNS settings? Is this an NM-related issue on CentOS? –  wnstnsmth Dec 20 '12 at 5:10
    
And every other mystery problem you're having with the NIC. Using NetworkManager is not recommended for servers. –  Michael Hampton Dec 20 '12 at 5:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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