Bonjour,
Suite à des problèmes de saturations chroniques du CPU d'une de mes bases de données hébergées chez OVH, j'ai été amené à contacter le support, ainsi qu'à mener mes propres investigations.
Le problème de CPU est toujours non-résolu, mais l'une des étapes pour voir plus clair dans la situation me semble être déjà d'avoir des logs utiles dans la compréhension du problème. Or l'intégralité de mes logs - auxquels j'accède en SFTP - sont remplis du même message d'avertissement :
[Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'
Le message est assez clair, le mot de passe d'un ou des utilisateurs de la base de données utilisent une méthode de hachage dépréciée - je suppose que cela vient du récent passage en MySQL 8. Selon le support, c'est à moi de corriger cette question de hachage - et me renvoie donc ici.
Cependant mes recherches semblent m'indiquer que je n'aurais pas les droits ou les permissions pour changer cela - par exemple, je ne peux pas requêter la table mysql.user pour voir le plugin de hachage de tel ou tel utilisateur - ou même de faire disparaître l'avertissement. J'ignore par ailleurs quelles seraient les conséquences d'un tel changement sur le fonctionnement de mon site web.
Sont-ce des configurations à changer dans les paramètres de connexion de mon site internet (Prestashop 1.7.8) à la base de données ? Je ne vois rien allant dans ce sens dans le fichier de configuration des paramètres de connexion à la base de données du CMS. Et je ne trouve pas beaucoup plus d'informations du côté de Prestashop.
En résumé, j'ai besoin d'aide.
J'espère avoir été clair, par avance merci.
Hébergements Web - Logs base de données : Plugin mysql_native_password reported: ''mysql_native_password'
Related questions
- Connexion à mon compte client
145304 
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
121802 03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
106520 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
93747 28.07.2017 11:39
- Passage en php 7.4
92358 30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
87271 04.12.2019 21:52
- The requested URL / was not found on this server
86445 02.03.2017 18:25
- Deploy d'un projet Node JS
86075 12.10.2016 20:18
- NextCloud sur mutualisé
86071 07.04.2017 08:42
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
85701 16.10.2016 16:24
Bonjour,
avez-vous essayé en faisant un reset du mot de passe de votre utilisateur SQL depuis l’espace client ?
Sinon peut être que @MikaelD1 pourrait en dire plus.
Cordialement, janus57
Salut @EtienneP12 et @janus57 🙂
Effectivement, ce warning vient du passage en MySQL 8.0. Explications.
Quand on crée un utilisateur, MySQL stock le hash de son mot de passe (et non le mot de passe chiffré). Le hash, c'est une fonction qui permet de transformer le mot de passe en une chaîne de caractères de taille fixe.
À partir d'un hash, il n'est pas possible de retrouver un mot de passe. Mais quand tu saisis ton mot de passe pour t’authentifier, MySQL calcule son hash et le compare à celui qu'il a stocké quand il a créé l'utilisateur.
Il existe plein de fonctions différentes pour calculer un hash. Par exemple, le hash de 'EtienneP12', c'est:
* `d62fcdb92a552e1d59787c694d22c3ae` en utilisant le MD5
* `192cc398a4b200eee7cc2da8be9d22bbe9628642ff4918344d782eb50df6460e` en utilisant le SHA256
* `eb35f237dc6f78b0eeb175b9138d4b02270dd0af82fb8d36caedaa4e9e88af8f6fdb5decfa0c53e7d3edf2a7e9a55d38a7743fd31dbf5037b871effca4be210a` en utilisant le SHA512
* etc, etc
MySQL utilise ses propres fonctions de hash, `mysql_native_password` en MySQL 5.7 et avant, `caching_sha2_password` à partir de MySQL 8.0.
Évidemment, MySQL 8.0 supporte toujours l'ancienne méthode, `mysql_native_password`, pour éviter de rejeter toute authentification sur les utilisateurs créés en 5.7 et avant. Par contre, il te demande gentiment de bien vouloir passer à l'autre méthode. Comment ? En mettant à jour le hash qui a été stocké en base.
Côté client, il est nécessaire d'avoir une version >= 8.0. Les 2 côtés (client et serveur) doivent connaître la nouvelle méthode de hash des mots de passe.
Le hic, ce sont les très (très) vieilles versions de PHP pour lesquelles il est compliqué de mettre à jour le client MySQL. On creuse ce point…
Une alternative pourrait consister à vous demander quel algorithme de hash vous souhaitez utiliser lorsque vous créez vos utilisateurs, mais ça ajouterait beaucoup de complexité, autant pour vous que pour nous.
Bref, le sujet n'est pas simple. La bonne nouvelle, c'est qu'il n'a pas d'impact pour vous si ce n'est le flood de messages que vous pouvez voir dans vos logs et pour lesquels vous ne pouvez (pour l'instant), rien faire.
Merci @MikaelD1 pour ce retour explicatif.
Dans la continuité, et en espérant que ça ne dévie pas trop du sujet initial, je me demandais si ce warning ne pouvait pas faire écran en quelque sorte aux véritables problèmes qui essaieraient d'être mis dans les logs ?
Pour clarifier, étant donné que ma base de données a des problèmes de saturation du CPU, mais que le seul message que je vois dans mes logs est ce warning à propos de la méthode de hachage, je me demande si des messages plus directement liés à ces problèmes de CPU sont empêchés d'être log à cause du warning ?
Je me pose cette question après avoir lu un post de blog concernant ce warning qui floodait des logs, mais la véritable cause du problème était moins la question du hachage, et plus le fait qu'un utilisateur non-enregistré essayait d'accéder à la base de données - apparemment quand un utilisateur non-enregistré essaye de se connecter, il lui est automatiquement assigné de façon aléatoire un plugin d'authentification.
Il y a clairement un lien avec la question du hachage dans ce cas, donc le warning n'est pas complètement hors-propos, mais je me demandais malgré tout s'il pouvait m'empêcher d'avoir des logs lisibles - au-delà du flood.
Encore merci pour le retour.
Réponse courte: non. Tous tes logs sont bien écrits.
Réponse longue: je vois 5 cas où un flood de log peut t'empêcher de voir des logs légitimes.
* Le filtre «visuel». Si je fais défiler mes logs en me disant qu'un log différent va sûrement me sauter aux yeux, alors c'est quasi-sur, je vais le louper. Dans la team, on appelle ça «grep avec les yeux» 😁 C'est bien sûr une méthode qu'il faut éviter, le filtre doit se faire avec un procédé technique.
* Le filtre technique est mal fait. Par exemple, si tu filtres le log avec un `grep -v 'instead'`, alors tu ne verras pas tous les logs qui comportent le mot `instead`.
* Tes logs sont envoyés en UDP. Ce n'est pas le cas ici, MySQL écrit directement dans le fichier que tu télécharges en SFTP.
* Tes logs sont filtrés en amont (exemple: MySQL écrit dans un fichier, puis ce fichier est lu, retravaillé, et mis à disposition via SFTP). Ici encore, ce n'est pas le cas, MySQL écrit directement dans le fichier que tu télécharges en SFTP.
* Une rotation a eu lieue sur tes logs. Là il faut que tu regardes la première et la dernière ligne de ton fichier. Tu auras un créneau horaire (qui peut durer plusieurs jours). Saches que tu peux être sûr que tous les logs compris dans ce créneau sont bien dans le fichier.
Envoie moi le nom de ton instance en message privé, je vais essayer de trouver du temps pour jeter un œil à ton problème de saturation CPU 🙂
Je suis embarrassé, mais je ne vois pas du tout comment envoyer un message privé...
Je peux accéder à la boite de réception de mes MP - qui est vide donc - ou accéder à ton profil, mais je ne vois nulle part les éventuels boutons me permettant d'envoyer un message direct.
Les nouveaux utilisateurs n'y ont pas droit.
@MikaelD1 aurait dû t'envoyer un MP, ce qui t'aurait permis d'y répondre par la même voie.
Merci @Fritz2cat 👍
Message privé envoyé, @EtienneP12 !
Bonjour,
Je suis dans la même situation :
- Prestashop 1.7 / MySQL 8 / RAM 2048Mo
- mysql.log > remplit de "Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead"
- Saturation CPU autour de 15% (Web Cloud Databases MySQL 8 ) d'une durée de 6 à 7 minutes toutes les 40mn environ.
Dans slow-query.log je constate des requêtes récurrentes qui correspondraient aux dates les saturations :
Exemple :
D'après les logs serveurs, ces saturations CPU et ces requêtes SQL lentes correspondent aux appels des filtres par marques présents dans les familles de produits (module Navigation à facettes) par des spiders (exemple ClaudeBot/1.0;).
Est-ce que ces appels du module Navigation à facettes pourraient être effectivement à l'origine des saturations CPU? Si oui, existe t-il une solution qui permettrait de limiter voir éradiquer ces saturations? (autre que de désactiver le module Navigation à facettes).
Merci d'avance.
Thierry
Quelle est la version de votre PHP ?
Si <7.1.16 ou <7.2 alors ce message est normal !
https://www.php.net/manual/en/mysqli.requirements.php
Passez à minima en PHP 7.4.4 puis migrez progressivement en restant dans les clous de la charte de compatibilité PHP/MYSQL de prestashop
Effectivement, PHP est en version 7.0 pour ce site.
Merci pour la piste, je verrai pour changer la version de PHP.