GLPI-Agent do not send CONTACT on first inventory

[eduardomozart]

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

Hello @g-bougard, here I'm again. =D
I noticed that when using /RUNNOW, running the GLPI-Agent Monitor to force inventory the first time or installing the agent and wait the next-run (first run), the Supported Tasks section of the agent isn't filled, as can be seen below:

I believe it happens because the

glpi-agent/lib/GLPI/Agent.pm

Line 218 in c3fd510

if ($target->isGlpiServer()) {

returns false which make the PROLOG call not be made and the Supported tasks not be reported to GLPI server on the first GLPI-Agent run.

It can become an issue because on glpi-project/glpi-inventory-plugin#627 the GLPI-Inventory plugin also checks the Supported tasks reported by GLPI-Agent (now the use_module* columns of agent is checked on isAgentCanDo() PHP function call). You can see on the glpi-agent.log files (in attachment) it returns a "400" HTTP error when attempting to retrieve the "Deploy" and "Collect" tasks the first time GLPI-Agent runs and it may happen because the GLPI server do not send tasks (e.g. Deploy or Collect tasks) to agents that doesn't supports it. If the PR glpi-project/glpi-inventory-plugin#603 be approved as it is it will not show those agents on taskjob dropdown until a second inventory task is run, which may lead the users to be confused about "the agent is shown on GLPI but not on the taskjob dropdown" kind of issues.

To reproduce

1. Uninstall the GLPI-Agent on the client operating system (if it exists)
2. Delete agent and computer asset of the agent on GLPI-server (if it exists).
3. Install/Reinstall the GLPI-Agent.
4. Do the first inventory.
5. Supported tasks from GLPI isn't updated to reflect the tasks supported by GLPI-Agent installed on the client operating system.

Expected behavior

Supported tasks from GLPI is updated to reflect the tasks supported by GLPI-Agent installed on the client operating system.

Operating system

Windows

GLPI Agent version

v1.12

GLPI version

GLPI 10.0.18-dev (Nightly Build)

GLPIInventory plugin or other plugin version

GLPI Inventory v1.4.0

Additional context

I tried to change

glpi-agent/lib/GLPI/Agent.pm

Line 218 in c3fd510

if ($target->isGlpiServer()) {

to if ($target->isGlpiServer()) { but the GLPI server returns a 404 error and GLPI-Agent returns No supported answer from server at https://glpi.example.com/plugins/glpiinventory (glpi-agent-1st-force-glpiserver.log), so I believe this PR may requires changes on GLPI Core to accept those kind of requests if the Agent doesn't exists yet OR a modification be made on GLPI-Agent itself to run CONTACT again if target has been identified as isGlpiServer after inventory (so the GLPI server would accept the request and fill the Supported Tasks section of agent on GLPI server).

glpi-agent.log files (Debug level = 2):

glpi-agent-1st-run.log
glpi-agent-2nd-run.log

glpi-agent-1st-next-run.log

glpi-agent-1st-force-glpiserver.log

[g-bougard]

Hi @eduardomozart

we were more or less aware of a latency here. And yes, we estimated this wasn't a big deal. The most important for us was to still support servers older than GLPI 10 so they can migrate to GLPI-Agent before updating GLPI server.

Just to be clear semantically and accurate, we name PROLOG request the legacy XML request, and this one is indeed the first one which is sent to an unknown server. We name CONTACT the JSON request which is used to tell GLPI 10 which tasks are installed agent-side. And you are indeed speaking about this CONTACT request.

My guess is glpi-agent should also send the CONTACT request after the PROLOG if it obtains a JSON answer on it. I'll try something this way.

[g-bougard]

Hi @eduardomozart

I finally pushed an update to fix the problem you reported. I had to rework at the same time the event handling.

You should be able to validate the fix with next nighty build.