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''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. On one of my machines, ifconfig returns 5 device names which can have IP addresses associated with them (eth0, lo, virbr0, vmbridge, and vnet0), of these, eth0 is bridged to vmbridge (and has no IPv4 address of its own), lo I don''t care about, virbr0 is the internal (ie not visible off the host) bridge created by some libvirt (I think) and I don''t know where vnet0 comes from. 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. 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)? tia Tim -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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. It''s not very useful if you have to worry about machines that have more than one non-loopback network interface. It might be even less useful than that.> On one of my machines, ifconfig returns 5 device names which can have > IP addresses associated with them (eth0, lo, virbr0, vmbridge, and > vnet0), of these, eth0 is bridged to vmbridge (and has no IPv4 address > of its own), lo I don''t care about, virbr0 is the internal (ie not > visible off the host) bridge created by some libvirt (I think) and I > don''t know where vnet0 comes from. > > 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. > > 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''m not sure whether you''re seeing the expected behavior. If ifconfig lists an IP address for eth0, then probably not. Otherwise, probably so, though it must be understood that "expected" is not necessarilly the same as "most desirable". I recommend that you reserve twiddling interface names for a last resort. It really shouldn''t come to that. I also recommend, however, that you stop using the ''ipaddress'' fact. In the words of Inigo Montoya, "I don''t think it means what you think it means." Pittman offered an alternative in the discussion I linked above. You might also be able to use one of the per-interface ipaddress facts (e.g. ipaddress_eth0) if that''s sensible and if facter is picking it up (check by running facter from the command line on the system in question). If neither of those fits the bill, then a custom fact is pretty easy to write and distribute; that''s the Swiss army knife of Facter. John -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, May 31, 2011 at 07:40, jcbollinger <John.Bollinger@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 <daniel@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks, chaps. Pleased to hear that I''m not mad. The relationship between IP addresses and hosts is non-trivial, especially when you wrap in the MAC address concept. It''s also asymmetrical in the sense that the value seen from ''inside'' a host may not relate to the value used ''outside''. I''ve been through a lot of pain with this domain model elsewhere (happy to provide references for those that are interested, but no code, I''m afraid). There''s also complexities if one assumes that DNS resolves hostnames to IP addresses: it just resolves names to IP addresses. I think that I''m going to ignore this issue for the moment as something that just doesn''t work yet. Tim On May 31, 6:28 pm, Daniel Pittman <dan...@puppetlabs.com> wrote:> 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/f278..., > > 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, May 31, 2011 at 14:04, Tim Coote <tim.coote1@googlemail.com> wrote:> Thanks, chaps. Pleased to hear that I''m not mad. The relationship > between IP addresses and hosts is non-trivial, especially when you > wrap in the MAC address concept. It''s also asymmetrical in the sense > that the value seen from ''inside'' a host may not relate to the value > used ''outside''.Yeah. If you only ever dealt with the single-homed, single-address case (or maybe trivial NAT) it is easy to assume that there is "an" IP address for a host, but in the data center... not so much. :)> I''ve been through a lot of pain with this domain > model elsewhere (happy to provide references for those that are > interested, but no code, I''m afraid). There''s also complexities if > one assumes that DNS resolves hostnames to IP addresses: it just > resolves names to IP addresses.Yeah; for a non-trivial number of cases this is the least wrong "do what I mean" answer, but it is absolutely not clear that the hostname and "the" IP address of a host are the same. I would only look to that if either I knew local convention assured it, or as a "less wrong" answer for this fact for compatibility. :)> I think that I''m going to ignore this issue for the moment as > something that just doesn''t work yet.Yah. Better write your own fact, or resolution, to match local rules. Daniel> > Tim > > On May 31, 6:28 pm, Daniel Pittman <dan...@puppetlabs.com> wrote: >> 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/f278..., >> > 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+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.