Bug#455743: global.ipv4 cannot handle multiple addresses on same interface
Mark Burgess <[EMAIL PROTECTED]> writes: > I have made a change (Committed revision 524 which hopefully addresses > this. Could someone test it please? Sorry for this late answer: sue:~# ip addr ls ... 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:ce:a4:e3:e4 brd ff:ff:ff:ff:ff:ff inet 192.168.0.101/24 brd 192.168.0.255 scope global eth1 inet 192.168.0.191/32 scope global eth1 inet6 fe80::213:ceff:fea4:e3e4/64 scope link valid_lft forever preferred_lft forever sue:~# cfagent -d3 | grep ipv4 | grep -v "Defined Classes" cfengine:sue:/var/lib/cfengine2/inputs/cfagent.conf:Undefined action classes in sequence 590 : ipv4_2[eth1]=192.168 1895 : ipv4[eth1]=192.168.0.191 2100 : ipv4_1[eth1]=192 4049 : ipv4_3[eth1]=192.168.0 sue:~# # upgrade cfengine sue:~# cfagent -d3 | grep ipv4 | grep -v "Defined Classes" cfengine:sue:/var/lib/cfengine2/inputs/cfagent.conf:Undefined action classes in sequence 590 : ipv4_2[eth1]=192.168 1895 : ipv4[eth1]=192.168.0.101 2100 : ipv4_1[eth1]=192 4049 : ipv4_3[eth1]=192.168.0 sue:~# So the patch seems to address the problem, thanks. :) - Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455743: global.ipv4 cannot handle multiple addresses on same interface
I have made a change (Committed revision 524 which hopefully addresses
this. Could someone test it please?
M
Morten Werner Forsbring wrote:
> Hi!
>
> Here is another bugreport from one of our Debian users.
>
> "Chun Tian (binghe)" <[EMAIL PROTECTED]> writes:
>
>> I have servers with multiple addresses on the same interface eth1:
>>
>> 2: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
>> link/ether 00:1c:c4:a9:73:74 brd ff:ff:ff:ff:ff:ff
>> inet 172.17.2.6/20 brd 172.17.15.255 scope global eth1
>> inet 192.168.0.24/24 brd 192.168.0.255 scope global eth1:0
>> inet 172.17.2.18/20 brd 172.17.15.255 scope global secondary eth1
>> inet 172.17.2.15/20 brd 172.17.15.255 scope global secondary eth1
>> inet6 fe80::21c:c4ff:fea9:7374/64 scope link
>>valid_lft forever preferred_lft forever
>>
>> cfengine's ${global.ipv4[eth1]} returns 172.17.2.15, which is the last
>> address on eth1 (not included eth1:0). I need it return the first
>> address of eth1 (172.17.2.6), because other addresses are dynamic and
>> under control of the Linux-HA/Heartbeat.
>>
>> I think cfengine cannot handle this correctly now, could DD fix this or
>> forward it to the author?
>>
>> Thanks.
>>
>> Chun TIAN (binghe)
>
> I have similar output on servers running Linux Virtual Server [1] and
> HP ServiceGuard [2], e.g. like this for LVS:
>
> [EMAIL PROTECTED] / # ip addr ls
> ...
> 12: bond1: mtu 1500 qdisc noqueue
> link/ether 00:11:43:de:74:c1 brd ff:ff:ff:ff:ff:ff
> inet x.y.z.47/25 brd x.y.z.127 scope global bond1
> inet x.y.z.20/32 scope global bond1
> inet x.y.z.50/32 scope global bond1
> [EMAIL PROTECTED] / #
>
> So this is a more or less common setup on Linux
> cluster-solutions. I've tried a bit with cfengine 2.2.3, and it's the
> last IP listed by 'ip addr ls' that cfengine store in the
> global.ipv4[ethX]-variable:
>
> sue:~# ip addr ls
> ...
> 3: eth1: mtu 1500 qdisc pfifo_fast
> qlen 1000
> link/ether 00:13:ce:a4:e3:e4 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.101/24 brd 192.168.0.255 scope global eth1
> inet 192.168.0.199/24 brd 192.168.0.255 scope global secondary
> eth1
> inet6 fe80::213:ceff:fea4:e3e4/64 scope link
> valid_lft forever preferred_lft forever
> sue:~# cfagent -d3 | grep ipv4
> ...
> 590 : ipv4_2[eth1]=192.168
> 1895 : ipv4[eth1]=192.168.0.199
> 2100 : ipv4_1[eth1]=192
> 4049 : ipv4_3[eth1]=192.168.0
> sue:~#
>
> I agree with Chun Tian that the first IP-address listed by
> 'ip addr ls' should be the one picked up for global.ipvx[ethX], at
> least with these kinds of Linux cluster-solutions in mind. What do you
> think?
>
> Marry christmas! :)
>
>
> - Werner
>
> [1] http://www.linuxvirtualserver.org/
> [2] http://h20219.www2.hp.com/enterprise/cache/6468-0-0-0-121.html
> ___
> Bug-cfengine mailing list
> [EMAIL PROTECTED]
> https://cfengine.org/mailman/listinfo/bug-cfengine
--
Mark Burgess
Web: http://www.iu.hio.no/~mark
Tlf: +47 22453272
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455743: global.ipv4 cannot handle multiple addresses on same interface
Hi!
Here is another bugreport from one of our Debian users.
"Chun Tian (binghe)" <[EMAIL PROTECTED]> writes:
> I have servers with multiple addresses on the same interface eth1:
>
> 2: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:1c:c4:a9:73:74 brd ff:ff:ff:ff:ff:ff
> inet 172.17.2.6/20 brd 172.17.15.255 scope global eth1
> inet 192.168.0.24/24 brd 192.168.0.255 scope global eth1:0
> inet 172.17.2.18/20 brd 172.17.15.255 scope global secondary eth1
> inet 172.17.2.15/20 brd 172.17.15.255 scope global secondary eth1
> inet6 fe80::21c:c4ff:fea9:7374/64 scope link
>valid_lft forever preferred_lft forever
>
> cfengine's ${global.ipv4[eth1]} returns 172.17.2.15, which is the last
> address on eth1 (not included eth1:0). I need it return the first
> address of eth1 (172.17.2.6), because other addresses are dynamic and
> under control of the Linux-HA/Heartbeat.
>
> I think cfengine cannot handle this correctly now, could DD fix this or
> forward it to the author?
>
> Thanks.
>
> Chun TIAN (binghe)
I have similar output on servers running Linux Virtual Server [1] and
HP ServiceGuard [2], e.g. like this for LVS:
[EMAIL PROTECTED] / # ip addr ls
...
12: bond1: mtu 1500 qdisc noqueue
link/ether 00:11:43:de:74:c1 brd ff:ff:ff:ff:ff:ff
inet x.y.z.47/25 brd x.y.z.127 scope global bond1
inet x.y.z.20/32 scope global bond1
inet x.y.z.50/32 scope global bond1
[EMAIL PROTECTED] / #
So this is a more or less common setup on Linux
cluster-solutions. I've tried a bit with cfengine 2.2.3, and it's the
last IP listed by 'ip addr ls' that cfengine store in the
global.ipv4[ethX]-variable:
sue:~# ip addr ls
...
3: eth1: mtu 1500 qdisc pfifo_fast
qlen 1000
link/ether 00:13:ce:a4:e3:e4 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.101/24 brd 192.168.0.255 scope global eth1
inet 192.168.0.199/24 brd 192.168.0.255 scope global secondary
eth1
inet6 fe80::213:ceff:fea4:e3e4/64 scope link
valid_lft forever preferred_lft forever
sue:~# cfagent -d3 | grep ipv4
...
590 : ipv4_2[eth1]=192.168
1895 : ipv4[eth1]=192.168.0.199
2100 : ipv4_1[eth1]=192
4049 : ipv4_3[eth1]=192.168.0
sue:~#
I agree with Chun Tian that the first IP-address listed by
'ip addr ls' should be the one picked up for global.ipvx[ethX], at
least with these kinds of Linux cluster-solutions in mind. What do you
think?
Marry christmas! :)
- Werner
[1] http://www.linuxvirtualserver.org/
[2] http://h20219.www2.hp.com/enterprise/cache/6468-0-0-0-121.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
