Jira (FACT-3061) facter shows 127.0.0.1 as primary on openvzve with version 7.9.0

7 views
Skip to first unread message

Ciprian Badescu (Jira)

unread,
Jul 29, 2021, 3:49:02 AM7/29/21
to puppe...@googlegroups.com
Ciprian Badescu moved an issue
 
Facter / Bug FACT-3061
facter shows 127.0.0.1 as primary on openvzve with version 7.9.0
Change By: Ciprian Badescu
Key: CPR FACT - 833 3061
Project: Community Package Repository Facter
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Atlassian logo

Ciprian Badescu (Jira)

unread,
Jul 29, 2021, 3:51:03 AM7/29/21
to puppe...@googlegroups.com
Ciprian Badescu commented on Bug FACT-3061
 
Re: facter shows 127.0.0.1 as primary on openvzve with version 7.9.0

Helmut Ritter, what version showed the correct ip address? It was 7.x, 6.x or something older?

Helmut Ritter (Jira)

unread,
Jul 29, 2021, 6:18:02 AM7/29/21
to puppe...@googlegroups.com

Well, yes, I thought it worked with facter 3.14.14, see here:

https://tickets.puppetlabs.com/browse/FACT-2898

But I cannot reproduce installing puppet-agent_6.19.1-1bionic_amd64.deb

The thing is that OpenVZ might be very special here:

 

helmut@h2873756:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/void
inet 127.0.0.1/32 scope host venet0
valid_lft forever preferred_lft forever
inet 85.214.124.85/32 brd 85.214.124.85 scope global venet0:0
valid_lft forever preferred_lft forever
inet6 2a01:238:42d5:ca00:ef9e:8538:caa:af9/128 scope global
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet 10.0.124.18 peer 10.0.124.17/32 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::abda:44ed:de16:17d/64 scope link stable-privacy
valid_lft forever preferred_lft forever
helmut@h2873756:~$

helmut@h2873756:~$ ifconfig -a
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 135 bytes 8764 (8.7 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 135 bytes 8764 (8.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.0.124.18 netmask 255.255.255.255 destination 10.0.124.17
inet6 fe80::abda:44ed:de16:17d prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 625 bytes 47360 (47.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1551 bytes 516911 (516.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet 127.0.0.1 netmask 255.255.255.255 broadcast 0.0.0.0 destination 127.0.0.1
inet6 2a01:238:42d5:ca00:ef9e:8538:caa:af9 prefixlen 128 scopeid 0x0<global>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)
RX packets 65255 bytes 78235079 (78.2 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14871 bytes 2787756 (2.7 MB)
TX errors 0 dropped 125 overruns 0 carrier 0 collisions 0

venet0:0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP> mtu 1500
inet 85.214.124.85 netmask 255.255.255.255 broadcast 85.214.124.85 destination 85.214.124.85
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC)

helmut@h2873756:~$

ip6 is bound to venet0 but ip4 is an alias. So facter ipaddress6 resolves correctly but ipaddress doesn't:

helmut@h2873756:~$ facter ipaddress6
2a01:238:42d5:ca00:ef9e:8538:caa:af9
helmut@h2873756:~$ facter ipaddress
127.0.0.1
helmut@h2873756:~$

Of course one might argue that venet0 IS the primary interface but 127.0.0.1 does not make sense.

Ciprian Badescu (Jira)

unread,
Aug 2, 2021, 10:22:04 AM8/2/21
to puppe...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages