You are not logged in.
J'ai repéré quelques messages ayant en problème aucune remontée de matériels et un agent restant "en cours d'exécution" mais pas de réelle solution.
J'ai ce souci avec des points qui varient....
J'aimerai faire un petit récapitulatif! (Glpi 0.72.21 et Tracker 2.1.2)
1. L'agent ce lance correctement avec des remontées dans les logs dans la partie discovery mais rien dans query:
==== Discovery ====
[10.0.0.33][YES][2c][public]
==== Query ====
=========================================
================== END ==================
=========================================
2. Plusieurs tests on été effectué au niveau du nombre de coeurs et de thread.
3. Le script tracker_fullsync.sh à été lancé.
A ce propos, celui-ci doit-il être lancé toujours à la mano ou doit-il s'exécuter automatiquement?
Le fichier de log tracker_fullsync.log et tracker_snmp.log ne contiennent pas d'erreurs.
Voici le premier:
lundi 5 octobre 2009, 15:33:57 (UTC+0200) ./tracker_fullsync.sh started
[2009-10-05 15:33][][] >>>>>>>>>> WireInterSwitchs <<<<<<<<<<
lundi 5 octobre 2009, 15:33:58 (UTC+0200) ended
Pour conclure je me demande si il s'agit d'un simple problème d'utilisation ou s'il s'agit d'un véritable problème!
Offline
A mon avis un soucis de config. Regardez la doc que j'ai fini de rédigé hier qui indique un exemple d'utilisation (https://forge.indepnet.net/wiki/tracker/Fr_V_exemple)
Offline
J'ai donc refait selon le modèle sans plus de résultat, l'agent étant toujours en cours d'exécution.
La commande snmpwalk fonctionne correctement et j'ai bien discovery à yes dans les logs.
Je ne sais pas trop qu'elles autres informations donner!
Offline
Vous pouvez envoyer le log entier par mail d.durieux@siprossii.com ?
Offline
Pour information je n'ai également pas d'information "dernière remontée" ni "version de l'agent" pour mon agent en question!
Pour info également, sur Ubuntu faut-il installer php5 runkit?
Offline
oh non, je l'installe pas, il se sert plus à rien
Offline
Afin d'effectuer des test j'ai crée un matériel réseau ayant l'une des IPs indiquée dans la plage IP et j'ai renseigné dans l'onglet Informations SNMP du matériel les infos Switch générique et Authentification Private.
Ceci fait les logs de l'agent tracker sont en effet plus complets:
$VAR1 = {
'agent' => {
'threads_query' => '6',
'PID' => '02790816001',
'fragment' => 50,
'core_query' => '1',
'logs' => '2',
'key' => 'RwSczlEw0ZQR4zSnQKgxGdGc9ZmRoI',
'id' => '1',
'threads_discovery' => '20',
'core_discovery' => '2'
},
'discovery' => {
'rangeip' => {
'entity' => '0',
'id' => '1',
'ipend' => '10.0.0.150',
'ipstart' => '10.0.0.20'
},
'authentification' => {
'1' => {
'version' => '1',
'sec_name' => {},
'auth_passphrase' => {},
'community' => 'public',
'sec_level' => '0',
'priv_protocol' => '0',
'priv_passphrase' => {},
'auth_protocol' => '0'
},
'4' => {
'version' => '2c',
'sec_name' => {},
'auth_passphrase' => {},
'community' => 'private',
'sec_level' => '0',
'priv_protocol' => '0',
'priv_passphrase' => {},
'auth_protocol' => '0'
},
'2' => {
'version' => '2c',
'sec_name' => {},
'auth_passphrase' => {},
'community' => 'public',
'sec_level' => '0',
'priv_protocol' => '0',
'priv_passphrase' => {},
'auth_protocol' => '0'
}
}
},
'device_networking' => {
'auth' => {
'priv_protocol' => '0',
'sec_level' => '0',
'community' => 'private',
'sec_name' => {},
'version' => '2c',
'priv_passphrase' => {},
'auth_passphrase' => {},
'auth_protocol' => '0'
},
'infos' => {
'entity' => '0',
'ip' => '10.0.0.130',
'type' => '2',
'id' => '32'
},
'walk' => [
{
'object' => 'cdpCacheAddress',
'oid' => '.1.3.6.1.4.1.9.9.23.1.2.1.1.4',
'vlan' => '0'
},
{
'object' => 'cdpCacheDevicePort',
'oid' => '.1.3.6.1.4.1.9.9.23.1.2.1.1.7',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifDescr',
'oid' => '.1.3.6.1.2.1.2.2.1.2',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifIndex',
'oid' => '.1.3.6.1.2.1.2.2.1.1',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifInErrors',
'oid' => '.1.3.6.1.2.1.2.2.1.14',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifInOctets',
'oid' => '.1.3.6.1.2.1.2.2.1.10',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifAdminStatus',
'oid' => '.1.3.6.1.2.1.2.2.1.7',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifLastChange',
'oid' => '.1.3.6.1.2.1.2.2.1.9',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifMtu',
'oid' => '.1.3.6.1.2.1.2.2.1.4',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifName',
'oid' => '.1.3.6.1.2.1.31.1.1.1.1',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifOutErrors',
'oid' => '.1.3.6.1.2.1.2.2.1.20',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifOutOctets',
'oid' => '.1.3.6.1.2.1.2.2.1.16',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifPhysAddress',
'oid' => '.1.3.6.1.2.1.2.2.1.6',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifSpeed',
'oid' => '.1.3.6.1.2.1.2.2.1.5',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifOpenStatus',
'oid' => '.1.3.6.1.2.1.2.2.1.8',
'vlan' => '0'
},
{
'object' => 'IF-MIB::ifType',
'oid' => '.1.3.6.1.2.1.2.2.1.3',
'vlan' => '0'
},
{
'object' => 'ipNetToMediaPhysAddress',
'oid' => '.1.3.6.1.2.1.4.22.1.2',
'vlan' => '1'
},
{
'object' => 'vlanTrunkPortDynamicStatus',
'oid' => '.1.3.6.1.4.1.9.9.46.1.6.1.1.14',
'vlan' => '1'
},
{
'object' => 'vtpVlanName',
'oid' => '.1.3.6.1.4.1.9.9.46.1.3.1.1.4.1',
'vlan' => '0'
}
],
'get' => [
{
'object' => 'sysDescr',
'oid' => '.1.3.6.1.2.1.1.1.0',
'vlan' => '0'
},
{
'object' => 'sysLocation',
'oid' => '.1.3.6.1.2.1.1.6.0',
'vlan' => '0'
},
{
'object' => 'freeMem',
'oid' => '.1.3.6.1.4.1.9.2.1.8.0',
'vlan' => '0'
},
{
'object' => 'sysName',
'oid' => '.1.3.6.1.2.1.1.5.0',
'vlan' => '0'
},
{
'object' => 'processorRam',
'oid' => '.1.3.6.1.4.1.9.3.6.6.0',
'vlan' => '0'
},
{
'object' => 'entPhysicalSerialNum',
'oid' => '.1.3.6.1.2.1.47.1.1.1.1.11.1001',
'vlan' => '0'
},
{
'object' => 'sysUpTime',
'oid' => '.1.3.6.1.2.1.1.3.0',
'vlan' => '0'
},
{
'object' => 'ifNumber',
'oid' => '.1.3.6.1.2.1.2.1.0',
'vlan' => '0'
}
]
}
};
[...]
==== Query ====
[10.0.0.130] : start Thread
[10.0.0.130] : end Thread
=========================================
================== END ==================
=========================================
Mis à part les logs, cela n'a pas d'autres effets, pas de matériel détecté ni inconnu, et un agent qui reste en cours de traitement!!
Offline
Si il a interrogé là, vous avez lancé le script serveur après l'agent?
Offline
Le script serveur à été lancé, sans avoir de remonté.
Offline
Humm peut être le bug du caractère à la con. Faudrait tester avec la version svn de l'agent et du serveur ou attendre la semaine prochaine les nouvelle releases
Offline
J'ai refait des tests avec l'agent du SVN et le tarball de tracker, sans que cela ne change quelque chose. Je vais donc attendre la vers 2.1.3 du server!
Offline
On a fait des tests avec Tsmr hier et apparement sous Ubuntu ça a l'air de foirer. Je vais faire des tests plus poussés de mon côté
Offline
Je suis également intéressé :
Ubuntu 9.10 / GLPI 0.72.21 / Tracker serveur 2.1.3 / Tracker agent 1.5.3
28 matériels dans la plage ip avec les infos nécessaires.
snmpwalk ok.
Dans le log de l'agent la partie discovery et ok mais rien en query.
L'agent reste "en cours d'exécution" avec 0 partout sauf PID et date de début.
Rien dans le matériel découvert, ni inconnu.
=========================================
============== Start Agent ==============
=========================================
Operating system : linux
Operating system version : 2.6.24-23-server
Operating system arch : i486-linux-gnu-thread-multi
Perl version : 5.10.0
Thread version : 1.67
ForkManager version : 0.7.5
SNMP version :
Zlib version : 2.02
AppConfig version : 1.56
UserAgent version : 5.829
HTTP Request Common version : 5.824
XML Simple version : 2.18
Data Dumper version : 2.121_14
FindBin version : 1.49
$VAR1 = {
'agent' => {
'threads_query' => '1',
'PID' => '03121327001',
'fragment' => 50,
'core_query' => '1',
'logs' => '2',
'key' => 'iVJCk4fPDb6qgqhLGQ73KWakmQkCr4',
'id' => '1',
'threads_discovery' => '1',
'core_discovery' => '1'
},
'discovery' => {
'rangeip' => {
'entity' => '0',
'id' => '1',
'ipend' => 'x.x.x.x',
'ipstart' => 'x.x.x.x'
},
'authentification' => {
'1' => {
'version' => '1',
'sec_name' => {},
'auth_passphrase' => {},
'community' => 'public',
'sec_level' => {},
'priv_protocol' => {},
'priv_passphrase' => {},
'auth_protocol' => {}
},
'2' => {
'version' => '2c',
'sec_name' => {},
'auth_passphrase' => {},
'community' => 'public',
'sec_level' => {},
'priv_protocol' => {},
'priv_passphrase' => {},
'auth_protocol' => {}
}
}
}
};
==== List of IP to discover ====
$VAR1 = {
'0' => {
'x.x.x.x' => '0',
...
'x.x.x.x' => '0'
}
};
==== Discovery ====
[x.x.x.x][YES][2c][public]
[x.x.x.x][YES][1][public]
...
==== Query ====
=========================================
================== END ==================
=========================================
Dans la table glpi_plugin_tracker_printers, on trouve bien les imprimantes de la plage ip.
On dirait qu'il bloque sur l'interrogation ?
Offline
Il n'a rien reçu du serveur, vérifiez le status (lié vaec le status d'interrogation dans la config), la page ip dans lequel le matériel se trouve a bien l'interrogation d'activé... déjà ça à vérifier
Offline
Le statut des imprimantes est "ACTIF" comme celui de la config du serveur.
La plage ip est correcte, d'ailleurs la partie "découverte" a bien fonctionnée puisque les imprimantes sont apparues dans la table mySQL glpi_plugin_tracker_printers, mais le script ne les a pas inscrite dans le matériel découvert ou inconnu !
Offline
Elles ont bien une authentification associée ainsi qu' un modèle SNMP (onglet informations snmp)?
Offline
Oui, j'ai renseigné un modèle snmp (imprimante générique) et une authentification snmp v1 public :
[x.x.x.x][YES][1][public]
donc le matériel a répondu ?
Offline
non ça c'est l'interrogation.
Vous avez des fichiers dans glpi/files/_plugins/tracker/ ?
Offline
Oui, 6 fichiers qui correspondent au script lancé aujourd'hui.
Offline
... mais ils sont vides !
Offline
Vous avez bien suivi l'exemple de mise en place ? (https://forge.indepnet.net/wiki/tracker/Fr_V_exemple)
Offline
Oui, plusieurs fois même !
Je n'ai pas activé l'historique, ni le snmp réseaux.
Je n'ai pas touché non plus au "Nombre de process simultanés pour le script serveur de post-traitement", ni au niveau de l'agent les données "Coeurs (CPU) découverte", "Threads découverte (par coeur)", "Coeurs (CPU) interrogation", "Threads interrogation (par coeur)" qui sont restés aux valeurs par défaut.
Offline
Il y a un truc qui le gêne pour envoyer les ip à interroger à l'agent. Comme ça je ne vois pas , j'ai fait à peut prêt le tour de ce qui pouvait merdouiller
Offline
Un module perl manquant peut-être ? Mais lequel ...
J'ai eu quelques difficultés à trouver les .deb
Offline
J'ai tenté une installation des modules avec la commande
sudo cpan -i strict diagnostics Config Net::SNMP Compress::Zlib AppConfig LWP::UserAgent HTTP::Request::Common XML::Simple Data::Dumper FindBin Parallel::ForkManager
La commande semble avoir bien fonctionnée mais rien de nouveau du côté de l'agent ...
Je ne vois plus où chercher
Offline