Skip to main content

Vérifier les accès et les droits entre Medulla et GLPI

S'applique à : Medulla / GLPI
Version de Medulla : Toutes
Version de GLPI : 10 / 11
Environnement : On-Premise
Catégorie : Diagnostic / Intégration GLPI

Contexte

Medulla communique avec GLPI au travers de plusieurs mécanismes :

  • un accès direct à la base de données MySQL/MariaDB de GLPI pour consulter les informations nécessaires au fonctionnement de Medulla ;
  • des vues SQL spécifiques à Medulla, créées dans la base GLPI ;
  • des tables fédérées (local_glpi_*) permettant d'exposer certaines tables GLPI à Medulla ;
  • l'API GLPI pour certaines opérations et interactions avec GLPI.

En cas de problème de remontée d'inventaire, de synchronisation ou d'accès à GLPI depuis Medulla, un script de diagnostic permet de contrôler automatiquement la configuration et les droits utilisés par Medulla.

Le script utilise directement la configuration GLPI enregistrée sur le serveur Medulla.
Il n'est donc pas nécessaire de renseigner manuellement les identifiants de connexion à la base de données ou les jetons API : les paramètres SQL sont lus dans la configuration du plugin GLPI et les jetons API dans la base d'administration de Medulla.

1. Télécharger le script de diagnostic

Connectez-vous en SSH au serveur Medulla avec un compte disposant des droits nécessaires, puis téléchargez le script :

wget https://dl.medulla-tech.io/nc/check_itsm_access.sh

Rendez ensuite le script exécutable :

chmod +x check_itsm_access.sh

Version du script :
Si vous avez déjà téléchargé le script auparavant, supprimez l'ancienne copie et téléchargez-le à nouveau afin de disposer des derniers contrôles (notamment la vérification des tables fédérées).

2. Exécuter le contrôle

Lancez le script depuis le serveur Medulla :

./check_itsm_access.sh

Le script récupère automatiquement les paramètres de connexion GLPI configurés dans Medulla et effectue les contrôles en deux parties :

  • ITSM Database Access Check : contrôles sur la base de données GLPI ;
  • ITSM API Access Check : contrôles sur l'API GLPI.

Avant de commencer, il vérifie la présence des outils nécessaires (voir Prérequis du script) et l'existence du fichier de configuration.

3. Contrôles sur la base de données GLPI

Accès à la base de données GLPI

Le script commence par vérifier que Medulla peut se connecter à la base de données GLPI avec les paramètres actuellement configurés (section [main] du fichier glpi.ini.local). Si aucun port n'est renseigné, le port 3306 est utilisé par défaut.

Il effectue une requête SQL simple afin de valider :

  • l'accessibilité du serveur MySQL/MariaDB ;
  • le port configuré ;
  • le nom de la base de données ;
  • l'utilisateur utilisé par Medulla ;
  • le mot de passe ;
  • les droits permettant d'interroger la base.

Lorsque la connexion fonctionne, le résultat suivant est affiché :

[✓] Database connection successful

En cas d'échec, le script s'arrête immédiatement, les contrôles suivants ne pouvant pas être réalisés :

[✗] Failed to connect to database

==========================================
Database connectivity check failed!
==========================================

En cas d'échec de cette première étape :
vérifiez en priorité les identifiants MySQL/MariaDB, le port utilisé, les autorisations réseau et les droits accordés à l'utilisateur Medulla sur la base GLPI.

Présence des tables GLPI nécessaires

Le script vérifie ensuite que les 16 tables GLPI utilisées par l'intégration sont accessibles :

glpi_computers
glpi_users
glpi_profiles
glpi_entities
glpi_groups
glpi_softwares
glpi_networkports
glpi_printers
glpi_monitors
glpi_peripherals
glpi_tickets
glpi_changes
glpi_problems
glpi_projects
glpi_locations
glpi_plugin_glpiinventory_collects

La table glpi_plugin_glpiinventory_collects est fournie par le plugin GLPI Inventory. Son absence indique généralement que le plugin n'est pas installé ou pas activé.

Si toutes les tables attendues sont accessibles :

[✓] All 16 required tables found

Dans le cas contraire, le script affiche la liste des tables manquantes ou non accessibles :

[✗] Missing tables: ...

Contrôle des vues SQL Medulla

Medulla utilise également plusieurs vues SQL spécifiques pour exploiter certaines informations GLPI. Le script vérifie la présence et l'accessibilité des vues suivantes :

glpi_computers_pulse
glpi_view_computers_items_printer
glpi_view_computers_items_peripheral
glpi_view_peripherals_manufacturers

Si toutes les vues sont accessibles :

[✓] All 4 required views found

Dans le cas contraire, le script liste les vues manquantes et indique la marche à suivre pour les créer :

[✗] Missing views: ...

Les vues sont créées en important dans la base GLPI le script SQL correspondant à votre version de GLPI :

Version de GLPI Script SQL
GLPI 10 https://dl.medulla-tech.io/nc/glpi-100.sql
GLPI 11 https://dl.medulla-tech.io/nc/glpi-110.sql

Exemple d'import :

wget https://dl.medulla-tech.io/nc/glpi-110.sql
mysql -h <HOTE_GLPI> -P <PORT> -u <UTILISATEUR> -p <BASE_GLPI> < glpi-110.sql

La création des vues peut nécessiter un compte disposant de droits plus élevés que l'utilisateur Medulla (par exemple le compte root MySQL/MariaDB).

Attention en mode lecture seule :
la présence des vues ne suffit pas. L'utilisateur MySQL/MariaDB utilisé par Medulla doit également disposer des droits SELECT et SHOW VIEW nécessaires.

Reportez-vous à la documentation sur la configuration des accès GLPI pour connaître les droits à appliquer :

https://docs.medulla-tech.io/books/medulla-faq/page/glpi-connecter-un-glpi-externe

Contrôle des tables fédérées

Medulla s'appuie sur des tables fédérées qui exposent certaines tables GLPI via le moteur FEDERATED de MariaDB. Le script vérifie la présence des 7 tables suivantes :

Table fédérée Table GLPI source
local_glpi_configs glpi_configs
local_glpi_entities glpi_entities
local_glpi_filters glpi_computers
local_glpi_items_softwareversions glpi_items_softwareversions
local_glpi_machines glpi_computers
local_glpi_softwares glpi_softwares
local_glpi_softwareversions glpi_softwareversions

Si toutes les tables fédérées sont présentes :

[✓] All 7 required federated tables found

Dans le cas contraire :

[✗] Missing federated tables: ...

Le script affiche alors les requêtes SQL permettant de déclarer le serveur fédéré itsm_federated et de créer les tables manquantes, préremplies avec les paramètres de connexion configurés. À titre de référence, ces requêtes sont les suivantes :

CREATE OR REPLACE SERVER itsm_federated FOREIGN DATA WRAPPER 'mariadb'
  OPTIONS ( HOST "<HOTE_GLPI>", PORT "<PORT>", USER '<UTILISATEUR>', PASSWORD '<MOT_DE_PASSE>', DATABASE '<BASE_GLPI>' );

CREATE OR REPLACE TABLE `local_glpi_configs` (`id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(150) DEFAULT NULL, `value` text DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_configs';

CREATE OR REPLACE TABLE `local_glpi_machines` (`id` int NOT NULL, primary key(id), `entities_id` int(10) NOT NULL DEFAULT 0, `name` varchar(255) NULL DEFAULT NULL, `is_template` tinyint(4) NOT NULL DEFAULT 0, `is_deleted` tinyint(4) NOT NULL DEFAULT 0) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_computers';

CREATE OR REPLACE TABLE `local_glpi_filters` (`id` int NOT NULL, primary key(id), `states_id` int(10) NOT NULL DEFAULT 0, `entities_id` int(10) NOT NULL DEFAULT 0, `computertypes_id` int(10) NOT NULL DEFAULT 0, `autoupdatesystems_id` int(10) NOT NULL DEFAULT 0) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_computers';

CREATE OR REPLACE TABLE `local_glpi_items_softwareversions` (`id` int NOT NULL, primary key(id), `items_id` int NOT NULL DEFAULT 0, `itemtype` varchar(100) NOT NULL, `softwareversions_id` int NOT NULL DEFAULT 0) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_items_softwareversions';

CREATE OR REPLACE TABLE `local_glpi_softwareversions` (`id` int NOT NULL, primary key(id), `softwares_id` int NOT NULL DEFAULT 0, `name` varchar(255) DEFAULT NULL, `comment` text DEFAULT NULL) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_softwareversions';

CREATE OR REPLACE TABLE `local_glpi_softwares` (`id` int NOT NULL, primary key(id), `name` varchar(255) NULL DEFAULT NULL, `comment` text NULL DEFAULT NULL) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_softwares';

CREATE OR REPLACE TABLE `local_glpi_entities` (`id` int(10) unsigned NOT NULL DEFAULT 0, PRIMARY KEY (`id`), `completename` text DEFAULT NULL, `name` varchar(255) DEFAULT NULL) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci CONNECTION='itsm_federated/glpi_entities';

Prérequis :
le moteur FEDERATED doit être disponible et activé sur le serveur MariaDB. La déclaration du serveur fédéré et la création des tables peuvent nécessiter le compte root MySQL/MariaDB.

4. Contrôles sur l'API GLPI

Une fois les contrôles SQL terminés, le script teste automatiquement l'accès à l'API GLPI configurée dans Medulla.

Chargement de la configuration API

Le script récupère :

  • l'URL de l'API, l'utilisateur et le mot de passe GLPI dans la section [webservices] du fichier /etc/mmc/plugins/glpi.ini.local (paramètres glpi_base_url, glpi_username, glpi_password) ;
  • les jetons dans la table saas_application de la base admin de Medulla, à l'aide des identifiants du fichier /etc/mmc/plugins/admin.ini.local :
    • glpi_mmc_app_token : App-Token du client API utilisé par Medulla ;
    • glpi_root_user_token : user_token GLPI ;
    • glpi_crypt_key : clé de chiffrement GLPI.

Si l'un de ces trois éléments est absent de la base, le script s'arrête :

[✗] Failed to load ITSM API configuration. Missing required tokens or crypt key in database.

Attention :
dans ce cas, le script affiche en clair les valeurs récupérées pour ITSM_APP_TOKEN, ITSM_USER_TOKEN et ITSM_CRYPT_KEY. Masquez-les avant toute transmission.

Accessibilité du serveur API

Le premier test vérifie que l'URL de l'API GLPI est accessible depuis le serveur Medulla (délai d'attente de 10 secondes).

Si le serveur est joignable :

[✓] API server reachable at ...

En cas d'échec, le script s'arrête, les tests d'authentification ne pouvant pas être réalisés :

[✗] Cannot reach API server at ...

==========================================
API connectivity check failed!
==========================================

En cas d'échec :
vérifiez l'URL configurée, la résolution DNS, les flux réseau, les règles de firewall ainsi que la disponibilité du serveur GLPI.

Authentification avec les identifiants GLPI

Le script teste ensuite l'ouverture d'une session API GLPI (initSession) avec le nom d'utilisateur et le mot de passe configurés dans Medulla, associés à l'App-Token.

Lorsque l'authentification fonctionne :

[✓] Credential authentication successful

Dans le cas contraire, le script indique le code HTTP retourné par GLPI et fournit une commande curl permettant d'effectuer un diagnostic complémentaire (le mot de passe y est masqué) :

[✗] Credential auth failed with HTTP status ...

Authentification par jeton

Le script effectue enfin un second test d'authentification avec :

  • le user_token GLPI ;
  • l'app_token du client API utilisé par Medulla.

Lorsque les jetons sont valides :

[✓] Token authentication successful

Dans le cas contraire :

[✗] Token auth failed with HTTP status ...

Une commande curl de diagnostic est également proposée par le script (le user_token y est masqué).

5. Interpréter le résultat

Le script réalise au total 7 contrôles. Si tous sont valides, il termine par :

==========================================
All checks passed! (7 checks)
==========================================

La communication entre Medulla et GLPI est alors fonctionnelle pour les éléments testés par le script.

Si une ou plusieurs vérifications échouent, le script indique le nombre de contrôles en échec et réussis :

==========================================
Some checks failed! (Failed: X, Passed: Y)
==========================================

Les lignes précédées de [✗] permettent d'identifier le ou les contrôles en erreur.

Erreur Élément à vérifier
Missing required tools Installation de crudini, mysql et curl sur le serveur Medulla
Configuration file not found / not readable Présence et droits de lecture de /etc/mmc/plugins/glpi.ini.local (lancer le script avec un compte suffisamment privilégié)
Failed to load database configuration Paramètres dbhost, dbuser et dbname de la section [main] de glpi.ini.local
Failed to connect to database Accès réseau, port SQL, utilisateur, mot de passe et droits MySQL/MariaDB
Missing tables Version / structure GLPI, installation du plugin GLPI Inventory et droits de lecture sur les tables concernées
Missing views Import du script SQL des vues Medulla (GLPI 10 ou 11) et droits SELECT / SHOW VIEW
Missing federated tables Moteur FEDERATED activé, serveur fédéré itsm_federated déclaré et tables local_glpi_* créées
Failed to load ITSM API configuration Fichier admin.ini.local et valeurs glpi_mmc_app_token, glpi_root_user_token, glpi_crypt_key de la table saas_application
Cannot reach API server URL GLPI, DNS, routage, firewall et disponibilité du serveur
Credential auth failed Utilisateur GLPI, mot de passe et app_token
Token auth failed user_token, app_token et configuration de l'API GLPI

6. Prérequis du script

Le script utilise les outils suivants sur le serveur Medulla :

  • crudini
  • mysql
  • curl

Il vérifie automatiquement leur présence avant de commencer les tests.

Il utilise la configuration Medulla présente dans :

/etc/mmc/plugins/glpi.ini.local
/etc/mmc/plugins/admin.ini.local

ainsi que la table saas_application de la base admin de Medulla, dans laquelle sont stockés les jetons API et la clé de chiffrement GLPI.

7. En cas de problème

Si le script signale une erreur, corrigez le point indiqué puis relancez simplement :

./check_itsm_access.sh

Si le problème persiste, transmettez au support Medulla la sortie complète du script afin de faciliter le diagnostic.

Sécurité :
Certaines sorties du script contiennent des secrets en clair, notamment :

  • la commande d'import des vues SQL (mot de passe MySQL/MariaDB) ;
  • la requête de création du serveur fédéré itsm_federated (mot de passe MySQL/MariaDB) ;
  • les valeurs des jetons et de la clé de chiffrement en cas d'échec de chargement de la configuration API ;
  • l'App-Token dans les commandes curl de diagnostic.

Avant de transmettre des résultats ou des commandes de diagnostic, masquez systématiquement tout mot de passe, jeton API ou autre secret d'authentification.

Documentation complémentaire

Pour la configuration initiale des droits MySQL/MariaDB, des vues SQL et de l'API GLPI, reportez-vous à la FAQ consacrée à la connexion d'un GLPI externe :

https://docs.medulla-tech.io/books/medulla-faq/page/glpi-connecter-un-glpi-externe

Scripts SQL de création des vues Medulla :

Script de diagnostic :

https://dl.medulla-tech.io/nc/check_itsm_access.sh

Back to top