Unmanaged devices: Do not override device name if it's a managed device

[eduardomozart]

Checklist before requesting a review

Please delete options that are not relevant.

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes # (issue number, if applicable): NetDiscovery task overrides NetworkPort and Name of ESXi hosts glpi-inventory-plugin#530
• Here is a brief description of what this PR does:
  (This is a continuation of Check if MAC address exists before assume it's an Unmanaged device #17506)
  A MAC address should be unique. When running a NetDiscovery task, it may create a new Unmanaged asset with a MAC address that already exists on GLPI, which can lead to duplicate MAC addresses on NetworkPort DB table, so before assuming it's an Unmanaged device, check if there's any item on DB that matches this MAC address. It would be great if GLPI implements an option to cleanup orphans/unmanaged devices from time to time as seen in: https://github.com/glpi-project/glpi-inventory-plugin/blob/e8cd779e0449ab4d402774e39a22f84b69317f3b/hook.php#L357

Here's the output of the affected 'Unmanaged device' asset import:

[20-Jan-2025 10:25:32 America/Sao_Paulo] stdClass Object
(
    [autoupdatesystems_id] => GLPI Native Inventory
    [last_inventory_update] => 2025-01-20 10:25:32
    [is_deleted] => 0
    [type] => Unmanaged
    [name] => 192.168.0.9
    [mac] => 20:47:47:ff:a2:72
    [ips] => Array
        (
            [0] => 192.168.0.9
        )

    [is_dynamic] => 1
    [entities_id] => 1
)

This fix simplies unset the [name] attribute of an unmanaged asset if it's already imported (aka. is a managed asset).

Here's the inventory files as requested by @stonebuzz:

esxi01.json
server02.json

Screenshots (if appropriate):

[stonebuzz]

Hi @eduardomozart

I've tried importing the supplied files several times, but I can't reproduce your problem.

Everything's OK on my side

No Unmanaged created

server02

esxi01

During import do you have GLPI errors (files/_logs/php-errors.log or files/_logs/sql-errors.log)

Could you carry out another test by resetting the Rules for import and link equipments rules?

Best egards

[eduardomozart]

Hello @stonebuzz,
Yes, your tests should work as expected. It only happens when running a NetDiscovery task. The "esxi01" host is first inventoried by ESXi task, but when running a NetDiscovery task on "192.168.0.9", it overrides the "esxi01" name by "192.168.0.9" (it's IP address) because the NetDiscovery task finds a device there, but the NetDiscovery shouldn't override the name of an existing asset. Please notice that server02 isn't directed related to this issue, as it's only the GLPI-Agent, but I appended it's inventory file as you requested.
There's no related errors on php-errors.log and sql-errors.log files.

[stonebuzz]

Can you send me inventory file from discovery module ?

[eduardomozart]

Hello @stonebuzz,
Here's the requested file:
netdiscovery_esxi01.xml.txt
I noticed the following: when uploading the XML manually on GLPI UI or running the GLPI-Agent with debug=2, the "esxi01" hostname isn't overriden (the import is denied), but when running it with GLPI-Agent debug=1, it overrides the hostname without the fix of this PR applied, so I believe it can be an issue with the GLPI-Agent, maybe @g-bougard can help us to troubleshoot this issue. I believe that override maybe only happening when JSON output is used (which I believe is the case when debug=1 since debug=2 shows a XML file on output)?

[g-bougard]

Hi @eduardomozart

netdiscovery files will always be sent as XML when directly sent from a netdiscovery task toward glpi.

And debug value can't change the output format. This is definitively not related. You probably missed another context problem.

[eduardomozart]

Hello @g-bougard, thank you for your response. The only flag I changed was the debug and no changes on GLPI server whatsoever. I'm not sure what caused this, but it's reproduciable.
Edit: I tried to change the debug mode from 1 to 2 and in fact I was able to reproduce it on debug=1 so the debug mode doesn't seems related to this issue.

[stonebuzz]

Following the review of the file generated during the discovery process, I was able to reproduce the observed behavior. However, I question the relevance of performing a discovery on an ESX. Here are some key points to better understand the situation:

1. Absence of an SNMP Module on the ESX
   The ESX does not have an SNMP module, which means it cannot respond with OIDs to the agent’s requests.

   • Without OIDs, the agent cannot determine the type of the device (NetorkEquipment or Printer).
   • Consequently, the device is integrated into GLPI as an Unmanaged type.

2. Handling of Unmanaged Devices in GLPI

   • When GLPI processes a device classified as Unmanaged, it performs a check to determine if an existing asset matches the detected MAC address (because it is possible to convert an Unmanaged asset into a managed asset (Computer, Printer, NetworkEquipment).
   • If a matching asset is found, it is updated (in our case, the name is changed to the IP address detected during discovery as there is no SNMP module and the agent cannot retrieve its real name).
   • If no match is found, GLPI creates a new Unmanaged asset or updates an existing one.

3. Limitations of SNMP Discovery
   SNMP discovery is specifically designed for devices capable of responding to SNMP requests.

   • Example : If a discovery is performed on a Computer, it will also be handled as an Unmanaged device, as it may not provide the expected features for standard SNMP processing.

In my opinion, the issue lies in the improper use of the discovery module. To prevent this behavior, the IP address of the ESX should simply be excluded from the scan range (IP range).

• This approach would prevent the unnecessary update of ESX from Unmanaged.
• The current fix appears to be more of a temporary solution, or a "band-aid", aimed at enabling the discovery of an ESX.

We fully agree that the system can be improved in the long term. We are considering a different approach by implementing a global discovery module, not limited to SNMP devices. This module would allow for the inventory of a PC, an ESX, or a network device equipped with an SNMP module.

However, at this stage, it is essential to use the discovery feature within its current capabilities: detecting and retrieving only devices that respond to the SNMP protocol.

Best regards

[g-bougard]

@stonebuzz said:

However, I question the relevance of performing a discovery on an ESX.

Here I must tell you I fixed an issue on agent in remoteinventory use case: glpi-project/glpi-agent@a2db0fc

@eduardomozart do you use ToolBox or RemoteInventory to inventory ESX computers ?
In that case, you should use current glpi-agent nightly build to not send a netdiscovery XML for ESX computers, or you can wait for coming soon next release. Anyway take care, this is a coming change and the analysis may change with it.

[stonebuzz]

@stonebuzz said:

However, I question the relevance of performing a discovery on an ESX.

Here I must tell you I fixed an issue on agent in remoteinventory use case: glpi-project/glpi-agent@a2db0fc

@eduardomozart do you use ToolBox or RemoteInventory to inventory ESX computers ? In that case, you should use current glpi-agent nightly build to not send a netdiscovery XML for ESX computers, or you can wait for coming soon next release. Anyway take care, this is a coming change and the analysis may change with it.

Ok, but it doesn't matter, it will always be seen as an Unmanaged (no OIDs, no Type)

[eduardomozart]

Hello @stonebuzz, thank you for analyzing this bug further.
When I report a bug report, I always think on the average user experience. The IP range doesn't seems to allow creating IP exceptions, and even being a bad practice, ESX allows DHCP assigned IP address (I believe no one does it), but as it's supported, we can't assume that ESX would always use a fixed IP address, so user may not be able to create an IP exception for it (even if it would be possible, which isn't the case for IP ranges on GLPI Inventory) and we can't assume that the IP address of ESX would always be the same (which could allow us to get the current ESX address on GLPI DB and add an exception for it automatically) - also, there's the possibility of the user to change the IP address manually assigned on their ESX servers, which could make other device undiscovered if set to use the same old IP address of the ESX server.
Just to update: To reproduce this issue, I had to run a NetDiscovery task on the same IP range of ESX server, then a ESX task, and after, when running a NetDiscovery again on the same range, the Name of ESX server on GLPI asset is updated by the device IP address (attribute name returned by NetDiscovery task). I don't see my PR as a hack, since an Unmanaged asset shouldn't change the name of a Managed asset. I see the following workarounds:

1. Since VMware tasks relies in adding up ESXi manually, maybe we could create an exception on GLPI server backend to exclude VMware IP addresses filled on GLPI Inventory from NetDiscovery task, but I believe that it would be cubbersome because it would assume that based on Entities? If the user uses sub-entities or no entities at all and have more than a task with the same range but for different clients/regions? It would not work as expected and may wrongly exclude an IP address from NetDiscovery.
2. Update NetDiscovery task on GLPI-Agent side to not send IP address as a name on NetDiscovery XML response if it's a IP address, so it would not match the , but GLPI-server side would need to be updated to use the IP address as name for Unmanaged assets Unmanaged import (by name) GLPI rule.
3. Update the Unmanaged import (by name) GLPI rule to not match IF the asset is Managed.

Please also notice that this issue is also reproduciable with IP Phone assets, not only ESX assets.

@g-bougard I'm using RemoteInventory (ESX task) on server-side. When updating to GLPI-Agent 1.12 (today nightly build - GLPI-Agent-1.12-git8caa3984-x64.msi) it simply doesn't run ESX task and nothing is shown on GLPI-Agent log.

[stonebuzz]

Let's take the example of an Unmanaged element converted into a Computer (for example, a connected television (already seen before)). If this asset changes its IP address, the name will no longer be updated in GLPI (with your change)

This could represent an inconvenience for users who accept that the name changes according to the IP address (in their management of unmanaged equipment). However, even taking user experience into account, modifying GLPI's behaviour to respond to this specific case does not seem appropriate. (So far, I haven't come across a situation where a dynamic IP address was associated with an ESX via DHCP).

I remain convinced that the proposed solution is not relevant. A more acceptable approach would be to configure two ranges of IP addresses to exclude the problematic IP.

We're still thinking about integrating IP address exclusion management into IP ranges in a future version of the global discovery module.

[stonebuzz]

I would be more inclined to validate a PR that would allow the GLPIInventory plugin to exclude IPs from the IP Range definition.

[eduardomozart]

Hello @stonebuzz,
Thank you for your comments. I agree that GLPI-Inventory should include a feature to exclude IP addresses from IP ranges, but I believe it's not exactly aligned with this case. I would like to see it implemented, of course, but I didn't have the time needed to work on such feature 😔
In my environment, I have only two ESXi hosts and I know their IP addresses. But imagine an IT staff that is starting to use GLPI-Agent. I took a little time to comprehend how tasks works, it was frustating to me to instantiate a task on the beginning. So this IT staff thinks: "Hey, it have a NetDiscovery feature, it's great, let's use it!" and decide to scan their network using it. No one said to them that they have to exclude ESXi hosts from it's NetDiscovery task (!), they will think "I want to use NetDiscovery to discover devices on my network!", and they are not exactly wrong with their statement, it's what this task should do.
I agree with you about keep updating the IP address of the managed device if it's name is an IP address (aka. it hasn't been changed by the user or other tasks like ESXi discovery) and I did a little change to this PR. Similar to #17506, now it:

1. KEEP THE CURRENT BEHAVIOR: If the new name gathered from NetDiscovery task is an IP address, and the current asset name is also an IP address, it updates the name to reflect the new IP address of the device
2. NEW BEHAVIOR: If the new name is an IP address but current asset isn't an IP address (e.g. ESXi task retrieved the name of ESXi server and renamed it), the NetDiscovery task won't gonna update the managed asset name with it's IP address and keep the current asset name.
3. KEEP THE CURRENT BEHAVIOR: If both names (current asset name and new name) aren't IP addresses, update the managed asset name with the name retrieved from NetDiscovery task.

Please note that those verifications supports IPv4/IPv6 addresses.

Here's some output examples of the changes introduced in this PR:

[21-Jan-2025 20:44:38 America/Sao_Paulo] fields:name 192.168.0.8
[21-Jan-2025 20:44:38 America/Sao_Paulo] val:name 192.168.0.9
[21-Jan-2025 20:44:38 America/Sao_Paulo] is_valid(fields) 1
[21-Jan-2025 20:44:38 America/Sao_Paulo] is_valid(name) 1

Scenario 1 (KEEP THE CURRENT BEHAVIOR): fields:name (current asset name) is an IP address, the val:name (new asset name) is also an IP address, so both are valid IP addresses and the asset will be renamed from 192.168.0.8 to 192.168.0.9.

[21-Jan-2025 20:47:03 America/Sao_Paulo] fields:name esxi01
[21-Jan-2025 20:47:03 America/Sao_Paulo] val:name 192.168.0.9
[21-Jan-2025 20:47:03 America/Sao_Paulo] is_valid(fields) 0
[21-Jan-2025 20:47:03 America/Sao_Paulo] is_valid(name) 1

Scenario 2 (NEW BEHAVIOR): Now in this scenario a previous ESXi task renamed the asset to esxi01, so the current asset name isn't an IP address anymore and it won't gonna be renamed.

[21-Jan-2025 20:52:02 America/Sao_Paulo] fields:name esxi01
[21-Jan-2025 20:52:02 America/Sao_Paulo] val:name esxi01.example.com
[21-Jan-2025 20:52:02 America/Sao_Paulo] is_valid(fields) 0
[21-Jan-2025 20:52:02 America/Sao_Paulo] is_valid(name) 0

Scenario 3 (KEEP THE CURRENT BEHAVIOR): Here we have a scenario where an Unix agent runs a NetDiscovery task. On Unix, it seems to be able to use reverse DNS queries (I pretend to implement it on GLPI-Agent for Windows too) and was able to resolve "192.168.0.9" to it's name ("esxi01.example.com"). In this case, both names aren't valid IP addresses, so it will keep the current behavior and will replace the current asset name (esxi01) by "esxi01.example.com", keeping the current behavior. If the user renamed the device and it changed it's NetBIOS/DNS name, it guarantees that even unmanaged devices or agentless devices reflect those changes, keeping the current behavior.

It also believe that it's possible to create GLPI rules for users that didn't want to use the full DNS registry name (scenario 3) using RegEx, so GLPI could split the ".example.com" part of the discovered device name.

It's not a perfect solution for me, as I believe that managed assets should have their name updated only by NetInventory or Inventory tasks, so the "esxi01" host wouldn't be updated to "esxi01.example.com" by NetDiscovery task as it is today. I believe that information gathered from "NetDiscovery" module isn't trustworthy for Managed devices since it can return a name from other device (e.g. device got an IP from other device that was using that same IP address DHCP lease in the past), but I can see it's utility for inventoring agentless/non-SNMP network devices, so I believe this PR is a win-win situation for everyone.