On an OpenVZ guest, the main ip is assigned to venet0:0. However, ansible facts list only lo (127.0.0.1) and venet0 (127.0.0.2).
Therefore, one cannot get the machine’s actual IP address using ansible facts.
Facter, however, does show the main IP.
Upon inspecting the source code of both tools, it turns out ansible parses /proc/dev/net, which does not show venet0:0, while facter parses the output of the ifconfig command, which does list both venet0 and venet0:0.
- Are you aware of another way of detecting the venet0:0 interface than using the ifconfig command?
- How do you feel about reimplementing ansible’s get_interfaces() (setup module) using ifconfig instead of /proc/dev/net? I can contribute such an implementation.
Just noticed that get_ipv4_facts() says:
# This is lame, but there doesn't appear to be a good way
# to get all addresses for both IPv4 and IPv6.
and that get_ipv4_facts() parses ifconfig output while get_ipv6_facts parses /proc/net/if_inet6 - although ifconfig does list both ipv4 and ipv6 information.
This is on a debian squeeze. Is it not the case on other distributions? or did that change recently?
Can’t both functions be reduced to one that uses ifconfig, or am I missing something?
Ahmad Khayyat wrote:
Just noticed that get_ipv4_facts() says:
# This is lame, but there doesn't appear to be a good way
# to get all addresses for both IPv4 and IPv6.
and that get_ipv4_facts() parses ifconfig output while get_ipv6_facts
parses /proc/net/if_inet6 - although ifconfig does list both ipv4 and ipv6
information.
This is on a debian squeeze. Is it not the case on other distributions? or
did that change recently?
Can't both functions be reduced to one that uses ifconfig, or am I missing
something?
ifconfig uses an API that has been deprecated for 10 years or so,
and is unable to list all assigned addresses. If you're going for a
command, you should use ip addr list.
OK. ‘ip addr’ seems to provide the needed information. venet0:0 is listed.
But the point still holds: the networking facts in the setup module uses a mixture of /proc files and ifconfig, and claims ipv4 and ipv6 info are not available in one place.
Unless things are different on non-Debian systems, I think many things can be consolidated by parsing the output of ‘ip addr’. If nothing else, we’d need to run a single command only once, and work with its output - an efficiency gain.
It's a very minor and very distributed efficiency gain, but yes, other points hold.
I'm open to reviewing attempts to port the Linux network fact calculation.
That comment is bit old and should have been removed when the network fact collection was most recently reimplemented. The ‘lame’ part refers to running a system command and parsing the STDOUT for fact information. There have been at least a couple cases in the short lifetime of the setup module where I’ve had to go back and fix something because a system command slightly changed its output. One of those cases was ifconfig. 
Parsing /proc/net/if_inet6 is a clean way to get ipv6 information. Unfortunately, there is no equivalent for ipv4.
sf
So, we have two options:
- Reimplement both ipv4 and ipv6 using the output of ‘ip addr’ (run once)
- Reimplement only ipv4 using the output of ‘ip addr’ and keep ipv6 using /proc/net/if_inet6
I’d argue for option 1. If the output changes, ipv4 would need to be updated anyway, at which point ipv6 can be updated as well.
Advantage: consistency, and slight efficiency.
Is there another file in /proc/net that references venet0:0? If not /proc/net, perhaps /sys/class/net?
As noted in my previous email, I’d be loathe to rely on a system command to not change its output format across releases or distributions.
sf
Is there another file in /proc/net that references venet0:0? If not /proc/net, perhaps /sys/class/net?
Neither:
sudo grep -r ‘venet0:0’ /proc/net/
Nor:
ahmad@ovh:~$ sudo grep -r ‘venet0:0’ /sys/class/net/
revealed anything useful.
As noted in my previous email, I’d be loathe to rely on a system command to not change its output format across releases or distributions.
I share your opinion, though at this point it does not look like there is another way.
Is there another file in /proc/net that references venet0:0? If not /proc/net, perhaps /sys/class/net?
Neither:
sudo grep -r ‘venet0:0’ /proc/net/
Please try ‘grep -lR venet0:0 /proc/net’.
Does openvz store information elsewhere in /proc?
Nor:
ahmad@ovh:~$ sudo grep -r ‘venet0:0’ /sys/class/net/
Try ‘ls /sys/class/net/’
Thanks,
sf
Please try ‘grep -lR venet0:0 /proc/net’.
Nothing.
Does openvz store information elsewhere in /proc?
grep -lR venet0:0 /proc
→ Nothing
Try ‘ls /sys/class/net/’
lo venet0
The problem appears to boil down to interface aliases, eg eth0:0 or venet0:0. Perhaps there’s a sane way for get_interfaces() to discover those too.