DNS Sync with rootnets fails for some endnets

Ricky
2016-07-01
2016-08-26
  • Ricky

    Ricky - 2016-07-01

    Since Gestioip syncs the rootnets and contained endnets twice, in order to speed up the process, we disabled the sync in the rootnets but left all endnets with the sync activated.

    It turns out that gestioip in this case, runs the process only in some endnets even though the sync is activated for all.
    We still havent grasped the logic behind this and therefore haven't found all failing cases. So we can't know which are the specific cases where its failing. Right now, we are going to enable all rootnets back again.

     
  • Ricky

    Ricky - 2016-07-01

    ok, it seems nothing was done after network
    Fri Jul 1 04:52:36 2016 root auto dns net auto synch dns x192.168.162.0/24x

    for example, networks
    192.168.18.0/24 and 192.168.19.0/24 failed

    i see the script processes by digit order by the longest match. So these networks:
    192.168.16.0/24
    192.168.160.128/29

    are processed before:
    192.168.18.0/24

    So as I said after 192.168.162.0/24 nothing was processed.

    esba-ipam-ip:log$ tail -n 3 2016063030001_MGMT_ip_update_gestioip_dns.log

    192.168.165.0/24

    We had about 25 more networks after this.

     
  • Marc Uebel

    Marc Uebel - 2016-07-01

    Ricky, here a actualized version of ip_update_gestioip_dns.pl, which processes the networks in correct order. Download and untar it and copy it over the original version
    wget http://www.gestioip.net/files/ip_update_gestioip_dns.tar.gz
    Do not use the sync option for root networks. It is an error that it is possible to mark the sync option for rootnetworks. The option should be disabled. This will be fixed with next update.
    I can not reproduce the problem, that not all networks are processed.
    Please execute the script new version of the script from the commandline and check if there appear error messages:
    /usr/share/gestioip/bin/ip_update_gestioip_dns.pl -v

     
  • Marc Uebel

    Marc Uebel - 2016-07-01

    I just saw that only the "change network" form is affected.
    When creating a network as root network, the sync check-box is correctly disabled.

     
  • Ricky

    Ricky - 2016-07-14

    Marc,
    in the new file you sent, if the gestioip DB has recorded unknown and the DNS has new good data, the update process is not overwriting it.

    old version:
    192.168.10.18: updated: crm-accview.chef.elephant (old entry: unknown)
    192.168.10.19: updated: crm-doc.chef.elephant (old entry: unknown)
    192.168.10.20: updated: zenoss-02.chef.elephant (old entry: unknown)

    new version:
    192.168.9.148: has already an entry in the database: unknown (no rDNS entry) - ignored
    192.168.9.149: has already an entry in the database: unknown (no rDNS entry) - ignored
    192.168.9.150: has already an entry in the database: unknown (no rDNS entry) - ignored

    Are you able to fix this?

     
  • Marc Uebel

    Marc Uebel - 2016-07-14

    Hi Ricky
    I will check this. As I'm making vacacions, this may take some days,
    Thanks,
    Marc

     
  • Macs Kavana

    Macs Kavana - 2016-08-26

    Hi,

    I can confirm this.
    DB filled with snmp discovery, then ip_update_gestioip_dns.pl was run.
    Some hostnames were updated but the majority remained 'unknown' although DNS can resolve those IP-s to exactly one hostname.

    This is the log: a.b.c.d: has already an entry in the database: unknown (no rDNS entry) - ignored

    GestióIP version data:
    GestióIP v3.2 (patch version 10)

    Thank you in advance!

     
    Last edit: Macs Kavana 2016-08-26
  • Marc Uebel

    Marc Uebel - 2016-08-26

    Hi Macs
    I'm not able to reproduce the problem. Is the DNS update via web working?
    Thanks,
    Marc

     
  • Marc Uebel

    Marc Uebel - 2016-08-26

    Hi Ricky,
    what version of GestióIP are you using?
    Thanks,
    Marc

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks