• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Agent de déploiement qui reste toujours en maintenance
#1
Bonjour,

J'utilise le dernier patch FusionInventory for GLPI 9.4+2.0, 9.4+2.1 avec l'agent en 2.5.1. 

J'ai créé un package que je déploie ensuite via une tâche depuis GLPI, jusque là tout va bien. 
Le problème c'est que ma tâche reste toujours en statut Prepared et ne s'applique pas automatiquement. J'ai beau insisté, relancer le job sur le poste, rien n'y fait.

Le seul moyen pour qu'elle s'applique c'est que j'aille sur le poste cible et force un inventaire manuel sur l'adresse http://localhost:62354/. Là pas de souci, ma tâche est vue, s'exécute, magnifique. J'ai essayé en installant l'agent 2.5 même comportement. Sur un autre poste, idem. 

Côté log de l'agent, je vois que celui-ci reste continuellement en mode maintenance et ne semble pas être contacté par le serveur. J'ai installé l'agent en mode complet et en service Windows et j'utilise des postes en Windows 10.

J'ai vu que je n'étais pas la seule dans cette situation mais j'ai l'impression que les posts restent tous en suspend sans solution à la fin  Sad

Y a t'il une configuration que j'ai oublié côté serveur pour qu'il contact l'agent ?

Merci à tous pour votre aide
  Reply
#2
Il y a eu une correction, il faut installer la version 9.4+2.2 fraichement releasée.

On essaye de répondre à un maximum de messages pour information Wink
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#3
Merci beaucoup pour votre réponse. J'imagine bien que ce n'est pas simple à gérer, bon courage à vous et les équipes !

Malheureusement, j'ai installé la version 2.2 et je constate le même comportement entre mon agent et le serveur : pas de réactivité provenant du serveur lorsque que je crée et lance mon job mais le job se lance bien lorsque je fais un inventory.

J'ai réinstallé l'agent sur le poste, redémarrer GLPI, rien n'y fait, le serveur ne contact pas mon agent.

Y a t'il des versions plus "stable" que je puisse installé/testé ?

Merci beaucoup pour votre aide
  Reply
#4
A partir du serveur GLPI, si tu fais un telnet sur l'IP du poste sur le port 62354, ça répond?
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#5
(2019-12-02, 09:19:55)ddurieux Wrote: A partir du serveur GLPI, si tu fais un telnet sur l'IP du poste sur le port 62354, ça répond?
Malheureusement non et je n'ai pas vraiment d'explication car :
 > j'ai ouvert les ports de mon firewall et je vois bien le paquet passé, aucun drop
 > côté poste utilisateur le port 62354 est bien autorisé. Si je fais depuis le poste un "telnet localhost 62354" aucun problème 
 > j'ai désactivé l'antivirus
 > je n'ai rien dans les logs windows

Y a t'il une autorisation supplémentaire à rajouter sur le serveur GLPI pour autoriser le port à sortir ? Je ne vois pas d'autre point qui pourrait être bloquant  Sad
  Reply
#6
Pour une raison qui m'échappe, le job s'est exécuté de lui même cette nuit à 0:36 sur mon poste. Si je regarde les logs de l'agent j'ai ceci : 

[Thu Dec  5 00:36:01 2019][debug] Agent memory usage before freeing memory: WSS=121827328 PFU=148000768
[Thu Dec  5 00:36:01 2019][info] FusionInventory Agent memory usage: WSS=2908160 PFU=148000768
[Thu Dec  5 00:36:47 2019][info] target server0: server http://MONSERVEURGLPI/plugins/fusioninventory
[Thu Dec  5 00:36:48 2019][debug] [http client] Using Compress::Zlib for compression
[Thu Dec  5 00:36:48 2019][info] sending prolog request to server0
[Thu Dec  5 00:36:48 2019][debug2] [http client] sending message:
<?xml version="1.0" encoding="UTF-8" ?>
<REQUEST>
  <DEVICEID>MONPOSTE</DEVICEID>
  <QUERY>PROLOG</QUERY>
  <TOKEN>12345678</TOKEN>
</REQUEST>
[Thu Dec  5 00:36:48 2019][debug2] format: Zlib
[Thu Dec  5 00:36:48 2019][debug2] [http client] receiving message:
<?xml version="1.0" encoding="UTF-8"?>
<REPLY>
  <RESPONSE>SEND</RESPONSE>
  <PROLOG_FREQ>24</PROLOG_FREQ>
</REPLY>

[Thu Dec  5 00:36:48 2019][debug] new thread 340 to handle task NetDiscovery
[Thu Dec  5 00:36:48 2019][debug] NetDiscovery task execution not requested
[Thu Dec  5 00:36:48 2019][debug] new thread 341 to handle task WMI
[Thu Dec  5 00:36:49 2019][debug] new thread 342 to handle task Deploy


Je vous passe la suite qui est le déploiement de mon job et l'inventaire de mon poste. 

Je comprends que c'est mon poste qui a contacté le serveur ("sending prolog request to server0") mais je n'ai programmé aucun trigger à 0:36 ! Comment a t'il contacté de lui même le serveur ? Y aurait il moyen de mettre une tâche planifiée depuis le poste client qui s'exécute tous les jours pour contacter le serveur ? Cela pourrait répondre au final à mon besoin... 

Un élément que je n'ai pas présicé depuis le début mais le cron taskscheduler s'exécute très bien depuis le serveur GLPI toute les minutes.
  Reply
#7
Avec la configuration par défaut, à chaque exécution l'agent recalcule la prochaine exécution entre 12h et 24h
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#8
(2019-12-05, 20:58:23)ddurieux Wrote: Avec la configuration par défaut, à chaque exécution l'agent recalcule la prochaine exécution entre 12h et 24h

Est ce que je peux modifier un fichier pour forcer une exécution hebdomadaire à une heure précise ?
  Reply
#9
fais une requête web via une tache planifiée système sur : http://127.0.0.1:62354/now
Co-leader, official developper
DCS official PARTNER: dcs.glpi@dcsit-group.com
  Reply
#10
Thumbs Up 
On va partir là dessus.

Merci beaucoup pour ton aide  Big Grin
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)