Aller au contenu

Sujets conseillés

Posté

Bonsoir à tous,

Voilà bien longtemps que je n'ai plus participé au forum, d'autres cieux m'ayant appelé auxquels je n'ai pu résister.

Je suis face à un problème, j'espère que je suis bien dans la bonne section, si pas d'avance désolé. Je gère un petit site hébergé sur un mutualisé. Ce site est composé du domaine principal et de trois sous-domaines.

Ce we, en faisant une mise à jour importante du site, je me suis heurté à cette erreur :

Warning : mysql_connect() [function mysql_connect] :Client does not support authentication protocol requested by server, consider upgrading mysql_client + chemin de fichier

Sur trois parties du site : le www, et deux sous-domaines. Un des sous-domaines fonctionnait tout à fait normalement.

La fonction mysql_connect est native, est la même utilisée partout, et est utilisée au sein d'une seule et même classe sur le site entier. Lorsque je rétablis l'ancienne version du site, codée en procédural, aucun souci, tout fonctionne sur tous les domaines.

L'hébergeur me dit que c'est la machine physique qui a planté. Sans autre explication. Je ne suis que développeur autodidacte et amateur, et n'ai aucune connaissance en gestion de serveur.

Pouvez-vous m'éclairer un peu à ce sujet ? Car je ne comprends pas comment c'est possible de planter une même machine, avec les mêmes scripts, sur trois parties et pas la quatrième, pour ensuite fonctionner normalement sans aucune action de ma part si ce n'est le rétablissement du code procédural.

Merci d'avance pour vos réponses !

KM

Posté

Non, ce qui change c'est le passage du procédural à l'objet. Cela fonctionne sur trois domaines (le www et deux sous-domaines) mais pas sur le quatrième.

Posté

Y'a forcément un truc qui change au niveau de la bibliothèque utilisée pour te connecter si la base ne bouge pas.

C'est symptômatique, il faut faire une mise à jour du mot de passe mysql ( http://dev.mysql.com/doc/refman/5.5/en/old-client.htm) pour que la connexion soit raccord avec le nouveau protocole.

Que rien n'ait changé me laisse un peu dans le doute. ( L'hébergeur me dit que c'est la machine physique qui a planté => ça me laisse encore plus dans le doute, tu n'aurais pas ce message )

Posté

Tu passes de quelle version mysql à quelle nouvelle version. :?:

La gestion de l'encodage des mots de passe a changé à partir de la 4.1.

Posté

Je n'ai rien changé du tout au niveau du serveur mysql, je suis sur un mutualisé.

Voilà comment ça fonctionne en résumé :

class_works.php :

class work {

function dbConnect($base,$host,$login,$pass)
{
$dp = mysql_connect($host,$login,$pass) OR DIE ('Le serveur ne répond pas');

mysql_select_db($base, $dp) OR DIE ('Connexion à la base '.$base.' impossible');
}
}

Cette classe est appelée au début du fichier index de chaque répertoire (www, annuaire, blog et forum).

De là, hop, require_once, bufferisation, requêtes, appel des fichiers de templates, hop sortie. Simple comme bonjour.

Cette façon de faire est la même pour les 4 domaines. Je suis autodidacte en la matière et il y a beaucoup de choses qui m'échappent, je bidouille beaucoup. Mais ça n'explique pas ce que j'ai rencontré ici, d'autant que le site en question a connu 4 gros problèmes en un mois.

Une chose, j'ai modifié les bases de données un jour avant la mise à jour. Au départ, je fonctionnais avec 1 seule base dans laquelle je fourrais tout. Pour la mise à jour, j'ai opté pour 4 bases, une pour chaque domaine, et surtout pour chaque application (forum fsb, blog wordpress, annuaire maison et portail maison). Ce principe n'a encore une fois pas posé de problème pour l'un des domaines : l'annuaire.

Idem ensuite, j'ai tout rétabli à l'ancienne, et ça a fonctionné.

Bref, c'est assez confus. Etant sur un mutualisé, je ne peux de toute façon pas paramétrer le serveur mysql. Si je vous contacte, c'est aussi parce que la réponse de l'hébergeur ne me satisfait pas du tout, et que dans le cadre de hacks successifs, beaucoup de questions surgissent.

Est-ce que ça vient de la façon dont sont appelés les fichiers ? J'en doute, c'est pareil pour les 4 domaines, c'est la même classe qui se charge de la connexion, sauf pour le blog et en partie le forum, puisque même sur le forum je bidouille un peu. En local, tout ça fonctionne très bien.

Posté
Au départ, je fonctionnais avec 1 seule base dans laquelle je fourrais tout. Pour la mise à jour, j'ai opté pour 4 bases, une pour chaque domaine, et surtout pour chaque application (forum fsb, blog wordpress, annuaire maison et portail maison).

Si tu es passé de 1 à 4 bases, j'en déduis donc que tu en as créées 3, et conservé la base existance (qui donc a été simplement modifiée).

Or tu nous dis que ça fonctionne parfaitement sur une base et pas sur les trois autres.

La base où ça fonctionne est-elle précisément celle qui n'a pas été crée ? (la base existante) Si oui, alors tu devines déjà que c'est dans la création de la base que tu as dû te louper quelque part.

Ceci n'est que simple supposition à la Sherlok Holmes ;) Difficile d'en savoir plus...

Posté

Tu as quelles versions de mysql et de php ?

Tu peux trouver cette info dans phpMyAdmin, sur la page d'accueil, si tu n'as pas accès au shell Linux.

Posté

Non Ernestine, j'ai créé 4 bases supplémentaires, une pour chaque appli. Donc la création des bases de données est la même. C'est PHPMyAdmin qui a été utilisé pour ça. Et l'application qui tournait (annuaire) travaillait avec une des nouvelles bases.

Dan, le serveur 5.0.51a-24+lenny5, version du client Mysql 5.0.32

Je continue à chercher. Maintenant, il y a un autre problème, c'est que comme le soulignait Jean-Luc, une fois qu'on a été hacké, il faut nettoyer les machines qui ont eu accès au serveur. Je ne l'ai pas fait, résultat des courses ça a effectivement recommencé. Là maintenant, le site ne tourne plus en local, enfin partiellement, alors que je n'ai rien modifié dans le code. Inutile de préciser que je n'arrive pas à trouver le bug, et que la configuration matérielle n'a pas changé sur mon pc.

Maintenant, si vous avez des pistes pour la connexion qui a posé problème, je les prends avec plaisir.

Posté

Manifestement, Php n'a pas été recompilé suite au changement de version de Mysql. Donc l'API ne correspond pas !

Il faut dire à ton hébergeur qu'il DOIT le faire ! C'est son boulot, bordel !

C'est la raison pour laquelle tu as ce message :

Warning : mysql_connect() [function mysql_connect] :Client does not support authentication protocol requested by server, consider upgrading mysql_client + chemin de fichier

De plus, lenny ne sera plus supporté à partir du 6 février. Il serait donc utile pour ton hébergeur de changer de version et passer à Squeeze.

Posté

Ok, c'est du chinois pour moi tout ça, je ne comprends toujours pas pourquoi ça n'a pas fonctionné, mais tant pis. Merci pour vos réponses !

Posté

Pas suivi ... le site est hébergé chez Nuxit. En 4 ans, jamais eu de problèmes, au contraire, par contre depuis un mois ça n'est plus pareil ...

Posté

Dan, je ne comprends toujours pas pourquoi ça a fonctionné sur un domaine et pas sur les autres, est-ce que là tu vois une explication ?! C'est surtout ça qui est interpelant.

La compilation de PHP c'est une chose, mais elle est identique sur tous les domaines, alors ?

Posté

Manifestement tu dois avoir des différences entre les sites...

De toutes manières, Php n'a pas été recompilé pour utiliser la bonne version de l'API de mysql. Et ça n'est pas sérieux de la part de ton hébergeur !

Posté

Oui, sans doute y a-t-il des différences au niveau du code, quelque part, somewhere comme dirait l'autre. Il n'y a que cette explication là qui soit valable. Ou le hack paranoïde. Pourtant c'est la même classe qui établit la connexion, c'est fou. Sans doute une ou l'autre fonction qui fait appel à une connexion, mon niveau n'est pas assez élevé pour le dire, comme je disais je bidouille. En local ça fonctionnait très bien, mais le serveur est plus récent (5.0.45-community-nt, mysql 5.0.45). Finalement, ça n'est pas sérieux de ma part non plus en tant que développeur, j'aurais du vérifier les différences de serveur. En fait j'ai passé un cap dans mon développement avec cette façon de programmer en objet, et j'ai laissé quelques trucs de côté. Bonne leçon.

Là où ce n'est pas sérieux de la part de l'hébergeur non plus, c'est quand il ne répond pas aux questions posées, qu'il digresse continuellement en m'encourageant à passer à une offre supérieure d'hébergement, alors que comme tu me l'apprends, le problème technique vient aussi de chez lui. En fait ils poussent peu à peu leurs clients à migrer vers une v2 d'hébergement, tout simplement.

Je vais ouvrir un autre topic pour les offres d'hébergement. Merci pour ces éclaircissements. :thumbsup:

  • 2 semaines plus tard...
Posté

Dan, petit up, mon hébergeur me dit que tu n'as rien compris, que tu crois que je suis sur un dédié. J'ai bien précisé qu'il s'agissait d'un mutualisé pourtant. :whistling:

Posté

J'avais parfaitement compris que tu étais sur un mutualisé !

C'est d'autant plus INEXCUSABLE de la part de ton hébergeur de ne pas recompiler php lorsqu'il change de version de mysql.

L'API n'est pas la bonne ! C'est peut-être "un imbécile qui n'a rien compris" qui l'annonce, mais dis tout de même à cet hébergeur que je ne manquerai certainement pas de le déconseiller pour cause de son manque de compétence et de ses réponses hors de propos ! :P

Tu devrais peut-être demander, lorsque tu les as au téléphone : "passez-moi quelqu'un qui s'y connait un petit peu"... ça doit tout de même pouvoir se trouver chez eux, non ? Quoique ton dernier post soulève en moi quelques sérieux doutes !

Et pour information, à l'attention de ton hébergeur, un hébergement mutualisé n'est toujours qu'un gros serveur dédié (ou cluster de serveurs, je simplifie délibérément) partagé entre plusieurs clients. La config LAMP est tout à fait comparable. Et ils doivent là aussi recompiler Php lors de chaque changement de version mysql. Ca n'a rien à voir avec la taille du serveur. :P

Je reprends ton message d'erreur :

Warning : mysql_connect() [function mysql_connect] :Client does not support authentication protocol requested by server, consider upgrading mysql_client
ça me semble pourtant facile à comprendre, non ?
Posté (modifié)

Merci pour ta réponse Dan, en fait je rencontre de gros gros soucis qui dépassent allègrement le simple domaine de l'hébergement. Je t'ai un peu chauffé en me doutant bien que tu savais ce que tu racontais, il y a assez longtemps que je passe ici que pour (re)connaître la qualité des intervenants.

Oui pour moi c'est évident également, mais je doute toujours, je suis autodidacte et la gestion de serveur est sans doute le domaine que je connais le moins.

Le site en question est actuellement en proie à diverses manipulations, fraudes, attaques. Ca atteint le domaine personnel et ma vie privée, mon propre pc a été infecté à un moment ou à un autre. Bref ça va loin. Malheureusement pour l'hébergeur, c'est aussi son boulot et il ne le fait pas.

Modifié par KnockedMaster
Posté

Ça ne m'a pas chauffé... mais j'ai été sidéré de lire ce que t'avait dit ton hébergeur.

Il en est vraiment qui feraient mieux de changer de métier :)

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...