On Tue, May 31, 2011 at 07:40, jcbollinger <john.bollin...@stjude.org> wrote: > On May 30, 3:10 pm, Tim Coote <tim.coo...@googlemail.com> wrote: >> Hullo >> I'm running facter 1.5.8 (fedora 13). I'm not very clear about what >> the variable ipaddress is supposed to represent. > > I suggest you read the discussion at > http://groups.google.com/group/puppet-users/browse_thread/thread/f278468018b13a32, > especially Daniel Pittman's response at the end. As Daniel observes, > *Facter* is not very clear about what that fact represents. > >> I've read that it >> returns the ip address that's bound to the lowest alphabetic name of a >> network interface. That model seems a bit weird to me but that's >> probably because I'm just used to tools that return the set of IP >> addresses associated with the host, as seen from the host. > > No, I think it's because you intuitively understand what Daniel wrote, > that Facter's ipaddress fact is not well-defined, and it is not very > meaningful in the general case.
*nod* Nothing much has changed since way back when; we still have the same vague definition of what ipaddress means, which is "right" in the trivial case where you have only one IP address, and more or less wrong in any complex case. (We have a vague plan to try and be a bit more DWIM-ish by, indeed, respecting either the DNS IP for the current hostname, or the IP of the interface with the default route, when there is only one least-specific-route match. Patches welcome; it isn't super-high priority.) […] >> Facter is returning the IP v4 address on virbr0, which is neither what >> the documentation says, nor much use as I can see that it's likely to >> be the same on all hosts that have libvirt installed. There are no >> IPv6 addresses returned. I think the latest release has IPv6 support, which is distinct from the IPv4 facts. >> Am I seeing the expected behaviour for facter? Do I have to >> standardise how I name network interfaces and associate IP addresses >> to them to be able to deal with them all in a consistent, meaningful >> way (eg to pick out the IP that's used for backup, or the different IP >> addresses connected to the different edge switches)? I would strongly suggest you use something else. I did literally standardise on using the resolved IP from DNS, and made it a failure to compile when that failed to resolve. Your network might not support that, but I would suggest pretending the ipaddress fact just doesn't exist at all. Fixing the interface naming ... nah. Don't contort your network to support a stupid tool. Fix the stupid tool. (Incidentally, you should be able to replace the existing ipaddress fact with a better, higher priority version that does respect your needs, by putting a custom fact in place to override the shipped version. :) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <dan...@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
