Agent GLPI



Où puis-je télécharger l'agent GLPI ?

L'agent est disponible via cette URL


Quelle URL dois-je configurer sur mon agent ?

Vous pouvez vous référer à la documentation en ligne pour configurer correctement votre agent.


Quels systèmes d'exploitation sont compatibles avec l'agent GLPI ?

  • Windows

  • MacOSX (Intel et Apple Silicon)

  • GNU/Linux (principales distributions et celles basées sur RPM et DEB ou supportant Snap)

Voici la documentation pour installer l'agent sur vos différents OS.


Comment installer l'agent via GPO ?

Un script est disponible pour déployer vos agents via GPO


Qu'est-ce que Glpi-Agent Monitor ?

Glpi-Agent Monitor vous permet d'avoir une interface graphique de votre agent afin de réaliser des actions comme forcer un inventaire, consulter le log de l'agent, ouvrir un ticket. Vous pouvez le télécharger ici lien

Alt text

Comment installer l'agent sur MacOSX ?

Pour vous aider à installer l'agent GLPI sur MacOSX, vous pouvez consulter la documentation officielle


Comment installer l'agent sur GNU/Linux ?

Pour vous aider à installer l'agent GLPI sur GNU/Linux, veuillez consulter la documentation officielle


Où trouver le fichier de configuration de l'agent ?

  • Sous GNU/Linux : /etc/glpi-agent/agent.cfg

  • Sous MacOSX : /Applications/GLPI-Agent/etc/agent.cfg

  • Sous Windows : dans le registre à HKEY_LOCAL_MACHINE\SOFTWARE\GLPI-Agent


Quels paramètres sont disponibles dans le fichier de configuration de l'agent ?

L'agent GLPI inclut de nombreux paramètres comme l'installation de tâches particulières, l'activation du SSL, l'utilisation de mots de passe pour l'authentification HTTP sur le serveur, etc. Vous trouverez la liste complète ici


Comment forcer un inventaire ?

Windows :

  • Si l'agent est installé en tant que service, rendez-vous sur http://hostname:62354 et forcer un inventaire

  • Si Glpi-Agent Monitor est installé, vous pouvez lancer l'inventaire directement depuis l'interface de monitoring.

  • Par CLI :

      C:\> cd "C:\Program files\GLPI-Agent" "C:\Program files\GLPI-Agent
      C:\Program filesGLPI-Agent > glpi-agent --force

MacOSX :

sudo /Applications/GLPI-Agent.app/bin/glpi-agent --force

GNU/Linux et autres

sudo glpi-agent --force


Quelles tâches sont supportées par l'agent ?

L'agent supporte un certain nombre de tâches, dont certaines peuvent être configurées depuis le plugin GlpiInventory disponible sur la MarketPlace :


Comment activer l'authentification Basic vers GLPI Agent ?

Depuis le dossier de configuration de l'agent, identifiez le fichier basic-authentication-server-plugin.cfg. Copiez ce fichier et renommez l'extension en .local. Dans le fichier renommé, décommentez la ligne disabled = no. Plus d'informations dans la documentation officielle


À quoi sert la Toolbox ?

La ToolBox est une interface web simple intégrée à l'agent GLPI qui permet de configurer certaines fonctionnalités lorsqu'aucun serveur GLPI n'est disponible.


Quelles sont les fonctionnalités de la Toolbox ?

Voici les principales fonctionnalités offertes par la ToolBox :

  • Gérer les tâches d'inventaire (disponible depuis GLPI Agent 1.6)

  • Gérer les informations d'authentification

  • Gérer les définitions de plages IP

  • Gérer les définitions de planification (disponible à partir de GLPI Agent 1.6)

  • Afficher les résultats d'inventaire léger et modifier les champs personnalisés si besoin

  • Gérer les définitions de remotes (obsolète depuis GLPI Agent 1.6)

  • Gérer les règles de support mib pour ajuster les résultats des équipements réseau SNMP


Comment installer la ToolBox de l'agent ?

La ToolBox de l'agent GLPI est un module de l'agent GLPI qui peut être activé en suivant cet article.


Comment configurer mon agent pour accéder à mon serveur GLPI en SSL ?

La première chose à vérifier est que vous utilisez une URL commençant par https://. Si votre serveur GLPI est correctement configuré et possède un certificat signé par une autorité de certification publique, vous n'aurez rien d'autre à faire. Ensuite, vérifiez que votre réseau ne bloque pas les requêtes vers le port 443 de votre serveur GLPI depuis le poste où l'agent doit être exécuté. Enfin, vous pouvez consulter le log de l'agent ou vérifier que la sortie d'une exécution en ligne de commande ne rapporte pas une erreur comme celle-ci :

[error] [http client] internal response: 500 Can't connect to 192.168.2.3:443 (certificate verify failed), SSL connect attempt failed error:0A000086:SSL routines::certificate verify failed
[error] No supported answer from server at https://192.168.2.3

Le mot-clé ici est certificate verify failed. Dans ce cas, la configuration du support SSL du serveur GLPI peut utiliser une autorité de certification privée. C'est le cas, par exemple, si votre GLPI est configuré avec un certificat auto-signé. Dans ce cas, l'agent dispose de plusieurs options pour configurer le support SSL et chacune de ces options peut être choisie selon le contexte d'utilisation. Mais avant d'aller plus loin, vérifiez aussi qu'un antivirus n'est pas configuré sur l'ordinateur pour intercepter les flux réseau SSL. Dans ce cas, l'antivirus présente généralement un certificat privé auto-signé, ce qui est responsable de l'erreur. Consultez la documentation de votre antivirus pour savoir comment résoudre ce problème, peut-être en incluant l'URL du serveur GLPI dans une liste blanche. La première option que vous pouvez utiliser est l'option no-ssl-check. Cette option doit être utilisée pour vérifier que le support SSL fonctionne bien. Cependant, cette option ne doit jamais être utilisée en production car elle n'authentifie pas votre serveur GLPI. L'option no-ssl-check permettra aussi à l'agent d'indiquer la valeur que vous pouvez utiliser pour une autre option disponible depuis la version 1.3 de l'agent GLPI : l'option ssl-fingerprint. Voici un exemple d'information que l'agent peut rapporter avec l'option no-ssl-check activée :

[info] [http client] SSL Client warning: Peer certificate not verified
[info] [http client] SSL Client info: Cert-Issuer: '/CN=debian-hosting', Cert-Subject: '/CN=debian-hosting', Version: 'TLSv1_3', Cipher: 'TLS_AES_256_GCM_SHA384'
[info] [http client] SSL server certificate fingerprint: sha256$bae02f72f312d6bc4e6f358181a7beb319224e242b8e370d49a60f659c4a589f
[info] [http client] You can set it in conf as 'ssl-fingerprint' and disable 'no-ssl-check' option to trust that server certificate

Dans cet exemple, la ligne SSL server certificate fingerprint: indique que vous pouvez configurer l'option ssl-fingerprint avec la valeur sha256$bae02f72f312d6bc4e6f358181a7beb319224e242b8e370d49a60f659c4a589f. Cette valeur peut alors être configurée sur tous vos agents pour qu'ils reconnaissent votre serveur GLPI. Notez que vos agents devront être reconfigurés avec une nouvelle empreinte de certificat SSL si le certificat présenté par le serveur est mis à jour. Alternativement, la méthode historique pour configurer la reconnaissance du certificat SSL présenté par le serveur GLPI est de configurer l'option ca-cert-file avec le chemin vers un fichier au format PEM contenant soit le certificat public présenté par le serveur, soit le certificat public de l'autorité ayant signé le certificat présenté par le serveur. L'inconvénient de cette option est qu'il faudra créer ou copier ce fichier sur toutes les machines qui en ont besoin. L'option ca-cert-dir peut aussi être utilisée, mais sa mise en œuvre est plus complexe car il n'est pas facile de déterminer le nom de fichier des certificats que le dossier configuré doit contenir. Depuis la version 1.3 de l'agent GLPI sur Windows et MacOSX, l'agent essaiera aussi de vérifier s'il trouve le certificat du serveur dans le magasin de certificats système sur Windows ou dans le trousseau sur MacOSX. Comme demandé par la communauté, depuis l'agent 1.5, l'agent reconnaît plusieurs autres sections du magasin de certificats sur Windows. Cette fonctionnalité peut vous permettre de simplifier l'authentification SSL du serveur GLPI sur un grand parc, car il suffira de déployer automatiquement le magasin de certificats sans avoir à utiliser d'option spécifique dans l'agent. De plus, si le certificat du serveur GLPI est mis à jour, il suffira de déployer le nouveau certificat et les agents finiront par l'utiliser sans intervention de votre part.


Comment diagnostiquer un problème de connexion SSL ?

Si vous n'arrivez pas à configurer l'authentification SSL du serveur, vous pouvez utiliser l'option --debug deux fois combinée à l'option --logger=stderr lors de l'exécution de l'agent en ligne de commande pour obtenir un diagnostic plus complet du support SSL. Cela vous aidera probablement à identifier un problème particulier et on vous demandera toujours la sortie si vous demandez de l'aide.

Vous devez exécuter la commande depuis une console administrateur et il est préférable d'utiliser des options qui forcent l'exécution et limitent les tâches à une seule, dans ce cas la tâche Collect. Le seul but est de diagnostiquer un problème de communication SSL avec le serveur GLPI : glpi-agent --logger=stderr --debug --debug --tasks=collect --force

Voici à quoi peut ressembler la sortie :

DEBUG: .../IO/Socket/SSL.pm:846: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:3690: * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8)
DEBUG: .../IO/Socket/SSL.pm:3690: * TLSv1.3 (IN), TLS handshake, Certificate (11)
DEBUG: .../IO/Socket/SSL.pm:2857: ok=0 [0] /CN=debian-hosting/CN=debian-hosting
DEBUG: .../IO/Socket/SSL.pm:3690: * TLSv1.3 (OUT), TLS alert, Unknown alert (560)
DEBUG: .../IO/Socket/SSL.pm:849: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:852: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:852: local error: SSL connect attempt failed error:0A000086:SSL routines::certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:855: fatal SSL error: SSL connect attempt failed error:0A000086:SSL routines::certificate verify failed
DEBUG: ...perl/Net/HTTPS.pm:67: ignoring less severe local error 'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed error:0A000086:SSL routines::certificate verify failed'
DEBUG: .../IO/Socket/SSL.pm:3062: free ctx 94133007189808 open=94133007189808
DEBUG: .../IO/Socket/SSL.pm:3066: free ctx 94133007189808 callback
DEBUG: .../IO/Socket/SSL.pm:3073: OK free ctx 94133007189808
[error] [http client] internal response: 500 Can't connect to 192.168.2.3:443 (No such file or directory), SSL connect attempt failed error:0A000086:SSL routines::certificate verify failed
[error] No supported answer from server at https://192.168.2.3

On retrouve ici une ligne contenant ok=0 [0] /CN=debian-hosting/CN=debian-hosting qui montre que le certificat serveur est un certificat auto-signé avec un nom d'hôte debian-hosting et une erreur SSL fatale indiquant certificate verify failed. En conclusion, l'agent refuse la connexion car il n'arrive pas à authentifier le serveur auquel il accède. Et c'est normal lors de l'utilisation d'une url contenant une IP. Ce type d'erreur peut être résolu en utilisant l'une des options de configuration de l'agent. D'autres erreurs peuvent cependant apparaître, indiquant par exemple que le support SSL du serveur est obsolète ou que la négociation du protocole d'échange n'a pas abouti. Ce type d'erreur peut indiquer un problème à résoudre côté serveur.


Pourquoi mon agent affiche-t-il un statut inconnu ou une demande d'inventaire ?

Par défaut, le statut de l'agent est affiché comme inconnu. Vous pouvez cliquer sur :

  • view the status

  • launch an inventory

Alt text

Il peut arriver que le serveur n'ait pas accès au port de l'agent ; dans ce cas, cette fonctionnalité ne sera pas disponible :

  • si l'agent est derrière un pare-feu

  • si le routage ne le permet pas

  • si le port est filtré par le pare-feu de la machine


Comment puis-je ajouter les tâches collect et deploy via un script VBS ?

Annoncé avec la sortie de l'agent 1.8, les tâches de déploiement et de collecte ne sont plus installées par défaut. Elles doivent être ajoutées à vos scripts si vous souhaitez les installer. Voici la syntaxe à suivre :

SetupOptions = "/quiet RUNNOW=1 ADDLOCAL=feat_DEPLOY,feat_COLLECT SERVER='' TASKS='Deploy,Collect,Inventory,...


Qu'est-ce qu'un inventaire partiel ?

Un inventaire partiel inclut uniquement les informations qui ont été modifiées lors de l'inventaire précédent ou qui ont été demandées par configuration ou option.

Cela réduit la charge sur le serveur GLPI et le réseau lors de l'importation de l'inventaire.


Pourquoi l'agent génère-t-il un inventaire partiel ?

L'agent GLPI (depuis la version 1.8) générera, par défaut, un inventaire partiel après un inventaire complet initial. Nous avons ajouté une fonction pour reporter l'inventaire complet afin de réduire la charge sur le serveur GLPI et le réseau. Dans ce cas, s'il n'est pas temps de générer un inventaire complet, l'agent GLPI supprimera les catégories d'inventaire qui n'ont pas changé depuis le dernier inventaire et ajoutera un champ "partial": true dans l'inventaire JSON.

Et dans ce cas, à la fin de 14 inventaires partiels (la valeur par défaut de full-inventory-postpone) envoyés, l'agent GLPI finira par envoyer un inventaire complet.


Pourquoi mes règles d'attribution d'entité ne sont-elles pas appliquées ?

Il peut arriver que le transfert de matériel soit autorisé d'une entité à une autre (Administration > Entité > mon_entité > Actifs > Transfert) et que l'agent GLPI génère un inventaire partiel.

Pendant un inventaire partiel, il est possible que les informations requises par vos règles ne soient pas incluses dans l'inventaire, notamment si vous avez besoin d'informations IP et de masque réseau (CIDR) (dans un inventaire partiel, l'absence d'une section indique qu'aucun changement n'a eu lieu depuis l'inventaire précédent).

Cela peut donc avoir une influence si vous avez des règles d'affectation de matériel à une entité par IP et/ou et que le transfert d'entité est autorisé. Le matériel concerné pourrait être transféré vers l'entité racine, contournant ainsi les règles d'affectation de matériel.

Il existe deux manières de corriger ce problème : forcer l'agent à générer des inventaires complets, ou continuer avec des inventaires partiels mais forcer le transfert de la partie réseau.

Information

Dans le 2ème cas, vous devrez installer l'agent GLPI 1.13 ou une version supérieure.

Forcer l'inventaire à être complet :

full-inventory-postpone=0

  • Inventaire partiel avec retour d'information du réseau :

Dans la configuration de l'agent, indiquer :

required-category=network

full-inventory-postpone=14 (default value)

Vous pouvez également tester les options en ajoutant :

glpi-agent --full-inventory-postpone=14 --required-category=network


Comment puis-je forcer mes agents à toujours générer un inventaire complet ?

Dans la configuration de l'agent, indiquer :

full-inventory-postpone=0

Last updated

Was this helpful?