Change the order of IP addresses returned by ifconfig?

Question

I have an Ubuntu server with several IP addresses attached to it. 127.0.0.1 is listed as venet0 by ifconfig. I'm using Chef to configure the server. The problem is that chef is listing 127.0.0.1 as the IP address for the server instead of one of the server's "real" IPs. (apparent "ohai ipaddress" uses the first IP listed by ifconfig to determine the server's IP).

How can I change the order so the servers main IP is listed first instead of the 127.0.0.1?

Can venet0 be deleted and venet0:0 be "promoted" to take its place since 127.0.0.1 is already listed in the "lo" interface?

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:334 errors:0 dropped:0 overruns:0 frame:0
          TX packets:334 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:16700 (16.7 KB)  TX bytes:16700 (16.7 KB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:7622207 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8183436 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2102750761 (2.1 GB)  TX bytes:2795213667 (2.7 GB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:XXX.XXX.XXX.XX1  P-t-P:XXX.XXX.XXX.XX1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:XXX.XXX.XXX.XX2  P-t-P:XXX.XXX.XXX.XX2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

route -n

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.1       0.0.0.0         255.255.255.255 UH    0      0        0 venet0
0.0.0.0         192.0.2.1       0.0.0.0         UG    0      0        0 venet0

Answer 1

ohai uses route to find the "default interface" by finding your default gateway (destination 0.0.0.0):

network[:default_interface] = from("route -n \| grep -m 1 ^0.0.0.0 \| awk \'{print \$8\}\'")

(From line 21 as of right now)

The problem is that route doesn't care about the aliases on interfaces (venet0:0 and venet0:1 are aliases of the venet0 interface), it assumes that anything sent through the aliases all goes out the same device, so it lists venet0 as the outgoing interface. This is logical when the interface is a physical interface, but when it's a virtual interface it could be wrong (and is wrong in this case). Because of this behavior, it's also technically wrong for ohai to rely on it to determine the "correct" IP address to use, even if the base IP address wasn't 127.0.0.1.

The ideal fix is going to be for you to reconfigure your network settings so that the un-aliased venet0 interface is your "primary IP". If you REALLY need venet0 to be 127.0.0.1 for some reason (I'm not familiar with the venet* interfaces so I don't know why you have it this way or what would happen if venet0 was the primary IP address instead of 127.0.0.1), then you might try finding that network.rb file (/usr/lib/ruby/1.8/ohai/plugins/linux/network.rb in Lucid) and editing it to read

network[:default_interface] = "venet0:0"

(or whichever interface you want it to report as the correct address). I don't know if from() strips the newline that the command would print at the end so it might need to be "venet0:0\n" for ohai to work right. Note that this will be replaced when you upgrade the package it was in.

I am personally curious as to whether ip route list (from the iproute package) shows your "default" route using the venet0 interface or venet0:0 interface. Likewise, netstat -r. If either shows venet0:0 then you might suggest in a bug report to ohai that they try those commands first and if they don't work, try again with the "normal" route command.

Answer 2

I don't know of a way to do this, unless you just remove your loop back device. Not to be nosy, but why does it matter what order they are in?

Answer 3

You may be able to change things around by rearranging entries in /etc/udev/rules.d/70-persistent-net.rules.

If you don't have any entries there, you can try adding your own. This is an example:

# PCI device 0xXXXX:0xXXXX (XXXX)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:00", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Answer 4

What I find bizarre and troubling is that you have the same IP address defined both on your lo and your virtual interface venet0.

My only guess as to why this would be setup this way is that you were unable to bring up the interface without an address though this could have been done with an IP of 0.0.0.0.

Removing the 127. address on venet0 would most likely resolve that problem as well as correct a potential security/performance hole ( fairly sure chef is smart enough not to grab your loopback address ).

Answer 5

It may be nothing more than coincidence but it looks to me like it's being sorted alphanumerically by interface name. I see the same thing on my Linux boxes.

I know nothing about Chef but can you pipe the output of ifconfig through a script which will rearrange it into whatever order you do want?