Issue #19764 has been updated by Adrien Thebo. Status changed from In Topic Branch Pending Review to Merged - Pending Release
---------------------------------------- Bug #19764: ipaddress not being captured according to documentation https://projects.puppetlabs.com/issues/19764#change-89825 * Author: John Norman * Status: Merged - Pending Release * Priority: High * Assignee: * Category: interface * Target version: 1.7.1 * Keywords: ipaddress * Branch: https://github.com/puppetlabs/facter/pull/431 * Affected Facter version: 1.6.17 ---------------------------------------- For me, this is a showstopper bug. Basically, ipaddress is coming back as: nil My system is Scientific Linux (RHEL-derived) but it seems like it would be a problem for any Linux. Because node identification depends on ipaddress, I can't get my manifests to get applied. See my comment on https://github.com/puppetlabs/facter/commit/0e514b843642176a9322bd3b8d0ad9b4420e516e I'm not 100% sure if I got the facter version right. The commit date was back in December. Here it is: I've been trying to isolate a problem on one of my systems, and the refactoring here for linux seems wrong. Here is the documentation (at http://docs.puppetlabs.com/facter/1.6/core_facts.html#ipaddress): ``` On the Unixes does an ifconfig, and returns the first non 127.0.0.0/8 subnetted IP it finds. ``` Here is an example of the output from my ifconfig command: <pre> 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:9031461 errors:0 dropped:0 overruns:0 frame:0 TX packets:9031461 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3205490447 (2.9 GiB) TX bytes:3205490447 (2.9 GiB) 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:38161277 errors:0 dropped:0 overruns:0 frame:0 TX packets:24601924 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3847964603 (3.5 GiB) TX bytes:5770630041 (5.3 GiB) venet0:1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.0.222.20 P-t-P:10.0.222.20 Bcast:10.0.222.20 Mask:255.255.255.255 UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 </pre> Notice that the value of ipaddress that is supposed to be captured is: `10.0.222.20` Now look at the refactoring of the `ipaddress` fact for Linux. BEFORE, it split the output and checked every line for a regexp match; and then ignored matches for the loop back address (127...). AFTER, there is no split. This means that ONLY the first match would EVER be considered. There is no way that the refactored code can get to the inet address on venet0:1 (in my example). Here's an example irb session following the code: <pre> irb(main):001:0> output = `ifconfig`; nil irb(main):002:0> regexp = /inet (?:addr:)?([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/ irb(main):003:0> match = regexp.match(output) => #<MatchData "inet addr:127.0.0.1" 1:"127.0.0.1"> irb(main):004:0> match[1] unless /^127/.match(match[1]) => nil </pre> You will see this failure more clearly if you add another fixture for ipconfig output (for example, used what I've pasted in above). In your fixture, the very first interface has a non-127.0.0.1 address. Here's the fixture: <pre> eth0 Link encap:Ethernet HWaddr 42:01:0a:57:50:6e inet addr:10.87.80.110 Bcast:10.87.80.110 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1 RX packets:1609444 errors:0 dropped:0 overruns:0 frame:0 TX packets:1479569 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:673812693 (673.8 MB) TX bytes:221186872 (221.1 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5435415 errors:0 dropped:0 overruns:0 frame:0 TX packets:5435415 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:734540224 (734.5 MB) TX bytes:734540224 (734.5 MB) </pre> One last thing: The code here doesn't even look at the IP mask, which is stipulated in the documentation. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
