Découverte réseau avec GLPI 0.85.4+1.3

sadnotrue · 2015-10-29 18:43:28

Bonjour,

J'ai déjà posté un message sur le sujet mais comme je n'ai pas eu de réponse (sauf de personne étant dans le même cas que moi Cf. http://forum.glpi-project.org/viewtopic.php?id=117366) j'en remonte un nouveau.

Dans le principe, j'ai suivi la doc pour l'installation de GLPI et du plugin fusion en paramétrant :
- L'agent.cfg,
- Affecté un agent pour la découverte
- Affecté une plage IP
- Un créneau horaire sans heure de fin...
- Création de la tâche
- ...

Mais rien de remonte, tous les compteurs restent à zéro et ça ne bouge pas.

J'ai testé X tuto, regardé un peu partout sur x forum et j'en reviens toujours au même point sans savoir ce qui coince.
Quand je fais une recherche par l'agent en ligne de commande il me ramène bien les infos...

Via Nagios je récupère bien les informations en SNMP de mes imprimantes qu'est-ce qui peut faire que ça ne fonctionne pas avec fusion ?
Les agents sur poste Linux et Windows remontent bien les informations et c'est nickel, mais pour les imprimantes et périphériques réseaux il n'y a rien à faire.

Pour information le serveur tourne sur Jessie, apache2 ...

Merci d'avance pour vos suggestions.

Sad

Last edited by sadnotrue (2015-10-29 18:48:18)

ZenAdm · 2015-10-30 18:32:46

Bonjour,

Est-ce que l'agent affecté à cette tâche est en mode DAEMON (Linux) ou service (Windows), afin qu'il vienne interroger le serveur et soit "au courant" qu'il a un inventaire à faire ?

sadnotrue · 2015-10-30 19:07:43

Bonjour ZenAdm,

Merci pour ta réponse, l'agent est bien en mode Daemon sur Linux.
Je l'ai même démarrer manuellement au cas ou...

mais lorsque je vérifie il me dit qu'il n'y aura aucune tâche démarrer :

root@MonServeur:/# fusioninventory-agent start
[debug] FusionInventory Agent (2.3.13)
[debug] Configuration directory: /usr/local/etc/fusioninventory
[debug] Data directory: /usr/local/share/fusioninventory
[debug] Storage directory: /usr/local/var/fusioninventory
[debug] Lib directory: /usr/local/share/fusioninventory/lib
[debug] [target server0] Next server contact planned for Thu Oct 29 15:41:43 2015
[debug] Available tasks:
[debug] - NetDiscovery: 2.2.0
[debug] - NetInventory: 2.2.0
[debug] - Deploy: 2.0.4
[debug] - Inventory: 1.0
[debug] - WakeOnLan: 2.0
[debug] - ESX: 2.2.1
[debug] [http client] Using Compress::Zlib for compression
[info] sending prolog request to server server0
[debug] NetDiscovery task execution not requested
[debug] NetInventory task execution not requested
[info] running task Inventory
[debug] Running FusionInventory::Agent::Task::Inventory::AccessLog
[debug] Running FusionInventory::Agent::Task::Inventory::Generic
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Arch
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Dmidecode
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Dmidecode::Battery
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Dmidecode::Bios
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Dmidecode::Memory
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Dmidecode::Ports
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Dmidecode::Slots
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Domains
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Environment
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Hostname
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::PCI
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::PCI::Controllers
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::PCI::Modems
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::PCI::Sounds
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Printers
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Processes
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::SSH
[debug] Running FusionInventory::Agent::Task::Inventory::Generic::Screen
....

sadnotrue · 2015-11-02 11:10:39

Petite évolution, merci ZenAdm de m'avoir mis sur la voie, effectivement, j'ai forcé le démarrage de la tâche.

Le daemon n'avait pas l'air de fonctionner normalement, j'ai modifié le fichier /etc/default/fusioninventory-agent et j'ai remis le mode CRON au lieu de DAEMON.

J'ai ensuite executé cette commande :

/usr/bin/php5 /var/www/glpi/front/cron.php &>/dev/null

J'ai relancé l'agent et magie magie ..!
La tâche qui est passé à 1 et prépare à 1.
Reste à savoir quand elle va se lancer...
Ca fait 1h30 et rien n'a bougé... J'ai peur...

ZenAdm · 2015-11-02 15:00:04

Bonne nouvelle !
Je vois que tu utilises l'agent 2.3.13, n'hésite pas à passer sur une version plus récente. La dernière sortie est la 2.3.17, et quand j'utilise les dépôts de Fusioninventory pour mon Ubuntu 14.04, ça m'installe la version 2.3.16 actuellement.

sadnotrue · 2015-11-03 12:56:59

Merci pour ton retour.

Ok c'est installé, par contre chose bizarre et c'est là où je ne comprends pas le système :
Mes imprimantes sont bien remonté lorsque j'ai forcé le démarrage de l'inventaire avec la commande fusioninventory-agent (Donc forcé manuellement)

J'ai du coup recréé deux autres tâches pour les remontés SNMP des imprimantes découvertes et une tâche pour la découverte des équipements réseaux.
Et bah tout reste à zéro encore une fois...
Je craque...

J'ai testé le démarrage avec daemon plutôt que cron pour voir et ça n'a pas l'air de changer beaucoup...
Au niveau de l'agent.cfg j'ai positionné ces informations :

server = http://IP du serveur/glpi/plugins/fusioninventory/

# disable embedded web server
no-httpd = 0
# network interface to listen to
httpd-ip = ip du serveur
# network port to listen to
httpd-port = 62354
# trust requests without authentication token
httpd-trust = 127.0.0.1

et lorsque j'execute l'agent, j'obtiens ça :

[debug] WakeOnLan task execution not requested
[debug] NetInventory task execution not requested
[debug] NetDiscovery task execution not requested
[info] running task Collect
[debug] Inventory task execution not requested, but execution forced
[info] running task Inventory
[info] running task ESX
[info] ESX support disabled server side.
[info] running task Deploy

Je précise également et je ne comprends toujours pas la différence :
- Dans le menu configuration générale, module des agents, tout est activé et j'ai bien positionné l'agent du serveur en exclusion (terme que je trouve pas logique) et
- Dans le menu Gestion des agents / Modules des agents, tout est décoché. Si tout est activé dans la zone config générale il ne met pas à jour les options de que j'ai coché.

Une idée ?

ZenAdm · 2015-11-03 13:10:30

Ce que je vois rapidement : tu peux chercher du côté de

httpd-ip = ip du serveur

Comme c'est la configuration de l'agent, c'est l'adresse IP sur laquelle il écoute. Il vaut donc mieux la laisser vide (par défaut) afin que l'agent puisse écouter les requêtes sur toutes les cartes réseau du PC.

Si ça ne suffit pas, tu peux aussi ajouter l'IP du serveur à la rubrique "httpd-trust" :

httpd-trust = 127.0.0.1,ip du serveur

Personnellement, au niveau de la conf de l'agent, je touche juste à "server", "httpd-trust" et "tag", avec mes agents en mode "daemon" sous Linux et service sous Windows.

sadnotrue · 2015-11-03 13:46:38

Ok j'ai modifié les infos selon tes recommandations, j'ai redémarré l'agent et le service mais pour le moment ça change pas beaucoup :_\

Last edited by sadnotrue (2015-11-03 13:46:50)

sadnotrue · 2015-11-04 10:05:25

Ok j'ai compris ce qui n'allait pas, la tache taskscheduler ne se lance pas automatiquement malgré le fait que la configuration soit donnée comme ceci :
Fréquence d'execution : 1 minute
Statut : Programmé
Mode d'execution : CLI
Plage horaire d'execution : 0 - 24

Ma question, comment ça se fait qu'elle ne démarre pas automatiquement ?

LaDenrée · 2015-11-04 10:25:42

Bonjour,
en mode cli, il faut une entrée dans la crontab pour déclecnher périodiquement les actions automatiques.

un truc du style */5 * * * * /usr/bin/php5 /var/www/glpi/front/cron.php &>/dev/null

sadnotrue · 2015-11-04 11:07:17

Bonjour LaDenrée,
Merci pour ton retour, je vais "retester" parce que j'ai déjà vu ça sur le forum et je l'avais déjà mis en place sans que ça change quoi que se soit :_\
Je vais creuser de ce côté merci pour la piste.

En tout cas, les remontés d'imprimantes ont bien fonctionné, aussi bien pour la partie découverte que la partie SNMP.
Je vois la partie utilisation consommable dans la zone fusion snmp mais il n'y a rien côté cartouche. Est-ce normal ?

La partie réseau par contre, la tâche démarre bien mais en remonté malgré qu'il me mette un succès, j'obtiens toujours 0 en mise à jour.
j'ai pourtant bien le nmap en succes :

debug] creating 1 worker threads
[debug] [thread 20] creation
[debug] [thread 20] scanning 10.40.101.180:
[debug] [thread 20] - scanning 10.40.101.180 with nmap: success
[debug] [thread 20] - scanning 10.40.101.180 with netbios: success
[debug] [thread 20] scanning 10.40.101.181:
[debug] [thread 20] - scanning 10.40.101.181 with nmap: no result
[debug] [thread 20] - scanning 10.40.101.181 with netbios: no result
[debug] [thread 20] scanning 10.40.101.182:
[debug] [thread 20] - scanning 10.40.101.182 with nmap: success
[debug] [thread 20] - scanning 10.40.101.182 with netbios: success
[debug] [thread 20] scanning 10.40.101.183:
[debug] [thread 20] - scanning 10.40.101.183 with nmap: success
[debug] [thread 20] - scanning 10.40.101.183 with netbios: success
[debug] [thread 20] scanning 10.40.101.184:
[debug] [thread 20] - scanning 10.40.101.184 with nmap: success
[debug] [thread 20] - scanning 10.40.101.184 with netbios: success
[debug] [thread 20] scanning 10.40.101.185:
[debug] [thread 20] - scanning 10.40.101.185 with nmap: success
[debug] [thread 20] - scanning 10.40.101.185 with netbios: success
[debug] [thread 20] scanning 10.40.101.186: ...

Je farfouille mais je suis preneur de piste ; )

LaDenrée · 2015-11-04 11:11:55

ma proposition était uniquement en réponse à la question :

Ma question, comment ça se fait qu'elle ne démarre pas automatiquement

mais j'ai bien noté qu'il reste d'autres problèmes auxquels je n'ai pas la réponse.

sadnotrue · 2015-11-04 11:37:40

Oui mais c'est une très bonne piste merci

ngaillard · 2015-11-05 17:39:08

Bonjour,

sadnotrue, j'ai du mal à comprendre comment tu arrives à faire la découverte sans que l'action automatique taskscheduler ne fonctionne.

EDIT :
j'ai compris! ça ne fonctionne pas automatiquement et tu lances en ligne de commande le cron.
Perso, voici comment j'ai fait ma crontab

Voici mon exemple :

#je crois que j'ai créé une crontab spéciale pour le www-data
sudo crontab -u www-data -l
sudo crontab -u www-data -e

J'ai ajouté la première ligne

* * * * * /usr/bin/php5 /var/www/glpi/front/cron.php &>/dev/null
#sinon, tu peux remplacer par la commande suivante (sans le dièse bien sûr) si tu crois qu'il est possible que ça ne fonctionne pas à cause d'une erreur
#* * * * * /usr/bin/php5 /var/www/glpi/front/cron.php 2>/var/www/glpi/files/_log/crontab_line.log

Et ça au cas où

/etc/init.d/cron restart

Tu attends une petite minute, et tu vérifies si le crontab_line.log a été créé (si tu as mis la seconde ligne à la place), si oui, s'il y a une erreur, sinon que t'as dit le cron.log, et si tout vas bien, bah certainement, ton cron fonctionne désormais.

Last edited by ngaillard (2015-11-05 20:04:15)

sadnotrue · 2015-11-06 10:44:57

Bonjour ngaillard et merci de participer à cette discussion.

Lorsque LaDenrée m'a indiqué l'histore du cron je me suis penché sur la question et j'ai effectivement trouvé des infos.
J'ai donc bien fait la même chose que toi à l'exception près que je l'ai déclaré ainsi :

1 * * * * /usr/bin/php5 /var/www/glpi/front/cron.php &>/dev/null

Autre point, j'ai par contre zappé de redémarrer le service mais ça ne change rien au fait que le taskscheduler de redémarre pas
automatiquement.

J'ai également essayé ta méthode en remplaçant le 1 par * mais bon, je lui demande simplement de redémarrer toutes les minutes donc ça devrait fonctionner quand même.

Voilà ce que j'obtiens dans GLPI
Prochaine exécution Dès que possible(06-11-2015 09:18)

La tâche est censé se lancer toutes les minutes, il est 9h42... et elle a pas démarré .

Par contre avec le log, j'obtiens ça :
PHP Fatal error: Allowed memory size of 262144 bytes exhausted (tried to allocate 49152 bytes) in /var/www/glpi/inc/includes.php on line 142

Dans le php.ini la valeur memory_limit par défaut est bien de 128M et non 128MB.
Je cherche dans cette direction pour voir.

Merci encore pour ton aide.

Autre point, est-ce qu'il est possible que des switchs Dell ne puissent pas être inventorié (car non pris en compte) et si c'est bien le cas, peut-on rajouter les informations manquantes quelques part pour qu'ils puissent être pris en compte ?
Idem pour les cartouches d'imprimantes HP qui ne remontent pas. (même si j'ai déjà le niveau du toner restant ce qui est déjà bien).

sadnotrue · 2015-11-06 10:55:01

Effectivement c'était bien ça, dans le fichier /etc/php5/cli/php.ini la limite mémoire était à 32.
Je l'ai remonté et ça va beaucoup mieux.

C'est extra... Reste plus que les remontés des cartouches et des équipements réseaux...
Merci encore.

LaDenrée · 2015-11-06 11:16:22

arretez moi si je me trompe mais :
1 * * ***

signifie une fois par heure à la première minute 10:01 11:01 12:01 ....

pour toutes les minutes c'est */1 ****
non ?

quelqu'un pourrait confirmer ?

http://www.glpi-project.org/DOC/FR/glpi … skcli.html

orthagh · 2015-11-06 11:42:11

exactement.
ou sinon * * * * *

sadnotrue · 2015-11-06 12:43:40

Oui je confirme autant pour moi...

ngaillard · 2015-11-10 17:34:52

Une question bête, tu as bien activé les modules NetDiscovery et NetInventory dans la configuration de l'agent?
Je ne parle pas des configuration que l'on fait depuis l'interface de GLPI, mais bien à l'installation de ton agent.

sadnotrue · 2015-11-18 10:24:34

Bonjour ngaillard,

Mmmh je ne vois pas où ça se trouve, j'ai vérifié les fichiers de conf et lorsque je lance mes tâches il me dit bien que Netdiscovery tourne.

Sinon j'ai avancé sur le sujet, mes équipements réseaux montent bien lors de la découverte et pour la majorité se retrouve dans la zone équipement non géré.
La partie SNMP s'occupe du reste et ça fonctionne pour le moment plutôt bien.
Il n'y a que les cartouches d'imprimantes qui ne remontent pas... Je continu de fouiller.

Forum GLPI-Project

Announcement

#1 2015-10-29 18:43:28

Découverte réseau avec GLPI 0.85.4+1.3

#2 2015-10-30 18:32:46

Re: Découverte réseau avec GLPI 0.85.4+1.3

#3 2015-10-30 19:07:43

Re: Découverte réseau avec GLPI 0.85.4+1.3

#4 2015-11-02 11:10:39

Re: Découverte réseau avec GLPI 0.85.4+1.3

#5 2015-11-02 15:00:04

Re: Découverte réseau avec GLPI 0.85.4+1.3

#6 2015-11-03 12:56:59

Re: Découverte réseau avec GLPI 0.85.4+1.3

#7 2015-11-03 13:10:30

Re: Découverte réseau avec GLPI 0.85.4+1.3

#8 2015-11-03 13:46:38

Re: Découverte réseau avec GLPI 0.85.4+1.3

#9 2015-11-04 10:05:25

Re: Découverte réseau avec GLPI 0.85.4+1.3

#10 2015-11-04 10:25:42

Re: Découverte réseau avec GLPI 0.85.4+1.3

#11 2015-11-04 11:07:17

Re: Découverte réseau avec GLPI 0.85.4+1.3

#12 2015-11-04 11:11:55

Re: Découverte réseau avec GLPI 0.85.4+1.3

#13 2015-11-04 11:37:40

Re: Découverte réseau avec GLPI 0.85.4+1.3

#14 2015-11-05 17:39:08

Re: Découverte réseau avec GLPI 0.85.4+1.3

#15 2015-11-06 10:44:57

Re: Découverte réseau avec GLPI 0.85.4+1.3

#16 2015-11-06 10:55:01

Re: Découverte réseau avec GLPI 0.85.4+1.3

#17 2015-11-06 11:16:22

Re: Découverte réseau avec GLPI 0.85.4+1.3

#18 2015-11-06 11:42:11

Re: Découverte réseau avec GLPI 0.85.4+1.3

#19 2015-11-06 12:43:40

Re: Découverte réseau avec GLPI 0.85.4+1.3

#20 2015-11-10 17:34:52

Re: Découverte réseau avec GLPI 0.85.4+1.3

#21 2015-11-18 10:24:34

Re: Découverte réseau avec GLPI 0.85.4+1.3

Board footer