Luke Kanies <[email protected]> writes:
> On Jun 19, 2010, at 1:12, Daniel Pittman <[email protected]> wrote:
>> Cody Herriges <[email protected]> writes:
>>> On Jun 18, 2010, at 1:49 AM, Daniel Pittman wrote:
>>>
>>>> The assumption that the "primary" IP address exists, or that it is the
>>>> one that shows up with ifconfig, so a bit bogus: on a number of my hosts,
>>>> for example, the "primary" IP address is an additional address added by
>>>> ip and not visible at all.

[...]

>> Mostly I want to try and make sure that these assumptions don't get too
>> embedded into the heart of puppet, because they encourage community modules 
>> to
>> make the same mistakes, and then make 'em harder to use when I try to
>> introduce them to our more complex networks.
>
> I think that's a reasonable concern.  I'm certainly open to other
> approaches, but so far this has followed our "start simple, complicate only
> when necessary" approach.  While it's obviously true that many machines
> don't have a primary/secondary distinction, the majority do, so it's simple.
>
> I'm happy to see a shift that makes sense, though.

Well, I would encourage exporting the IP addresses on the system as a
structure string (array, once facter and puppet both support them), rather
than trying to distinguish primary and secondary addresses.

I would also encourage that you *don't* export them as things like
'ipaddr_eth0' or whatever — because that confuses people into believing that
they are actually associated with the interface, while that is absolutely not
a portable belief.[1]


Incidentally: below, in the output of the 'ip' command you will see some
addresses flagged as 'secondary'.  This is one of those nice jargon conflicts:
in the output here it has a specific, technical meaning:

    When an address is flagged as secondary the kernel will automatically
    remove it if the address flagged as primary is removed.

That probably isn't the meaning that most people expect when they talk about a
primary or secondary address — although, in some ways it is vaguely analogous.


So, if it was me I would do this on my own laptop:

] facter | grep 'ip6?addr'
ipaddr  => 172.16.23.236,172.16.32.1,172.16.23.240
ip6addr => 
fe80::21c:25ff:fe1e:266f,fe80::21d:e0ff:fe55:4845,fe80::2c0e:ecff:fe2c:714a

...actually, thinking about it maybe exporting the unportable association of
addresses and interface would make some sense.  While it isn't portable, it
probably doesn't have the same level of trouble as concepts like "gateway":

ipaddr_eth0 => 172.16.23.236
ip6addr_eth0 => fe80::21c:25ff:fe1e:266f


Meanwhile, on a production server:

r...@mel-lb02:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:30:48:97:59:AE  
          inet addr:192.168.10.11  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:89686041 errors:0 dropped:0 overruns:0 frame:0
          TX packets:82692679 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3247758521 (3.0 GiB)  TX bytes:4038796073 (3.7 GiB)
          Base address:0x4000 Memory:e8000000-e8020000 

r...@mel-lb02:~# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:30:48:97:59:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.11/24 brd 192.168.10.255 scope global eth0
    inet 192.168.10.130/24 brd 192.168.10.255 scope global secondary eth0:0
    inet 192.168.10.131/24 brd 192.168.10.255 scope global secondary eth0:1
    inet 192.168.10.132/24 brd 192.168.10.255 scope global secondary eth0:2


r...@mel-lb02:~# facter | grep 'ip6?addr'
ipaddr_eth0  => 192.168.10.11,192.168.10.130,192.168.10.131,192.168.10.132


In that case we do have "alias names" assigned to the interface.  On another
production server, which is the newer model for HA use:

r...@mel-db01:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:30:48:33:4A:39
          inet addr:192.168.10.8  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

r...@mel-db01:~# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:30:48:33:4a:39 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.8/24 brd 192.168.10.255 scope global eth0
    inet 192.168.10.194/24 brd 192.168.10.255 scope global secondary eth0

That would also report both addresses (.8, and .194) in the ipaddr_eth0
fact, I would suggest.

Regards,
        Daniel

Footnotes: 
[1]  Linux treats them as a property of the machine, so will respond to any
     address bound to any adapter from any other adapter, with a tiny list of
     exceptions.  Other platforms won't, and Linux can (IIRC) be configured
     not to, but...

-- 
✣ Daniel Pittman            ✉ [email protected]            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to