Re: global.ipv4 cannot handle multiple addresses on same interface

Morten Werner Forsbring <[email protected]>
Newsgroups gmane.comp.sysutils.cfengine.bugs
Message-ID <[email protected]>
Morten Werner Forsbring <[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:

[snip]

> So the patch seems to address the problem, thanks. :)

Hi again,

Chun Tian experience that the patch maybe have some side-effects that
I didn't notice. This is what he writes:

  Hi, Werner
  
  Worse bug invoked after this patch...
  
  I have this "editfiles" class definition:
  
  editfiles:
    { /etc/default/snmpd
      ReplaceFirst "^SNMPDOPTS.*$" With "SNMPDOPTS='-Lsd -Lf /dev/null -
  u snmp -I -smux -p /var/run/snmpd.pid ${global.ipv4[eth0]}:1185 $
  {global.ipv4[eth1]}'"
    }
  
  I found one of ${global.ipv4[eth0]} and ${global.ipv4[eth1]} cannot be
  expanded into right value, which depends my interfaces order on
  server.
  
  On one machine:
  
  img7-6:/etc/default# ip addr
  1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
      inet6 ::1/128 scope host
         valid_lft forever preferred_lft forever
  2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
  1000
      link/ether 00:13:21:b5:70:1a brd ff:ff:ff:ff:ff:ff
      inet 222.185.245.186/25 brd 222.185.245.255 scope global eth0
      inet6 fe80::213:21ff:feb5:701a/64 scope link
         valid_lft forever preferred_lft forever
  3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
  1000
      link/ether 00:13:21:b5:70:1b brd ff:ff:ff:ff:ff:ff
      inet 172.17.0.253/20 brd 172.17.15.255 scope global eth1
      inet 192.168.0.186/24 brd 192.168.0.255 scope global eth1:0
      inet6 fe80::213:21ff:feb5:701b/64 scope link
         valid_lft forever preferred_lft forever
  4: tunl0: <NOARP> mtu 1480 qdisc noop
      link/ipip 0.0.0.0 brd 0.0.0.0
  5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
      link/ether 76:20:1a:97:49:3a brd ff:ff:ff:ff:ff:ff
  6: sit0: <NOARP> mtu 1480 qdisc noop
      link/sit 0.0.0.0 brd 0.0.0.0
  
  I got this result in /etc/default/snmpd:
  
  SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid
  222.185.245.186:1185 ${global.ipv4[eth1]}'
  
  On another machine:
  
  img7-7:/etc/default# ip addr
  1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
      inet6 ::1/128 scope host
         valid_lft forever preferred_lft forever
  2: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
  1000
      link/ether 00:13:21:b5:70:d6 brd ff:ff:ff:ff:ff:ff
      inet 172.17.0.254/20 brd 172.17.15.255 scope global eth1
      inet 192.168.0.187/24 brd 192.168.0.255 scope global eth1:0
      inet6 fe80::213:21ff:feb5:70d6/64 scope link
         valid_lft forever preferred_lft forever
  3: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
  1000
      link/ether 00:13:21:b5:70:d7 brd ff:ff:ff:ff:ff:ff
      inet 222.185.245.187/25 brd 222.185.245.255 scope global eth0
      inet6 fe80::213:21ff:feb5:70d7/64 scope link
         valid_lft forever preferred_lft forever
  4: tunl0: <NOARP> mtu 1480 qdisc noop
      link/ipip 0.0.0.0 brd 0.0.0.0
  5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop
      link/ether ae:5f:09:85:ed:24 brd ff:ff:ff:ff:ff:ff
  6: sit0: <NOARP> mtu 1480 qdisc noop
      link/sit 0.0.0.0 brd 0.0.0.0
  
  I got this result in /etc/default/snmpd:
  
  SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid $
  {global.ipv4[eth0]}:1185 172.17.0.254'
  
  The difference of two machine is: the order of eth0 and eth1 is
  different! It's possible that eth1 appears behand eth0, I think the
  patch of cfengine didn't consider that.
  
  Hope this mail is useful for another fix of cfengine.
  
  Regards,
  
  Chun Tian (binghe)

I haven't had time to look at the code yet, do anyone else?


- Werner
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.