glpi-project / glpi-inventory-plugin

GLPI Inventory plugin
GNU Affero General Public License v3.0
46 stars 27 forks source link

Netdiscovery strange behaviour #461

Open acdmail opened 8 months ago

acdmail commented 8 months ago

Describe the bug

hi, We are trying to migrate from GLPI 10.0.6 with FI plugin to GLPI 10.0.11 with glpi inventory plugin 1.3.4, we are trying to use same import and link rules, however are getting different final inventory results (we have put in place simple test setup)

  1. We have installed GLPI Agent 1.71 and inventoried 2 computers, host1 - 192.168.1.40/28 and host2 - 192.168.1.23/28 glpi_computers

  2. We have defined the Network discovery task/job for IP range 192.168.1.16/28, in which as target we put IP range 192.168.1.16/28 and as actor host 1 iprange glpi-job

  3. We have also put in place a very simple set of import and link rules like below: glpi_rules

  4. We are running the agent on host 1 in order to perform the Network discovery task as result our inventory is becoming glpi-computers-netdiscovery glpi-computers-netdiscovery1

To reproduce

  1. Implement the infrastructure similar to above
  2. Implement same simple set of GPLI import and link rules
  3. run the GLPI agent to perform network discovery

Expected behavior

As per screenshot we have defined only 4 import rules:

  1. Update by UUID - rule which will update the existing computers if they are already present in inventory and have same UUID
  2. Import by UUID - rule which will import computer if no computer with matching UUID found in inventory
  3. Import by IP denied - rule which is supposed to deny import if IP to be imported is already present in inventory 4.Import by IP - rule which will perform the import by IP

However as we can see it seems that rule "Import by IP denied" is not having any effect even if same IP (192.168.1.23) is already present in inventory and belonging to host2 the rule is not denying the import, action passing to next rule "Import by IP" which is updating the host2 leading to non-desirable effects. glpi-computers-netdiscovery glpi-computers-netdiscovery1

To mention here that GLPI 10.0.6 and FI plugin are working properly in this scenario no import is performed

Operating system

Linux

GLPI Agent version

Other (See additional context below)

GLPI version

10.0.11

GLPIInventory plugin

1.3.4

Additional context

No response

acdmail commented 8 months ago

hi, Could you advise please if you have any ideas regarding described?

Thanks

acdmail commented 7 months ago

Hello, Anybody please? Or maybe not in the plugin scope but rather GLPI issue?

Thanks

stonebuzz commented 7 months ago

hi @acdmail

why not use GLPI's default reconciliation rules? (works very well in 98% of cases)

I confess I don't understand what you're trying to do

acdmail commented 7 months ago

@stonebuzz thanks for you response and suggestion, I will try the default rules once again however unfortunately until now I was always in that 98% of cases :) For the submitted issue, I just do not understand why the rules are not working as before anymore and exactly why even if I have the below rule and the IP is already present in GLPI database the effect is not as expected and exactly asset is updated instead of Import denied (so rule just bypassed without matching) image

stonebuzz commented 7 months ago

I've created the same kind of rule

image

my PC has not been updated

But I have this rule in first position

Maybe yours isn't triggered because another upstream rule matches the criteria.

stonebuzz commented 7 months ago

It doesn't really matter,

from what I can see/understand, discovery supports a computer.

Unfortunately the SNMP discovery/inventory task is only dedicated to network equipment and is not at all intended to manage computers (this will be the case for the next network discovery plugin).

I don't really have a solution in this case.

normally from an SNMP inventory / discovery the inventory file (related to computer) should not contain a name, so you should match the "Computer constraint (name)" rule

Perhaps you should refine the IP ranges to exclude PCs?