PDA

Bekijk Volledige Versie : Mysql server weigert website connectie - andere werkt



elles
01/02/11, 00:57
Hallo,

we zijn al even op het forum, maar nog nooit een registratie gemaakt om te posten

We lopen sinds enige dagen tegen een issue aan die ons meer dan kopzorgen oplevert, wellicht is hier iemand die ons kan helpen. Het is een behoorlijk ingewikkeld probleem, hopelijk helpt de uitleg zoals hieronder omschreven. Ik heb geprobeerd het zo duidelijk mogelijk weer te geven.


Netwerk:

webhost 1 locatie A
webhost 2 locatie B

Platform Apache

mysql server 1 Locatie C
mysql server 2 Locatie D

Platform MS 2003 Server
Setup, indeling and my.ini van beide mysql servers zijn identiek
Servers hebben een verschillend IP, in eenzelfde datacenter

Onze oude website (php), op webhost 1, linkt zonder problemen naar mysql server 1



Wij hebben een nieuwe website (php) die tot voor het weekend succesvol linkte naar mysql-server 1 en 2.

Na het wijzigen van wachtwoord voor de mysql-user de nieuwe website kan niet langer contact maken met mysql-server 1 (access denied)
Dezelfde website kan zonder problemen contact maken met mysql-server 2

De nieuwe site kan geen contact maken vanaf webhost 1 en webhost 2
De oude website (op webhost 1) kan nog steeds zonder problemen contact maken met mysql-server 1, en mysql-server 2



Firewall / port is correct geconfigureerd.

User zou alle access moeten hebben op %, localhost
Ik heb geprobeerd de remote host toe te voegen aan user account (op IP) - acces denied

nieuwe user aangemaakt - zelfde probleem
ditzelfde met root user geprobeerd, alle rechten toegekend, geen succes

We hebben het geprobeerd via Mysql administrator, via command line, via Navicat console

als ik show all grants vraag, krijg ik voor % all privileges geretourneerd identified by pass xxx
en daaronder de databases (all privileges)

We hebben een klein / custom php connectie script gemaakt - die kan zonder problemen contact maken met mysql-server 1.


tot slot, en nogmaals
Dit was een 100% werkende setup, tot mysql-server 1 de neiuwe website ging weigeren vanaf alle 2 webhostlocaties



Begin werkelijk grijze haren te krijgen van deze situatie, en hoop dat iemand van jullie evt een oplossing heeft voor deze rare puzzel. herinstallatie van de mysql server is een optie, maar aangezien we 24 services hebben runnen, is dit echt een laatste optie

Als iemand een advies heeft, zou dit enorm op prijs worden gesteld!

systemdeveloper
01/02/11, 01:06
Nieuwe website met nieuw password werkt niet, oude met oud password werkt wel.

Dus de nieuwe user is toch anders geconfigureerd dan de oude of je hebt geen flush privileges gegeven. Let even op de volgorde van de user in de mysql users tabel. De eerste user die mysql vindt en aan de (eventuele wilcard) voldoet, wordt gebruikt en wellicht is daar het password toch niet goed van.

elles
01/02/11, 01:13
Nieuwe website met nieuw password werkt niet, oude met oud password werkt wel.

Dus de nieuwe user is toch anders geconfigureerd dan de oude of je hebt geen flush privileges gegeven. Let even op de volgorde van de user in de mysql users tabel. De eerste user die mysql vindt en aan de (eventuele wilcard) voldoet, wordt gebruikt en wellicht is daar het password toch niet goed van.

dank voor je antwoord, maar helaas dat hebben we echt geprobeerd

Nieuwe website werkt niet met nieuw, en ook niet met oud password. Niet met originele, of nieuwe user, of root. Van geen enkele locatie

De connectie die we maken met de oude website, werkt niet voor de nieuwe website (zelfde host / user)
Maar werkt wel naar de andere mysql server


na alle wijzigingen een flush doorgevoerd van privileges en hosts

Mysql server herstart heeft ook niet geholpen

Vic D'Elfant
01/02/11, 08:11
Even voor de zekerheid: is het echt exact dezelfde setup? Met ander woorden:

Dezelfde MySQL versie (die neem ik aan);
Dezelfde PHP versie;
Dezelfde PHP extensies;
Dezelfde client API version voor de mysql extensie van PHP?
Lezen ze allemaal hun configuratie uit dezelfde php.ini en my.ini?

Je hebt niet riet recentelijk een upgrade van MySQL gedaan?

Verder heb je het over een "oude" en een "nieuwe" website, en dat een test script klaarblijkelijk wel vanaf alle locaties toegang tot krijgen tot beide MySQL-servers. De oorzaak zou dus ook in de hoek van de scripting kunnen liggen, waarbij het probleem ook bij eventuele wijzigingen in de DBAL van de nieuwe webapplicatie kan liggen.

elles
01/02/11, 12:41
Even voor de zekerheid: is het echt exact dezelfde setup? Met ander woorden:


Dezelfde MySQL versie (die neem ik aan);
correct
Dezelfde PHP versie; correct
Dezelfde PHP extensies; correct
Dezelfde client API version voor de mysql extensie van PHP? correct
Lezen ze allemaal hun configuratie uit dezelfde php.ini en my.ini?correct



Je hebt niet riet recentelijk een upgrade van MySQL gedaan?

Nee absoluut niet



Verder heb je het over een "oude" en een "nieuwe" website, en dat een test script klaarblijkelijk wel vanaf alle locaties toegang tot krijgen tot beide MySQL-servers. De oorzaak zou dus ook in de hoek van de scripting kunnen liggen, waarbij het probleem ook bij eventuele wijzigingen in de DBAL van de nieuwe webapplicatie kan liggen.

De nieuwe website heeft toegang tot 1 van de mysql servers, waarbij de setup hetzelfde is. Dat is wat het zo verwarrend maakt, als de scripting niet in orde zou zijn, waarom kan het wel contact maken met de andere server. Dit is getest vanaf 2 webhost locaties.

De oude website heeft toegang tot beide mysql servers


Een update, ik heb het nu gedeeltelijk werkend naar mysql server 2, maar alleen als ik de volledige DNS naam van de webserver van onze webhost invoer. Op ip werkt het niet naar mysql server1, hoe ik het ook probeer of welke rechten ik ook toevoeg.
Mysql server 2 accepteer de connectie zonder rare toevoegingen. Heel verwarrend allemaal

Ramon Fincken
01/02/11, 19:03
Firewall? Mysql user rechten?

Magnetronkip
01/02/11, 19:27
Het lijkt er op dat op de mysql server de remote access is disabled, lokaal wel te bereiken maar vanaf de server niet.

Deze staat blijkbaar op mysql server 1 wel goed ingesteld. Configuratie van mysql servers ook helemaal na gelopen?

Mvg,
Dion

Vic D'Elfant
01/02/11, 19:30
Een update, ik heb het nu gedeeltelijk werkend naar mysql server 2, maar alleen als ik de volledige DNS naam van de webserver van onze webhost invoer. Op ip werkt het niet naar mysql server1, hoe ik het ook probeer of welke rechten ik ook toevoeg.
Mysql server 2 accepteer de connectie zonder rare toevoegingen. Heel verwarrend allemaal
Even "back to basics": bij een nslookup op beide "clients" (websites) krijg je dezelfde IP-adressen? Even zodat we een probleem met bindingen kunnen wegstrepen.

Trouwens, krijg je een timeout of meteen een foutmelding van MySQL zelf? Dan weet je of het iets met de rechten is of de verbinding zelf.

elles
01/02/11, 22:53
Aan Ramon Fincken; aan Magnetronkip;

Nee, dit is niet het geval zoals je kan lezen in mijn eerdere posts.
1 website werkt wel, een werkt niet
Een heel basic php script (dat een connectie maakt op IP) en alleen een simpele select uitvoert in database, werkt ook gewoon

Via Sqlyog en Navicat kan ik de mysql server ook remote benaderen - op IP

Maw, de remote access is mogelijk


Aan Vic D'Elfant;

Ja IP's gebruikt zijn gelijk
Het is een rechten (acces denied) issue, de website maakt wel contact met de server


Zoals gezegd, dit alles is begonnen na een wachtwoord wijziging.
Ik heb het nu wel weer werkend, op een nieuwe user, op DNS naam - op IP werkt nog steeds niet. Maar dit is bijzonder ongebruikelijk natuurlijk en zou betekenen dat iets niet goed is op de Mysql server zelf.

Een te groot risico voor onze diensten om onachtzaam mee om te gaan. Het gaat vooralsnog mijn logica te boven

Vic D'Elfant
02/02/11, 07:45
Vreemd dat de user rechten op % heeft en er niet door komt. Haal voor de aardigheid eens de rechten op localhost weg, zodat er alleen nog % staat?

Check trouwens ook de instelling skip-name-resolve, deze schakelt reverse DNS resolven vanaf de server uit. Dat maakt het verschil tussen rechten op user@192.168.0.1 en user@server02.domain.tld. Het kan geen kwaad om deze eens uit te zetten (ofja, toe te voegen aan my.ini dus) en de rechten op IP-niveau te doen.