je suis en train de mettre en place une communication SSL entre mon serveur GLPI et les Agents Fusion Inventory.
Mon GLPI tourne sur un serveur Windows 2019 IIS.
J'ai mis en place un binding pour ma connexion Fusion Inventory sur lequel j'utlise un self signed certificat.
I'm running GLPI 9.5.1 with the latest FusionInventory version and agent version 2.5.2 and am seeing random kernel panic and restarts on a few machines. This is only 8 out of an estate of 1600 so I was wondering if anyone had seen this happen before? The machines are running the same configuration and updates as the others with no changes made specifically to these machines. The crashes only seem to occur when the machine connects to the GLPI server to run an inventory, the agent runs fine on the machine without causing any issues when not checking in with the server, as soon as data collection starts on the machine it immediately crashes and restarts. Running an strace didn't find anything to link to the agent but every time an inventory runs these 8 systems will crash if the fusion agent is enabled. Machines are Fujitsu C740's running CentOS7.
Has anyone seen this behaviour before?
Below is an example of what happens when the machine runs an inventory.
j'aimerais pouvoir faire remonter tout les pc de mon entreprise sur la base de données GLPI (environ 400 postes) de manières automatiques.
CEPENDANT
On n'a pas accès au GPO, AD etc... (gérer en allemagne...)
Et en créant un .bat qui télécharge l'agent /exécute, il demande les droits admin en moment de l’installe de l'agent ... Et de plus impossible a déployer car sans accès au gpo et impossible de vérifier si tout le monde à bel est bien executez le script
Donc voici ma question :
Existe t-il un moyen de "scanner" tout le réseau de l'entreprise et le faire remonter sur glpi directement ?
Bonus si tout peut se faire de manière silencieuse
Hello, FusionInventory is collecting a license on the computer that has already been removed, both via the system and via regedit, is the Office 2013 license in a specific Windows location? I need to remove it because it is no longer installed
Je vais participer, l'été prochain, au raid Paris-Pékin-Istanbul en Camping-car. Aussi, j'ai créé un blog sur WordPress pour communiquer avec la famille, les amis et plus largement ceux qui s'intéressent à ce périple.
Je souhaiterais savoir comment accéder à mon blog depuis la Chine pour le mettre à jour. En France, j'utilise Chrome...
Est-ce Baidou la solution ? si oui, puis-je le télécharger depuis la France et le tester avant de partir ?
Nous serons pendant 4 semaines sur le territoire chinois et cela m'ennuierai de ne pouvoir faire la mise à jour au fur-et-à-mesure.
Merci d'avance pour votre aide et/ou votre partage d'expérience.
Je rencontre le problème déjà décrit en 2015 dans le post 2731 pour lequel aucune solution n’avait été donnée à l’époque :
Lorsqu’un agent remonte l'inventaire, les champs avec verrous (« Type », « Modèle », « numéro d’inventaire » dans mon cas) ne sont pas mis à jour. Parfait !
Mais lorsque ultérieurement la fiche du PC est modifiée manuellement (changement du "Statut" par exemple), les champs verrouillés « Type », « Modèle », « numéro d’inventaire » se remplissent avec les données de l'agent et écrasent donc les données attribuées par notre gestionnaire de parc.
Agents windows 2.5.2 sur ~250 pc (plusieurs réseaux / clients différents)
Eset endpoint entreprise / nod32 sur pas mal de postes.
J'ai remarqué depuis 15 jours que certaines machines ne remontaient plus rien via fusioninventory. Et pire, plus de deploiement possible... Aucun dialoque entre la station et le serveur.
Et dans le log :
Code:
[error] [http client] communication error: 500 Can't connect to support.xxxxx.xom:443 (Bad file descriptor)
Alors que bien entendu l'url est accessible sans aucun souci à la main. Après pas mal de recherches et de tests, j'ai une explication :
Dans une de ses dernières mise à jour Eset / nod32 antivirus force l'inspection ssl de tous les flux et insère dans le système un certificat racine qui permet une inspection profonde.
- Si on désactive manuellement dans la conf intellection ssl, tout rentre dans l'ordre sur fusioninventory/glpi
- si on intègre "C:\Program Files\FusionInventory-Agent\perl\bin\fusioninventory-agent.exe" dans les exceptions de Eset, tout passe aussi normalement.
J'imagine que tous les systèmes de protection qui font de l'interception ssl vont poser le même genre de soucis. Et en ce moment, le bypass n'est pas vraiment une option.
Pour ma part heureusement certains clients sont géré via une console d'admin et la modif est poussée automatiquement.
Mais sur pas mal de postes isolés je suis bon pour le faire à la main, sauf s'il y a une solution générale de trouvée un jour ou l'autre.