Pourquoi sortir de l'interface
Trois besoins reviennent, et aucun ne se traite à la main.
Créer un ticket depuis un outil de supervision quand un serveur tombe. Alimenter GLPI depuis un logiciel de ressources humaines à l'arrivée d'un salarié. Extraire un état du parc pour un tableau de bord ailleurs.
GLPI expose une API REST pour cela. Les objets y sont les mêmes que dans l'interface : on lit, on crée, on modifie, on cherche.
Le jeton, et ce qu'il engage
L'accès se fait par jeton, et deux niveaux existent : un jeton d'application, qui identifie le programme appelant, et un jeton personnel, rattaché à un utilisateur.
Point de sécurité central : l'API agit avec les droits de l'utilisateur du jeton. Un jeton rattaché à un compte Super-Admin donne à un script la capacité de tout supprimer.
Quatre règles suffisent à rester propre :
- un compte de service dédié par intégration, avec un profil taillé au besoin
- un jeton par intégration, jamais partagé, pour pouvoir en révoquer un seul
- une restriction des adresses appelantes quand la supervision est sur un segment connu
- HTTPS obligatoire, sinon le jeton circule en clair
Un jeton fuité est un accès complet à votre inventaire et à vos tickets. Il se révoque et se régénère, ce qui est la bonne réaction, plutôt que la recherche de ce qui a fuité.
Le cas qui rapporte le plus
L'intégration supervision vers GLPI est celle qui paie le plus vite.
L'outil de supervision détecte, appelle l'API, le ticket existe avant que quiconque s'en aperçoive, avec le bon matériel lié et la bonne priorité.
Une précaution obligatoire : la déduplication. Un service qui bat pendant la nuit produit quarante tickets identiques si rien ne l'empêche. Le motif correct consiste à chercher un ticket ouvert pour ce matériel et cette cause avant d'en créer un, et à ajouter un suivi au lieu d'un doublon.
Les règles d'import, l'autre moitié du travail
Elles s'appliquent aux inventaires entrants et décident de trois choses.
Ce qui entre et ce qui est refusé. Une machine de test, un poste d'un domaine invité, une VM éphémère n'ont pas à polluer le parc.
Où cela entre. L'entité de destination, déduite du tag de l'agent, du domaine ou du sous-réseau. C'est ainsi qu'un parc multi-sites se range tout seul.
Ce qui est mis à jour, et ce qui ne l'est pas. Un champ saisi à la main, un nom d'usage, un lieu précis, peut être verrouillé pour que l'inventaire ne l'écrase pas à la prochaine remontée.
Ce dernier point est celui qui sauve les données saisies par les humains. Sans verrou, une information patiemment renseignée disparaît au prochain passage de l'agent, et l'équipe cesse de saisir.
Les dictionnaires
Même mécanisme, appliqué aux valeurs plutôt qu'aux objets. Ils normalisent les noms de fabricants, de modèles et de logiciels au moment de l'import.
Sans eux, le même constructeur apparaît sous cinq écritures selon les machines, et tout regroupement est faux. Ils se mettent en place une fois, sur les quelques valeurs qui polluent réellement, et non exhaustivement.
À retenir
L'API agit avec les droits de son jeton : un compte de service par intégration, jamais un Super-Admin. Dédupliquez avant de créer un ticket depuis la supervision. Et verrouillez les champs saisis à la main, sinon l'inventaire les écrase et personne ne saisit plus rien.