Toon posts:

[MySQL] localhost forwarden naar externe server

Pagina: 1
Acties:
  • 175 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Ik heb een webserver met daarop apache + php4 + mysql-client en ik heb een database server met daarop de mysql server.

Alle scripts op de webserver moeten nu dus met de externe mysql server verbinden, maar de meeste scripts staan ingesteld op "localhost" en het is niet zomaar mogelijk om dit allemaal aan te passen.

Dus komt er een tcp port forwarder om de hoek kijken die poortje 3306 op 127.0.0.1 forward naar de externe mysql server. Connecten naar 127.0.0.1 gaat nu zonder problemen, maar omdat mysql "localhost" gebruikt om te connecten via een unix socket werkt dit niet voor alle scripts.

Nu is hiervoor het tooltje unix2tcp wat netjes unix sockets forward naar een externe server (tcp). Dit werkt opzich vrij aardig, ware het niet dat het soms de soep in loopt bij het inserten van binaire data (scripts die foto's uploaden en in mysql opslaan). Dit is dus ook geen oplossing.

Is het mogelijk om de mysql client te forceren om tcp te gebruiken i.p.v. een unix socket? Dan wordt "localhost" nl. netjes gezien als 127.0.0.1 en werkt de tcp forwarder het net af.

In /etc/my.cnf het volgende regeltje opnemen heeft helaas niet het gewenste resultaat.
code:
1
protocol = tcp


Ook de
code:
1
socket =
regel verwijderen heeft geen resultaat.

In de MySQL manual vind ik wel opties om tcp uit te schakelen (--skip-networking), maar helaas niet het omgekeerde.

Iemand een idee hoe ik alsnog de mysql client kan forceren om via tcp te connecten i.p.v. unix socket?

  • lordgandalf
  • Registratie: Februari 2002
  • Laatst online: 13-02 15:00
waarom kun je in je scripts niet gewoon het andere ip op geven ?
zitten ze er vast in gecode ?
om een site via tcp te laten connecten hoef je toch alleen het ip op te geven samen het password en de user en klaar ben je

Steam: Profile / Socialclub: Profile / Uplay: minedwarf / Origin: lordgandalf3


Verwijderd

Topicstarter
't Probleem is dat het code van klanten is. Dus als we het aanpassen is na een update alles weer foetsie en de klanten zijn helaas te n00b om zelf die scripts aan te passen.

  • TrailBlazer
  • Registratie: Oktober 2000
  • Laatst online: 07-02 09:48

TrailBlazer

Karnemelk FTW

hoezo is na een update alles weer foetsie. Ik denk dat je beter gewoon een script kan schrijven wat alle localhosts vervangt voor iets anders bijvoorbeeld een variabele

  • xtr3me
  • Registratie: Oktober 2001
  • Niet online
Verwijderd schreef op woensdag 19 januari 2005 @ 12:51:
't Probleem is dat het code van klanten is. Dus als we het aanpassen is na een update alles weer foetsie en de klanten zijn helaas te n00b om zelf die scripts aan te passen.
Om hoeveel klanten gaat het, stuur ze desnoods een brief met de aankondiging van deze wijziging :)

Verwijderd

Topicstarter
Daarvoor zijn het helaas iets teveel klanten. Er zullen er minimaal 100 overblijven die de brief negeren of er geen zak van snappen.

  • Gerco
  • Registratie: Mei 2000
  • Laatst online: 13-02 20:06

Gerco

Professional Newbie

Het komt misschien wat laat, maar toen ik in een soortgelijke (maar kleinschalige) situatie zat, heb ik de klanten allemaal vanaf het begin al als database server "dbserver1" laten opgeven. Nu hoefde ik alleen het ip adres van dbserver1 te veranderen en klaar was * Gerco .

Nu heb je daar momenteel niet zoveel aan, maar je zou het alsnog achteraf kunnen doen. Als je de klanten vooraf netjes waarschuwd wat ze moeten doen en ze een redelijke tijd geeft om dat ook echt te doen (een maand of twee). Dan stuur je na 1 maand de klanten die het nog niet gedaan hebben nog een brief en na twee weken en nogeens.

Wie het dan nog niet begrepen heeft is gewoon dom en dan kunnen ze jou ook niet verwijten dat het nu niet meer werkt.

PS. Als ze er geen zak van snappen, hoe hebben ze die scripts dan uberhaupt werkend gekregen?

[ Voor 8% gewijzigd door Gerco op 19-01-2005 15:02 ]

- "Als ik zou willen dat je het begreep, legde ik het wel beter uit!" | All number systems are base 10!


  • TrailBlazer
  • Registratie: Oktober 2000
  • Laatst online: 07-02 09:48

TrailBlazer

Karnemelk FTW

Gerco schreef op woensdag 19 januari 2005 @ 15:01:
PS. Als ze er geen zak van snappen, hoe hebben ze die scripts dan uberhaupt werkend gekregen?
you've got a point :p

Verwijderd

Topicstarter
Dat het eigenlijk in alle scripts aangepast zou moeten worden snap ik ook wel, maar dat is in dit geval niet echt mogelijk. Wellicht dat iemand toch nog een antwoord heeft op de vraag hoe ik mysql kan dwingen tcp te gebruiken i.p.v. unix sockets?

Verwijderd

1) Volgens deze pagina uit het PHP manual zou je een mysql.default_host in php.ini kunnen setten (welke wijst naar je nieuwe DB server). Hierna zullen alle php applicaties die de host niet gespecificeerd hebben (in mysql_connect) automatisch naar deze db server connecten. Echter los je hiermee niet het probleem op voor mensen die localhost hard hebben gedefineerd.

2) Een mailtje naar al je klanten sturen met het verzoek dit te veranderen. Geef hierbij wel een deadline op. Eventueel zou je met wat sh/sed toverwerk alle localhost entries kunnen veranderen in de fqdn van je nieuwe server

3) Forward tcp://dbserver:3306 naar tcp://localhost:3306 (dmv een ssh tunnel oid) en verwijder/verplaatst /tmp/mysql.socket

4) (deze is smerig) je zou in /etc/hosts localhost kunnen herdefineren naar het ip van je nieuwe db server. Echter gaat er dan naar alle waarschijnlijkheid

De meest nette oplossing is (imho) optie 2. Mits je jezelf goed indekt is dit de methode met het meeste resultaat... Mischien dat je met optie 3 nog uit de voeten kunt, maar het is ongetest ...

[ Voor 4% gewijzigd door Verwijderd op 20-01-2005 16:46 ]


Verwijderd

Topicstarter
Verwijderd schreef op donderdag 20 januari 2005 @ 16:45:
1) Volgens deze pagina uit het PHP manual zou je een mysql.default_host in php.ini kunnen setten (welke wijst naar je nieuwe DB server). Hierna zullen alle php applicaties die de host niet gespecificeerd hebben (in mysql_connect) automatisch naar deze db server connecten. Echter los je hiermee niet het probleem op voor mensen die localhost hard hebben gedefineerd.

2) Een mailtje naar al je klanten sturen met het verzoek dit te veranderen. Geef hierbij wel een deadline op. Eventueel zou je met wat sh/sed toverwerk alle localhost entries kunnen veranderen in de fqdn van je nieuwe server

3) Forward tcp://dbserver:3306 naar tcp://localhost:3306 (dmv een ssh tunnel oid) en verwijder/verplaatst /tmp/mysql.socket

4) (deze is smerig) je zou in /etc/hosts localhost kunnen herdefineren naar het ip van je nieuwe db server. Echter gaat er dan naar alle waarschijnlijkheid

De meest nette oplossing is (imho) optie 2. Mits je jezelf goed indekt is dit de methode met het meeste resultaat... Mischien dat je met optie 3 nog uit de voeten kunt, maar het is ongetest ...
Optie 1 werkt zoals je noemt niet voor mensen die localhost invullen, helaas.

Optie 2 zal het ben ik bang definitief gaan worden.

Optie 3 werkt helaas niet, omdat mysql "localhost" afvangt en dan unix sockets gaat gebruiken. tcp poortje 3306 forwarden heeft helaas geen zin.

Optie 4 werkt om die reden ook niet.

Uiteindelijk ben ik maar in de "php mysql extension" source code gaan rommelen en heb daar het stukje waar localhost afgevangen wordt de nek om gedraaid. Dit werkt wel goed, maar bij elke update met de hand patchen is niet echt leuk als je de ports collection van FreeBSD gewend bent ;)

  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 02:47
[rml][ iptables] Poort doorsturen naar andere machine[/rml]

Goh, komt me ineens een oude post heel erg bekend voor :P

Enige nadeel is dat je met PHP standaard een socket connectie maakt op localhost, niet een TCP connectie. Je moet PHP zien te overtuigen dat ie per se via TCP gaat.

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 12-02 13:44
Je kan toch een script maken waarmee je alle sites doorloopt en check naar welke server ze connecten? Eventueel zou je zelfs een handig script kunnen schrijven waarmee je reports kunt maken welke users nog geen aanpassingen gedaan hebben. Je zou het zelfs met een script gewoon zelf aan kunnen passen mocht het nodig zijn al zal je dat alleen kunnen bij eenvoudige scripts waar de logindata hard in de code staat en niet in een config bestandje.
Pagina: 1