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.
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:
are processed before:
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
We had about 25 more networks after this.
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
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:
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.
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.
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)
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?
I will check this. As I'm making vacacions, this may take some days,
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!
I'm not able to reproduce the problem. Is the DNS update via web working?
what version of GestióIP are you using?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.