On Fri, Apr 30, 2010 at 2:16 AM, Daniel Pittman <dan...@rimspace.net> wrote: > "Marcus, Allan B" <al...@lanl.gov> writes: > >> How does puppet determine the macaccess fact? For example, my MacPro has two >> enternet ports. >> >> macaddress => 00:25:00:ef:fb:ce >> macaddress_en0 => 00:25:00:ef:cf:a1 >> macaddress_en1 => 00:25:00:ef:fb:ce >> >> if I change the wire to the other port (and set the IP address appropriately >> in network), I get the same factor results. It seems factor always report >> en1 as the "macaddress". Is "macaddress" supposed to be the active mac >> address? I suppose it would be difficult to determine 'active' if the >> computer was plugged into two networks at the same time, but that is rarely >> the case in my environment. >> >> Any ideas on how to get the 'active' mac address? > > Er, you noted that you "fixed" this elsewhere, but... > > The 'macaddress' "fact" is a load of random garbage with no meaningful > connection to reality: it picks a random address from the output of ifconfig, > rather than anything useful. > > The idea of an "active" MAC is meaningless: my laptop currently has two > "active" MAC addresses: > > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.45 metric 1 > 192.168.201.0/24 dev wlan0 proto kernel scope link src 192.168.201.109 > metric 2 > 169.254.0.0/16 dev eth0 scope link metric 1000 > default via 192.168.1.1 dev eth0 proto static > > macaddress_eth0 => 00:1c:25:1e:26:6f > macaddress_wlan0 => 00:1d:e0:55:48:45 > > There is no meaningful way to talk about one of those being "active" to the > exclusion of the other: both are active, have real routes, and are interacting > with external devices. You can even fail-over traffic between the two. > > > The right fix would be to put that poor, meaningless fact to sleep before > someone mistakes it for something actually *significant*. >
Yep. The goal for Facter is to have these facts eventually namespaced, though we probably will have to keep existing fact names for backwards compatibility. That is to say, I want to be able to use: nic::wlan0::mac_address and nic::eth0::ip_address, etc. ipaddress itself is not so predictable either in a multi NIC setup, so being explicit is good. Even virtual machines can be dual homed. --Michael -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
