Jira (FACT-2846) Facter 4 fails to parse linux tun* interfaces on our openvpn server

[Adam Tkac (Jira)]

Title: Message Title

Adam Tkac created an issue   Facter / FACT-2846 Facter 4 fails to parse linux tun* interfaces on our openvpn server Issue Type: Bug Affects Versions: FACT 4.0.43 Assignee: Unassigned Components: Facter 4 Created: 2020/10/22 1:14 AM Environment: Linux, up2date CentOS 7.8 Working: # facter --version 3.14.10 Non-working (missing interfaces in networking fact): # facter --version 4.0.43 Priority: Normal Reporter: Adam Tkac During adoption of facter 4 in our environment, we hit issue on our CentOS 7 OpenVPN server. It has following network interfaces configured: [root@openvpn02:~] ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 9000 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 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000 link/ether fa:16:3e:8e:9c:98 brd ff:ff:ff:ff:ff:ff inet 50.56.10.143/32 brd 50.56.10.143 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000 link/ether fa:16:3e:2a:33:4a brd ff:ff:ff:ff:ff:ff inet 10.15.159.180/20 brd 10.15.159.255 scope global eth1 valid_lft forever preferred_lft forever 5: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.141.0.1 peer 10.141.0.2/32 scope global tun1 valid_lft forever preferred_lft forever 24: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.160.0.1 peer 10.160.0.2/32 scope global tun0 valid_lft forever preferred_lft forever It seems that facter 4 doesn't like the tun* OpenVPN interfaces, output from facter --debug [2020-10-22 09:56:08.388748 ] DEBUG Facter::Util::FileHelper - File at: /run/systemd/netif/leases/3 is not accessible. [2020-10-22 09:56:08.388861 ] DEBUG Facter::Resolvers::NetworkingLinux - ip_tokens = ["5:", "tun1", "inet", "10.141.0.1", "peer", "10.141.0.2/32", "scope", "global", "tun1\\", "valid_lft", "forever", "preferred_lft", "forever"] [2020-10-22 09:56:08.388932 ] DEBUG Facter::Resolvers::NetworkingLinux - interfaces = {"lo"=>{:bindings=>[{:address=>"127.0.0.1", :netmask=>"255.0.0.0", :network=>"127.0.0.0"}]}, "eth0"=>{:bindings=>[{:address=>"50.56.10.143", :netmask=>"255.255.255.255", :network=>"50.56.10.143"}]}, "eth1"=>{:bindings=>[{:address=>"10.15.159.180", :netmask=>"255.255.240.0", :network=>"10.15.144.0"}]}} [2020-10-22 09:56:08.388951 ] DEBUG Facter::Resolvers::NetworkingLinux - fill_ip_v4_info! [2020-10-22 09:56:08.388969 ] DEBUG Facter::Resolvers::NetworkingLinux - interface_name = tun1 ip4_address = 10.141.0.1 ip4_mask_length = [2020-10-22 09:56:08.389762 ] DEBUG Facter::Resolvers::NetworkingLinux - resolving fact interfaces, but undefined method `<' for nil:NilClass Due to error above, there are no interfaces related facts with facter 4: [root@openvpn02:~] facter networking { domain => REDACTED, fqdn => REDACTED, hostname => "openvpn02" } For comparison, facter 3 handles this networking setup well. Example: ... tun0 => { bindings => [ { address => "10.160.0.1", netmask => "255.255.255.255", network => "10.160.0.1" } ], ip => "10.160.0.1", netmask => "255.255.255.255", network => "10.160.0.1" }, tun1 => { bindings => [ { address => "10.141.0.1", netmask => "255.255.255.255", network => "10.141.0.1" } ], ip => "10.141.0.1", netmask => "255.255.255.255", network => "10.141.0.1" } ... Would it be possible to fix facter 4 somehow? Either that it will parse tun0/tun1 interfaces correctly, or that it will ignore them as "unknown" and return the rest of interfaces. Both ways are OK for us. Please let me know if you have any questions or if you need more debugging info. Add Comment   This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.375629.1603354499000.61000.1603354560052%40Atlassian.JIRA.