# Agent GLPI *** {% hint style="danger" %} **La Toolbox est réservée à un usage avancé. Pour inventorier vos imprimantes et matériels réseau, veuillez utiliser cette** [**procédure**](https://app.gitbook.com/s/qmRzI15ndDbFHGd5BnM4/inventory/snmp_inventory) {% endhint %} {% embed url="" %} *** ### Où puis-je télécharger l'agent GLPI ? L'agent est disponible via cette [URL](https://github.com/glpi-project/glpi-agent/releases/) *** ### Quelle URL dois-je configurer sur mon agent ? L'URL à saisir se trouve dans **`Configuration`** > **`Générale`** > **`Configuration Générale`** > **`URL de l'application`** * **`https://my_instance.com/`** Vous pouvez vous référer à la [documentation en ligne](https://glpi-agent.readthedocs.io/en/latest/configuration.html#available-parameters) 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](https://glpi-agent.readthedocs.io/en/latest/installation/index.html) 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](https://glpi-agent.readthedocs.io/en/latest/installation/index.html#large-installations) *** ### 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](https://github.com/glpi-project/glpi-agentmonitor/releases)
Alt text
*** ### Comment installer l'agent sur MacOSX ? Pour vous aider à installer l'agent GLPI sur MacOSX, vous pouvez consulter la [documentation officielle](https://glpi-agent.readthedocs.io/en/latest/installation/index.html#macos) *** ### Comment installer l'agent sur GNU/Linux ? Pour vous aider à installer l'agent GLPI sur GNU/Linux, veuillez consulter la [documentation officielle](https://glpi-agent.readthedocs.io/en/latest/installation/index.html#gnu-linux) *** ### 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](https://glpi-agent.readthedocs.io/en/latest/configuration.html#available-parameters) *** ### 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**](https://github.com/glpi-project/glpi-agentmonitor/releases) 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 : * Netinventory et NetDiscovery : découverte réseau et inventaire avec support SNMP * Deploy * Collect * ESX * RemoteInventory (uniquement avec une [configuration dédiée dans GLPI Agent](https://glpi-agent.readthedocs.io/en/latest/tasks/remote-inventory.html) ou avec le [plugin GLPI Agent ToolBox](https://glpi-agent.readthedocs.io/en/latest/plugins/toolbox-plugin.html)) *** ### 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](https://glpi-agent.readthedocs.io/en/latest/plugins/basic-authentication-server-plugin.html#basic-authentication-server-plugin) *** ### À 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](https://app.gitbook.com/s/qmRzI15ndDbFHGd5BnM4/inventory/advanced-usage/install-agent-toolbox). *** ### 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](https://3914205414-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FVU1qbB9Oe25HAYDAQ4tR%2Fuploads%2Fgit-blob-98ddc219b6a74d7b558ab176b43493edfdff4f9c%2Fagent-4.gif?alt=media) 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 {% hint style="danger" %} **Cette fonctionnalité n'est pas disponible en Cloud** {% endhint %} *** ### 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='`**[**`https:my_GLPI_instance/marketplace/glpiinventory/`**](#user-content-fn-1)[^1]**`' 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 [CIDR ](#user-content-fn-2)[^2]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. {% hint style="info" %} **Information** Dans le 2ème cas, vous devrez installer l'agent GLPI 1.13 ou une version supérieure. {% endhint %} Forcer l'inventaire à être complet : * Dans la [configuration de l'agent](https://glpi-agent.readthedocs.io/en/latest/configuration.html#required-category), indiquer : `full-inventory-postpone=0` * Inventaire partiel avec retour d'information du réseau : Dans la [configuration de l'agent](https://glpi-agent.readthedocs.io/en/latest/configuration.html#required-category), 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 ? {% hint style="warning" %} **Attention** Selon la taille de votre parc, cela peut augmenter la charge du réseau et celle du serveur GLPI. {% endhint %} Dans la [configuration de l'agent](https://glpi-agent.readthedocs.io/en/latest/configuration.html#required-category), indiquer : `full-inventory-postpone=0` [^1]: :man\_raising\_hand: To be modified by the URL of your instance [^2]: Classless Inter-Domain Routing