-
Notifications
You must be signed in to change notification settings - Fork 13
Document d’architecture technique
1.3 Modèle d’authentification SNMP
1.5.1 Ajout des types de compteurs
1.5.3.2 Conformité du numéro de série
1.5.4 Transfert d’une imprimante vers une autre entité
1.6 Liaison modèles de relevé / imprimantes
1.6.2 La gestion de la configuration de relevés
1.6.3 Gestion des actions supplémentaires
1.6.4 Ajout d’actions massives dans la liste des imprimantes
1.6.5 Ajout des modifications de configuration de relevé dans l’historique des imprimantes
1.7.1 Paramètres d’interrogation
1.7.1.1 Configuration des cartes réseau
1.7.1.3 Configuration des relevés de l’imprimante
1.7.1.4 Données utilisées pour les tests de conformité
1.7.2 Enregistrement du relevé
2.1.1 Ajout des types de compteurs
2.1.1 Transfert d’une imprimante vers une autre entité
2.2 Liaison modèle de facturation / imprimante
2.2.1 Affichage des modèles de facturation
2.2.2 Ajouter des modèles de facturation
2.3.1 Affichage en arborescence
2.3.3 Répartition des coûts sur les budgets parents
L’interrogation des imprimantes par le plugin printercounters s’effectue par l’intermédiaire de plusieurs classes ayant un rôle bien précis.
Un CRON permet de lancer le moteur d’interrogation par l’intermédiaire du script run.php*.\
- Ce script est le point d’entrée du plugin, voici un exemple de commande :
php /var/www/html/glpi/plugins/printercounters/scripts/run.php –sonprocess_nbr=4 –itemtype=Printer
Cette commande prend 2 arguments :
- sonprocess_nbr : Nombre de processus se répartissant l’interrogation des imprimantes
- itemtype : Type d’objet
Le CRON a pour tâche de lancer à intervalle régulier l’interrogation des
compteurs.
A chaque lancement le plugin va trier les imprimantes interrogeables,
et les répartir dans plusieurs processus pour gagner en performances.
La classe PluginPrintercountersProcess permet de gérer l’interrogation sur plusieurs processus.
Les imprimantes sont réparties dans chaque processus de manière à gagner en performances.
Une fois l’imprimante positionnée sur un processus, une mutex (exclusion mutuelle) est fixée sur l’imprimante empêchant son interrogation par un autre processus.
Cette mutex permet de savoir quelles imprimantes sont en cours d’interrogation. Elle est supprimée à la fin de l’interrogation, rendant l’imprimante de nouveau potentiellement interrogeable.
Dans le cas où l’interrogation aurait été inopinément interrompue, la mutex a une période de validité que d’une heure.
Plusieurs critères permettent de sélectionner une imprimante à interroger :
-
Imprimante non supprimée
-
Possédant au moins une adresse IP
-
Interrogation automatique activée
-
Possédant un modèle de relevé
-
La périodicité de relevé est vérifiée : La différence entre la date d’interrogation et la date du dernier relevé est supérieure ou égale à la périodicité.
-
L’imprimante n’est pas déjà en cours d’interrogation (mutex expirée ou supprimée).
Lorsqu’une interrogation est en cours chaque processus est visible sur l’interface de configuration du plugin. Il est possible de les interrompre individuellement ou en totalité.
Si un processus est arrêté toutes les imprimantes liées sont annulées.
La classe PluginPrintercountersSnmpauthentication, permet de gérer les paramètres d’authentification SNMP. Ces paramètres sont indispensables pour effectuer l’interrogation des imprimantes.
Les types de compteur sont gérés par la classe PluginPrintercountersCountertype. Cette classe permet de gérer la liste des types de compteurs.
Les modèles de relevés sont gérés par la classe PluginPrintercountersRecordmodel. Cette classe permet de gérer les OID des compteurs, et les tests de conformité des imprimantes.
La classe PluginPrintercountersCountertype_Recordmodel, permet d’effectuer la liaison entre les types de compteurs avec leurs OID et les modèles de relevé.
Les OID sont nécessaires pour interroger les imprimantes, si aucun OID n’est défini le relevé n’est pas enregistré et une exception est lancée avec un message du type « Veuillez renseigner les OID du modèle de relevé ».
Si un OID est incorrect le relevé est enregistré avec le type « Erreur relevé » et le résultat « Echec OID », avec des compteurs à 0.
Un OID de type « numéro de série » peut être ajouté pour les tests de conformité du numéro de série.
La classe PluginPrintercountersSysdescr, permet d’ajouter une liste de sysdescr sur chaque modèle de relevé, qui servira aux tests de conformité sysdescr.
Ces tests permettent de vérifier si les informations enregistrées dans GLPI correspondent aux informations disponibles sur l’imprimante.
Si l’un de ces tests échoue, les compteurs sont fixés à 0 et le type de relevé est enregistré en « erreur hôte » avec un résultat « échec + nom de l’erreur ».
Les tests de conformités s’exécutent en fonction de la configuration du modèle de relevé. 3 tests de conformités sont disponibles :
Comparaison entre les adresse MAC de chaque carte de l’imprimante dans GLPI et le résultat de l’OID « .1.3.6.1.2.1.2.2.1.6 ».
Comparaison entre le numéro de série de l’imprimante et le résultat de l’OID de type « Numéro de série » spécifié dans le modèle de relevé.
Comparaison entre la liste de sysdescr du modèle de relevé et le résultat de l’OID de type « sysdescr » spécifié dans le modèle de relevé.
La liste des sysdescr est à renseigner dans l’onglet « sysdescr » du modèle de relevé
Si une imprimante est transférée vers une autre entité, il y a un impact sur le modèle de relevé, qui dépend d’une entité.
Le modèle de relevé lié à l’imprimante est dupliqué sur la nouvelle entité de l’imprimante.
Note : Si le modèle de relevé est défini sur une entité parente en mode récursif, il n’est pas dupliqué sur l’entité fille.
La classe PluginPrintercountersItem_Recordmodel, permet de lier une imprimante à un modèle de relevé. Elle permet de gérer toute les interactions avec les imprimantes de GLPI comme :
Les relevés de compteurs sont affichés pour chaque imprimante dans l’onglet « relevé ».
Pour chaque imprimante un formulaire de configuration des relevés est disponible dans l’onglet « relevé » pour sélectionner :
-
Le modèle de relevé
-
Authentification SNMP
-
Activation des relevés automatiques
-
Périodicité des relevés automatiques,
-
Nombre de réessaies
-
Délai maximum
Cette configuration peut aussi se faire en action massive dans la liste des imprimantes.
Pour chaque imprimante il est possible :
-
d’effectuer un relevé de compteur immédiat
-
d’ajouter un relevé manuel
-
de mettre à jour la position de compteur dans GLPI (nombre de pages imprimées depuis la mise en place de l’imprimante)
-
de mettre à jour le TCO global qui se compose de la valeur d’achat (existant dans GLPI) + Les coûts d’intervention (existant dans GLPI)
Des actions massives concernant les actions immédiates et la configuration des relevés sont disponibles dans la liste des imprimantes.
A chaque modification de la configuration des relevés sur l’imprimante, les changements sont inscris dans l’historique de l’imprimante.
1.7 Relevés Une fois les imprimantes sélectionnées et réparties dans chaque processus, la méthode initRecord() de la classe PluginPrintercountersRecord est appelée pour effectuer l’interrogation.
Ensuite la méthode initSearch() de la classe PluginPrintercountersPrinter, est appelée. Cette classe contient les méthodes d’interrogation spécifiques aux imprimantes.
L’interrogation s’effectue grâce aux paramètres suivants :
Pour chaque imprimante l’interrogation se fait sur les différentes cartes réseau. Les adresses MAC et les adresses IP de chaque carte sont répertoriées.
Dans le cas d'adresse IP multiples pour un périphérique (Ethernet et Wifi par exemple), le moteur d'interrogation gère le doublon en n'inscrivant qu'un relevé. En cas d'erreur sur l'une et Succès sur l'autre adresse, seul le résultat du Succès est à inscrire. En cas de double erreur, les deux relevés sont à inscrire en erreur dans l'historique
L’authentification SNMP configurée pour l’imprimante est sélectionnée, comprenant :
-
La version SNMP
-
La communauté
-
Le cryptage de l’authentification (SNMP V3)
-
Le cryptage des données (SNMP V3)
-
Mot de passe pour crypter l’authentification (SNMP V3)
-
Mat de passe pour crypter les données (SNMP V3)
-
L’utilisateur
La configuration des relevés pour l’imprimante est sélectionnée, comprenant :
-
L’ID du modèle de relevé
-
Le nombre de réessaies
-
Le délai maximum (entre chaque essai)
-
L’ID de l’entité de l’imprimante
Chargement des données pour effectuer les tests de conformité de l’imprimante :
-
La liste des sysdescr
-
L’OID du numéro de série
-
La valeur du numéro de série de l’imprimante
-
Activation ou non des tests de conformité
Selon les résultats des tests de conformité, les relevés sont enregistrés en base de données avec un ID de liaison permettant d’identifier l’imprimante concernée.
Les champs suivants sont enregistrés :
-
Id de liaison à l’imprimante
-
La date de relevé
-
L’entité de l’imprimante
-
Les types de compteur
-
Les valeurs des compteurs
-
Le modèle de relevé
-
Le type de relevé
-
Manuel
-
Automatique
-
Erreur hôte, dans le cas où les tests de conformité ont échoué
-
Erreur relevé, dans le cas où un relevé est inférieur au précédent
-
-
Le résultat
-
Succès
-
Echec MAC
-
Echec IP
-
Echec OID
-
Echec sysdescr
-
Echec numéro de série
-
-
Le lieu
-
Les coûts des relevés, basés sur la différence avec le relevé précédent fois le coût des compteurs concernés
-
Le budget où sont imputés les coûts
La gestion des coûts permet d’afficher le calcul des coûts pour chaque relevé, et de répartir les budgets par entité.
La classe PluginPrintercountersBilling, permet de gérer les modèles de facturation pour calculer les coûts des relevés
La classe PluginPrintercountersPagecost, permet d’ajouter des types de compteurs associés à un coût pour chaque modèle de facturation.
Ces coûts sont ensuite multipliés par la différence des volumes des relevés pour chaque compteur. Le coût des relevés est affiché dans le relevé de chaque imprimante.
Si une imprimante est transférée vers une autre entité, il y a un impact sur le modèle de facturation, qui dépend d’une entité.
Le modèle de facturation lié à l’imprimante est dupliqué sur la nouvelle entité de l’imprimante.
Note : Si le modèle de facturation est défini sur une entité parente en mode récursif, il n’est pas dupliqué sur l’entité fille.
La classe PluginPrintercountersItem_Billingmodel, permet de gérer la liaison entre les modèles de facturation et les imprimantes.
Il peut exister plusieurs modèles de facturation pour une imprimante
Elle permet de gérer toute les interactions avec les imprimantes de GLPI comme :
Les modèles de facturations sont affichés pour chaque imprimante dans l’onglet « Modèles de facturation ».
3 critères sont vérifiés pour ajouter des modèles de facturation sur l’imprimante :
-
Il faut que le modèle de relevé de compteurs du modèle de facturation corresponde au modèle de relevé de compteurs de l’imprimante
-
Si aucun modèle de relevé de compteurs n’est défini dans l’imprimante, aucun modèle de facturation ne sera pris en compte
-
Le choix du modèle de facturation dépend de sa date d’application
-
il ne peut y avoir 2 modèles de facturation avec la même date d’application sur une même imprimante
La classe PluginPrintercountersBudget, permet de gérer les budgets.
L’affichage des enveloppes se fait selon l’arborescence des entités. Toutes les fonctions de la classe PluginPrintercountersBudget, parcours les données de façon récursive.
La méthode getRecordsAmountForBudget(), permet de calculer les montants des relevés correspondants à chaque budget.
Il prend en paramètre :
- la liste des budgets,
- la liste des relevés de toutes les entités
- filtrage selon le type d’OID des relevés (cela permet par exemple de calculer le budget pour le relevé « couleur » uniquement)
La méthode setRecursiveBudget(), permet de formater les données des manière récursive (selon l’arborescence des entités) et de répartir les montants des relevés sur les budgets des entités parentes si la période correspond.