Problèmes courants


Je reçois un message d'erreur indiquant vous n'avez pas les droits pour vous connecter à cette application ?

Plusieurs paramètres peuvent être liés à ce message.

  • Aucun profil associé à l'utilisateur : assurez-vous que chaque utilisateur qui se connecte a un profil. Si ce n'est pas le cas, votre règle d'autorisation de profil peut être incorrecte ou manquante.

  • Requêtes SQL temporaires : Les requêtes SQL peuvent saturer le dossier temporaire si elles sont trop volumineuses. La méthode consiste à tuer automatiquement certaines requêtes qui prennent trop de temps (évitant ainsi un stockage temporaire excessif). Veuillez vous référer à la commande pt-kill

    Exemple de commande (pour tuer toutes les requêtes "SELECT" qui durent plus de 61s)" perl /usr/bin/pt-kill --busy-time 61 --match-info "SELECT|select" --kill --victims all --daemonize

  • Problème de droits sur les dossiers GLPI : assurez-vous que le propriétaire des dossiers GLPI est l'utilisateur de votre serveur Web (apache, www-data, etc.) et que les permissions sont correctement définies :

# find  -type f -exec chmod 644 {} +
# find  -type d -exec chmod 755 {} +
# chown   -R

Que puis-je faire concernant le message me disant que les fuseaux horaires ne sont pas accessibles ?

Si les fuseaux horaires ne sont pas activés, vous ne pourrez pas sélectionner le pays dans lequel vous vous trouvez. Suivez la documentation officielle pour activer vos fuseaux horaires.


Pourquoi reçois-je le message d'erreur Une liaison avec le serveur SQL n'a pas pu être établie. Veuillez vérifier votre configuration ?

Cela peut être dû à plusieurs paramètres :

  • Vérifiez que le service mysql est démarré et (re)démarrez-le si nécessaire

  • Vérifiez la présence de votre base de données et les droits accordés à l'utilisateur de cette base de données

  • Vérifiez que le fichier de configuration GLPI est présent et a des permissions suffisantes

  • Vérifiez les logs sql-errors.log dans le dossier files


Pourquoi reçois-je un message d'erreur SSL certificate problem: unable to get local issuer certificate lorsque j'essaie d'activer ma clé d'abonnement dans le marketplace ?

Ce problème vient, généralement sur Windows, d'une configuration manquante. PHP n'a pas été configuré pour intégrer le certificat CA du magasin et ne peut donc pas vérifier la chaîne de notre certificat lorsqu'il essaie de s'y connecter.

Pour remédier à ce problème :

  • Téléchargez et extrayez cacert.pem en suivant les instructions sur https://curl.se/docs/caextract.html

  • Sauvegardez-le sur votre serveur dans un emplacement lisible par l'utilisateur du serveur Web

  • Dans votre php.ini, mettez l'emplacement du fichier cacert.pem dans la section [curl] et [openssl]

[curl]
curl.cainfo = "C:\mywebsite\php\extras\ssl\cacert.pem"

[openssl]
openssl.cafile = "C:\mywebsite\php\extras\ssl\cacert.pem"
  • Redémarrez votre serveur web et votre serveur PHP FPM si nécessaire


Comment configurer Redis pour gérer les sessions dans GLPI ?

  • session.save_handler doit être défini sur redis dans php.ini.

  • session.save_path doit contenir une configuration valide telle que :

    tcp://127.0.0.1:6379?persistent=1&timeout=2.5&read_timeout=2.5&retry_interval=30


Que dois-je faire si les sessions échouent avec Redis ?

  • Vérifiez que Redis est configuré sur le bon port (par défaut 6379).

  • Augmentez le timeout pour stabiliser la connexion.

  • Activez le verrouillage de session dans 20-redis.ini :

extension=redis.so
redis.session.locking_enabled = 1
redis.session.lock_expire = 60
redis.session.lock_wait_time = 50000
redis.session.lock_retries = 2000

Que dois-je faire si GLPI a des problèmes avec les menus ou les tokens dans un environnement front-end partagé ?

  • Assurez-vous que le dossier files/ est partagé entre tous les front-ends (dans le cas d'une installation multi-serveur),

  • Vérifiez les permissions du dossier partagé.

  • Vérifiez les logs


Pourquoi reçois-je une erreur SQL 'Out of range value for column "computertypes_id"' dans les logs GLPI ?

Cette erreur est souvent causée par une règle incorrecte ou incomplète qui modifie les types d'ordinateurs dans GLPI, résultant en une tentative d'écrire une valeur invalide (par exemple, -1) dans la colonne computertypes_id de la base de données.


Que peut-on faire pour éviter que /tmp se remplisse à cause des requêtes SQL ?

  • Optimisez les requêtes SQL : Examinez les vues et recherches par défaut dans GLPI et encouragez les utilisateurs à ne pas ajouter trop de colonnes à leurs requêtes.

  • Redirigez tmp_dir dans MySQL : Configurez le répertoire tmp_dir de MySQL en dehors de la partition /tmp pour éviter l'impact sur le système. Plus d'informations dans la documentation officielle


Comment identifier les utilisateurs responsables de grosses requêtes dans GLPI ?

Il est difficile d'identifier directement les utilisateurs sur la base des requêtes qui remplissent /tmp, car les utilisateurs peuvent ajouter un nombre illimité de colonnes à leurs recherches, générant ainsi de grosses requêtes SQL.


Pourquoi le dossier /tmp se remplit-il anormalement ?

Le problème vient de MySQL. Lorsque les requêtes sont trop longues, il doit écrire dans des tables temporaires (https://dev.mysql.com/doc/refman/8.0/en/internal-temporary-tables.html), et par défaut cela se passe dans le répertoire /tmp du serveur.

  • Examinez les utilisateurs qui ont trop de colonnes dans leurs vues par défaut ou qui ajoutent trop de colonnes à leurs recherches (ex. juan.meneses), car cela génère de très grosses requêtes sur le serveur MySQL, qui ne semble pas être assez gros pour les gérer correctement.

  • Configurez le tmp_dir de MySQL en dehors du système de fichiers /tmp (dans un dossier différent de celui utilisé par le système lui-même).

  • Implémentez un système automatisé (tel que la boîte à outils Percona pt-kill) pour tuer automatiquement les requêtes SELECT sur MySQL qui durent plus de X secondes, évitant ainsi que l'espace disque soit saturé par des requêtes trop volumineuses.

Last updated

Was this helpful?