problème d'interconnexion distante et individuelle

Version imprimable

10/02/2009, 15h51
Phoenix2001

problème d'interconnexion distante et individuelle

Bonjour à tous,
Voila c'est la première fois sur 10 ans que je post un message sur un forum pour trouver une solution à mon problème.
Sachez qu'il y a une triclée d'administrateur mysql/linux qui se sont penché sur le problème sans trouver de solution.

voici le hic:
j'ai 2 serveurs à configuration identique, sous plesk.
système d'exploitation: Linux 2.6.18-92.el5PAE
version mysql: 5.0.45-7.el5
php: 5.1.6-20.el5_2.1

nous allons definir le serveur A: maitre
et le serveur B: slave à cause de la réplication de mysql (qui fonctionne parfaitement).

Cependant, les exemples de connections (php) vous montrerons le souci.

Connection mysql via script php
Le serveur A arrive a se connecter en localhost (donc a lui même)
Le serveur A n'arrive pas à se connecter VIA sa propre ip ???? vraiment bizarre.
Le serveur A n'arrive pas à se connecter au serveur B (pour interroger les bdd)
Le serveur A RECOIT les connections du serveur B (donc l'ip est visible de l'extérieur ???). ben elle est bonne celle la.

DONC le serveur A se refuse a lui même si il passe par sa propre IP mais il accepte les connections du serveur B ???

Ce n'est pas tout, le meilleur reste à venir, Si on passe les commandes directement dans la console, tout fonctionne ???
mysql -h xx.xx.xx.xx -u Login -ppass (ip du serveur)
mysql -h xx.xx.xx.xx -u Login -ppass (ip du serveur distant)
mysql -h localhost -u Login -ppass

Je précise que la réplication fonctionne, mais malheureusement je souhaite interroger les bases de données du serveur B, et le serveur A veut rien savoir, même pas à sa propre IP.

Quand au serveur B, il n'y à aucun problème.
et sur les deux serveur les iptables sont OK
Les logins et mot de passe sont GRANT et OK.

ET c'est une première pour moi, je poste un message sur un forum parce que j'ai pas la solution, comme quoi que personne n'est parfait.

Bien sur je n'ai pas l'espoir d'avoir une solution car on a déjà tout retourné dans tout les sens et mon dernié recours c'est de carrément changer de serveur, a moins que ....

Merci d'avance de votre participation.

Peux-tu passer ces requêtes ?

Code:

1
2
3
4
5
6
7
8
9
10
 
-- sur le serveur A
SELECT user, host
FROM mysql.user
WHERE user = 'Login utilisé par A pour se connecter à lui-même'
 
-- sur le serveur B
SELECT user, host
FROM mysql.user
WHERE user = 'Login utilisé par A pour se connecter à B'

Citation:
Envoyé par Antoun
Peux-tu passer ces requêtes ?
Code:

1 2 3 4 5 6 7 8 9 10 -- sur le serveur A SELECT User, Host FROM mysql.user WHERE User = 'Login utilisé par A pour se connecter à lui-même' -- sur le serveur B SELECT User, Host FROM mysql.user WHERE User = 'Login utilisé par A pour se connecter à B'
Les deux requêtes fonctionnes, les User's Ont bien étés créé avec les droits qu'ils faut Login %. GRANT (pour les test et en attendant de bloquer sur une IP), c'est de toute manière les mêmes login sur les deux bases histoire de se simplifier la vie.

Au passage joli curriculum ;-)
Merci de votre participation.

10/02/2009, 22h34
Antoun

Merci pour l'appréciation !

En fait la seule explication logique que je vois, c'est que vos users existent en plusieurs versions, du genre login@localhost, login@'192.168.1.1', etc. Or, dans ce cas, il y en a toujours un qui masque l'autre, et ce n'est par nécessairement le bon ni celui auquel on s'attend (cf :faq: http://mysql.developpez.com/faq/?pag...ERS_PB_pb_hote).

Mes requêtes n'avaient donc pas pour but de vérifier l'existence de vos users ni vos GRANT, mais l'unicité desdits users... ce problème serait absurde pour un autre SGBD, mais il est fréquent sous MySQL.
10/02/2009, 23h03
Phoenix2001

Citation:

Envoyé par Antoun

Merci pour l'appréciation !

En fait la seule explication logique que je vois, c'est que vos users existent en plusieurs versions, du genre login@localhost, login@'192.168.1.1', etc. Or, dans ce cas, il y en a toujours un qui masque l'autre, et ce n'est par nécessairement le bon ni celui auquel on s'attend (cf :faq: http://mysql.developpez.com/faq/?pag...ERS_PB_pb_hote).

Mes requêtes n'avaient donc pas pour but de vérifier l'existence de vos users ni vos GRANT, mais l'unicité desdits users... ce problème serait absurde pour un autre SGBD, mais il est fréquent sous MySQL.

Hélas ce fut été trop simple, c'est une des choses qui à été vérifiée en premier lieu, raisonnement logique. Au départ je pensai que c'était un problème de firewall, mais apparemment ce n'est pas le cas.

Ce qui est étonnant c'est que le serveur peut recevoir des connections distantes mais qu'il ne peut pas lui même se connecter à un autre serveur, évidemment çà ne pose pas de problème pour le réplication puisque c'est le serveur distant qui interroge le maître quoi que en console ça fonctionne dans les deux sens.

[root@master ~]# mysql -h IPSLAVE -uLogin -pPass == ok
[root@slave ~]# mysql -h IPMASTER -uLogin -pPass == ok

Le souci reste que je ne peut pas demander au maître de lire l'esclave ni un autre esclave d'ailleurs via php.

Ce n'est pas un problème de script php non plus vu que ceux ci tournent à l'identique sur des serveurs à configuration identique sans aucun problème.

J'ai toujours mon idée qu'il y ai un blocage quelques part au niveau des ports
mais /sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT ne donne rien non plus, j'y croyait pas non plus de toute façon.

J'estime de toute manière que moi même je ne suis pas un pro mais j'ai qmm mes serveurs chez des spécialistes (du moins je le pense) et que ceux ci n'ont pas trouvé de solutions sur 3 jours, j'ai du mal a croire que j'y arriverai aussi ;-).

On me change le serveur Jeudi, mais comme il me convenait très bien et était très rapide, je suis un peu triste.

Quoi qu'il en soit j'ai jusque jeudi pour tenter de trouver une solution et peut être que cela servira à quelqu'un d'autre.

Je suis sur que c'est un truc ton con, comme d'hab...:lol:
13/02/2009, 16h03
Phoenix2001

Problème résolu

Citation:

Envoyé par Phoenix2001

Hélas ce fut été trop simple, c'est une des choses qui à été vérifiée en premier lieu, raisonnement logique. Au départ je pensai que c'était un problème de firewall, mais apparemment ce n'est pas le cas.

Ce qui est étonnant c'est que le serveur peut recevoir des connections distantes mais qu'il ne peut pas lui même se connecter à un autre serveur, évidemment çà ne pose pas de problème pour le réplication puisque c'est le serveur distant qui interroge le maître quoi que en console ça fonctionne dans les deux sens.

[root@master ~]# mysql -h IPSLAVE -uLogin -pPass == ok
[root@slave ~]# mysql -h IPMASTER -uLogin -pPass == ok

Le souci reste que je ne peut pas demander au maître de lire l'esclave ni un autre esclave d'ailleurs via php.

Ce n'est pas un problème de script php non plus vu que ceux ci tournent à l'identique sur des serveurs à configuration identique sans aucun problème.

J'ai toujours mon idée qu'il y ai un blocage quelques part au niveau des ports
mais /sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT ne donne rien non plus, j'y croyait pas non plus de toute façon.

J'estime de toute manière que moi même je ne suis pas un pro mais j'ai qmm mes serveurs chez des spécialistes (du moins je le pense) et que ceux ci n'ont pas trouvé de solutions sur 3 jours, j'ai du mal a croire que j'y arriverai aussi ;-).

On me change le serveur Jeudi, mais comme il me convenait très bien et était très rapide, je suis un peu triste.

Quoi qu'il en soit j'ai jusque jeudi pour tenter de trouver une solution et peut être que cela servira à quelqu'un d'autre.

Je suis sur que c'est un truc ton con, comme d'hab...:lol:

Et bien, comme je le disait la solution était toute simple.
C'est à cause de SELinux .
le système SELinux peut vite devenir un vrai problème si vous souhaitez effectuer des configurations un peu spécifique. Pour désactiver la bête, deux solutions:
La première est d’éditer le fichier /etc/selinux/config et de remplacer la ligne SELINUX=enforcing par:

SELINUX=disabled

puis de rebooter le système.

La seconde, plus rapide et bien utile pour faire des tests est de taper en ligne de commande (root):

# /usr/sbin/setenforce 0

ici, pas de reboot nécessaire.
voir cette page