Bonjour,


j'ai migré récemment ma fedora 18 en 19 via fedup sans souci. Tout semble fonctionner correctement.

Mais en fait, j'avais juste oublié un détail ; j'ai sur ma machine une webapp (glpi, pour ne pas la nommer) que j'ai installée "à la main" (en prenant le package sur leur site) car lorsque je l'ai installée (il y a longtemps), soit elle n'était pas dispo dans yum, soit je ne l'avais pas trouvée. Celle appli se connecte à une base mysql sur un serveur distant. Du moins, se connectait, car depuis la migration, j'ai une erreur indiquant que la base ne peut être jointe... Je me demande si c'est lié au fait que le package php-mysql, auparavant utilisé je crois bien pour faire cette connexion, semble ne plus exister dans yum ? Du moins, je ne le trouve pas sous ce nom. Peut être que c'est suite à l'abandon de mysql ?

Du coup, mon appli ne fonctionne plus. Je pourrais éventuellement réinstaller la version système de glpi, mais est-ce que cela résoudrait mon problème pour autant ? Car ma base resterait sur le serveur distant, et serait toujours une base mysql, donc j'aurais toujours, je pense, besoin d'un package type php-mysql ?

Merci d'avance pour vos conseils !
il faudrait regarder les log pour voir si cela ne vient pas de mysql connect qui n'est plus admis avec php 5.5; par exemple
Php et mysql ont beaucoup évolués donc une vieille appli fini forcément pas ne plus marcher si on ne la fait pas évoluer...

Gérard
Voir aussi la piste SELinux. Sinon en effet Mysql est remplacé par MariaDB.
Bonjour,

merci pour les réponses. J'ai regardé du côté de selinux, mais pas de message de sa part, donc je ne pense pas que ce soit lui qui bloque.

Par contre, je me suis sans doute mal exprimé : mon serveur mysql est distant, et ce n'est pas une Fedora, donc il n'est pas impacté par le changement en mariadb.

Pour voir, j'ai réinstallé la version de glpi à partir de yum, lors de l'install, lorsqu'il demande les infos sur le serveur mysql et les id, j'ai un message d'erreur indiquant qu'il n'arrive pas à se connecter au serveur...

Du coup je suis perplexe : avec cette version de Fedora, on ne peut plus installer une appli php et se connecter à un serveur mysql distant ? Je n'ai pas bien compris la remarque de Gérard sur le fait qu'en php 5.5, mysql connect n'est plus admis : comment fait on dans ce cas ?
GLPI est disponible depuis très longtemps dans les dépôts. 
yum install glpi
php-mysql est supprimé, remplacé par php-mysqlnd, seul le pilote change, les 3 extensions mysql, mysqli et pdo_mysql sont troujours présente.

L'extension mysql est effectivement dépréciée. Mais cela n'empeche pas son fonctionnement.
Pour info glpi 0.84 utilisera mysqli.

La version actuelle (glpi 0.83.91) fonctionne parfaitement sous f19, php 5.5, mariadb
Le package est compatible Selinux.

Pour l'utilisation d'un MySQL distant, ça fonctionne, il faut juste vérifier que la connexion distante est autorisée sur le serveur MySQL (droits mysql, firewall, ...) et que la connexion réseau est autorisée depuis le serveur GLPI par SELinux (les tests sont d'ailleurs présents dans la phase de "contrôle" de glpi proposée lors de l'installation).
Merci Rémi, mais justement, je viens de faire un "yum install glpi", et à la configuration, j'ai tous les tests ok, mais il n'arrive pas à se connecter à mon serveur distant mysql... alors que la connexion est ouverte (j'y accède d'ailleurs bien en ligne de commande depuis le même pc et avec le même user). D'ailleurs, la connexion a toujours été ouverte, puisque c'était mon serveur pour la base glpi en fedora 18, et je n'ai pas changé en fait ! C'est pour ça que je suis un peu perdue...

Selinux, s'il bloquait, écrirait quelque chose dans les logs génériques genre /var/log/secure ou /var/log/messages ? ou ailleurs ?

Je viens de vérifier, le package php-mysqlnd.i686 et bien installé (version 5.5.0-1.fc19) sur ma Fedora.
Je viens d'installer glpi 0.83.9.1-1.fc19, et j'ai php 5.5.0-1.fc19.

Je ne sais pas si ça peut jouer, mais le serveur mysql est une CentOS 5.5, avec mysql -5.0.95-5.el5_9.

Je vous mets le message d'erreur de l'interface glpi, si ça peut aider : 
Impossible de se connecter à la base de données :
Le serveur a répondu : mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file
Le truc c'est que je n'utilisais pas le "old password"...
Pour être sûre, j'ai tout de même refait un set password pour l'utilisateur, mais j'obtiens tout de même ce même message d'erreur.
à quoi ressemble le mot de passe dans la base ?
select Host,User,Password from mysql.user;
En fait, j'ai trouvé le souci... J'avais bien lancé la commande set password, mais apparemment, elle n'est pas prise en compte, ou du moins, pas comme php le voudrait, tant qu'il reste dans le my.cnf le paramètre "old_password". J'avais lancé la commande PUIS commenté ce paramètre, et à priori, du coup, le mot de passe n'était pas comme php le souhaitait. J'ai relancé la commande avec le paramètre commenté, et là c'est bon, j'ai de nouveau accès à mon interface glpi.

Du coup, j'en ai profité pour installer la version packagée dans Fedora et faire la migration de ma base, et tout s'est bien passé. Cela devrait m'éviter ce genre de soucis à l'avenir !

Merci beaucoup pour toutes les réponses !
Le serveur a répondu : mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file
Donc l'explication était dans le message d'erreur, comme souvent 🙂
Sinon, juste pour info, les logs SElinux sont plutôt dans /var/log/audit/audit.log