Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESX inventories hosts become Agents #831

Closed
eduardomozart opened this issue Jan 22, 2025 · 1 comment
Closed

ESX inventories hosts become Agents #831

eduardomozart opened this issue Jan 22, 2025 · 1 comment

Comments

@eduardomozart
Copy link
Contributor

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

Hello,
When inventoring a ESXi host using Windows or Unix agents, it creates an "Agent" actor on GLPI agent settings. I believe it happens because while digging on #828 I saw that ESXi tasks replaces the <DEVICEID></DEVICEID> computer ID with ESX own identity based on ESX hostname, but I believe it leads to GLPI server believe it's an Agent since there's no information to differentiate a ESX inventory from a "normal" Inventory since both have the same <QUERY></QUERY>, but it's just a guess, I still didn't have enough time to troubleshoot it further and attempt to fix.

Image

To reproduce

  1. Do a ESX inventory.
  2. A new agent is created based on ESX host.

Expected behavior

A new agent shouldn't be created when inventoring ESX hosts.

Operating system

Windows, Linux

GLPI Agent version

v1.11

GLPI version

10.0.17

GLPIInventory plugin or other plugin version

GLPI Inventory v1.4.0

Additional context

No response

@eduardomozart eduardomozart added the bug Something isn't working label Jan 22, 2025
@g-bougard g-bougard removed the bug Something isn't working label Jan 22, 2025
@g-bougard
Copy link
Member

Hi @eduardomozart

Do a ESX inventory.

Please, tell us how you run the inventory. This is too vague. You have to be accurate in you problem description.

Expected behavior

A new agent shouldn't be created when inventoring ESX hosts.

Well, this sentence is just a point of view. And this point of view is yours.

Since the beginning of the agent (and I wasn't there when the parent project was initiated: I mean the beginning of FusionInventory project), it was decided agent has to report a "deviceid" in any inventory, even if its a fake "deviceid". And indeed, since we implemented RemoteInventory task, it can even more be a faked "deviceid". And indeed it was still a faked one with the ESX task which was the really first remote inventory task.

In that case, maybe GLPI should not create an agent, but the rule actually is it creates an agent for any new "devicedid". This is just a rule of simplicity. And one fact is, we don't have to care about agents. Agents is just a convenient concept. It permits essentially to identify where was created an inventory, but it is actually useless in the case of a remote inventory. In GLPI, we prefer to keep "deviceid" concept as "agent" even if it's not really useful for the asset.

To be honest, to me the "agent" concept in glpi is only useful for tasks management. I can admit we are doing wrong in glpi and in glpi-agent, but we probably have inherited a misuse at the base from the FusionInventory project. And I don't think this will be changed in the future unless we discover it's really a problem for assets management. So, please, just don't care about "agents" and just take them as assets data.

I'll migrate this issue as a discussion as this is not really an issue. So if you want to comment that misconception on agent usage, you can.

@glpi-project glpi-project locked and limited conversation to collaborators Jan 22, 2025
@g-bougard g-bougard converted this issue into discussion #832 Jan 22, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants