xdebug Remote-Debugging mit Port 9000 über ssh-Tunnel weitergeleitet - wie man es funktioniert?

8

Ich habe XAMPP 1.7.3a auf einer "Amazon Linux" (Centos-abgeleiteten) 32-Bit-Instanz in der Amazon EC2-Cloud ausgeführt. Ich habe XDEBUG 2.1.0 heruntergeladen / gebaut / installiert. Die relevanten Einträge in der Ausgabe von phpinfo () sehen folgendermaßen aus:

%Vor%

Ich greife von einem Windows-Laptop mit XP SP3 auf die Linux-Box zu und benutze den SSH-Client in PuTTY Version 0.60. Auch auf dem Laptop habe ich Eclipse PDT installiert (Helios Service Release 1 Build-ID: 20100917-0705), und ich denke, ich habe es richtig konfiguriert XDEBUG Remote-Debugging mit Port 9000 zu tun. Ich sage ich denke , weil ich Schwierigkeiten hatte herauszufinden, wie das geht, und wie man Eclipse PDT im Allgemeinen benutzt. Aber ich habe es geschafft, es zu konfigurieren und arbeiten für "Remote" Debugging von PHP-Code von Webseiten mit XAMPP für Windows 1.7.3 auf localhost (127.0.0.1) mit Port 9000 ausgeführt ausgeführt. Die phpinfo () -Ausgabe für den Server auf dem Laptop, der PDT ist in der Lage zu debuggen ist das gleiche wie oben, außer für:

%Vor%

Ich bin mir ziemlich sicher, dass diese Unterschiede nicht mit dem Problem zusammenhängen. Tatsächlich war xdebug.idekey ursprünglich "root novalue" unter Linux, was ich dann in ECLIPSE_DBGP änderte, indem ich sowohl php.ini als auch die Umgebungsvariable DBGP_IDEKEY in dem sudo-ed-Skript, das Apache startet, vergebe.

Ich habe Firewalls und einen NAT-Router zwischen dem Laptop und der Linux-Box. Also versuche ich die Port-Weiterleitung durch einen PuTTY-SSH-Tunnel zu nutzen, um Linux XDEBUG mit der Windows PDT zu sprechen. Ich habe X11 Forwarding mit PuTTY für ein paar Monate ohne irgendwelche Probleme verwendet. Ich habe den Tunnel in PuTTY eingerichtet, wobei der lokale Port 9000 auf Port 9000 auf der Linux-Box und der Port 9000 auf der Linux-Box auf Port 9000 auf 127.0.0.1 weitergeleitet wurde. Das PuTTY-Tunnel-Panel zeigt:

%Vor%

Wenn Sie das PuTTY-Ereignisprotokoll beim Einrichten des Tunnels betrachten, scheint es keine Probleme zu geben:

%Vor%

Aber wenn ich dann zu PDT gehe und in einer Konfiguration Debugging anklicke, die den Remote-Webserver spezifiziert, zeigt PDT Hintergrundaktivität in der unteren rechten Ecke an, die bei 57% hängen bleibt, und wenn ich auf das Symbol klicke, um zur Fortschrittsansicht zu gehen , das zeigt "Starten: Warten auf XDebug-Sitzung".

Wenn dies geschieht, zeigt das PuTTY-Ereignisprotokoll:

%Vor%

In der Linux-Box zeigt / var / log / secure nur:

%Vor%

Ich habe meine / etc / ssh / sshd_config überprüft, und ich denke, es ist in Ordnung, sogar explizit zu "AllowTcpForwarding ja" ändern, obwohl das der Standard sein soll. In meinem Web sucht nach einer Lösung, ich stieß auf einen linuxquestions Beitrag wo die letzte Antwort etwas kryptisch sagt, dass sshd einen Hostnamen auflösen muss:

  

das schien es zu beheben:   Der Hostname war immer Domain-Serv, seit ich immer   dachte an meinen router als domain.com ... also nach dem rennen    hostname domain.com ... bam! Es funktioniert schließlich ...

     

Ich denke, manchmal ist es zu einfach. sshd musste domain.com auflösen   zu meinem Router ergo die Verbindung fehlgeschlagen.

Ich höre, dass das mit meinem Problem zusammenhängt, aber es ergibt keinen Sinn für mich, und da es ziemlich alt ist und der Autor es auch nicht zu verstehen schien, dachte ich, ich würde hier eher fragen als dort ...

Ich habe bemerkt, dass vor fast einem Jahr eine ähnliche Frage in diesem Forum gestellt wurde, die nur einen 0-Wert hat Antwort, vermutlich weil die Frage so wenig detailliert war, dass sie nicht zu beantworten war. Ich hoffe, dieser hat genug Informationen und ist nicht so lang, dass jemand mich richtig lenken kann. Nachdem ich die FAQs gelesen und eine Frage gestellt hatte, war mir nicht völlig klar, ob die korrekte Verwendung des Forums darin bestand, etwas unter dieser ursprünglichen, nicht so oft gestellten, aber inhaltlichen Frage zu posten oder dieses neue zu veröffentlichen - ich bin mir sicher, dass mir jemand sagen wird, was die richtige Entscheidung ist: -)

Ich bin verrückt geworden mit diesem Ding, und ich vermute, dass es etwas ziemlich Offensichtliches für jemanden mit Erfahrung ist. Ich bin ein Noob zu den meisten dieser Sachen (PHP, Web-Programmierung, Netzwerk-Admin und dieses Forum), aber nicht zu altmodischen C-Programmierung und Benutzer-Ebene Linux und Windows-Setup.

    
sootsnoot 17.11.2010, 01:07
quelle

1 Antwort

4

Wie peinlich, anscheinend war mein Port-Weiterleitungs-Setup etwas, das nur ein Netzwerk-Noob tun würde? Ich vermute, dass ich beschlossen hatte, dass der Xdebug, der auf dem Webserver läuft, mit dem PDT Debugger-Client auf dem Laptop sprechen muss und der PDT Debugger-Client auf dem Laptop auch mit Xdebug auf dem Server sprechen muss, und es gibt nur eine Portnummer (9000), deshalb musste ich den lokalen Port 9000 zum entfernten Port 9000 weiterleiten und auch den entfernten Port 9000 zum lokalen Port 9000 weiterleiten; Ich verwirrte die Richtung des Datenverkehrs mit welcher Seite der Client eine (bidirektionale) Verbindung zu einem bestimmten Port initiiert, auf den die Serverseite hört.

Was passierte, war, dass der PDT-Debugger, der auf dem Laptop lief, nicht weiterkam und darauf wartete, dass Xdebug unter Linux lief, um eine Verbindung herzustellen. Da ich nicht wirklich an eine Situation denken konnte, in der Xdebug Port 9000 abhören musste, wartete man darauf, dass der PDT-Debugger eine Verbindung einleitete (eher würde er auf den PDT-Debugger warten, um ihm einen Befehl über eine Verbindung zu senden Englisch: www.doc-o-matic.com/webhelp/SC_AddInfo.html Als ich den XDEBUG_SESSION Parameter in der Anfrage sah, entschied ich mich, nur die Weiterleitung des lokalen Ports 9000 zum Remote Port 9000 zu entfernen. Ich tat das und plötzlich empfing PDT die Verbindung vom Linux-Server gesendet und das Debugging lief normal von dort ab.

Was mir aber immer noch nicht klar ist, ist warum die zusätzliche Weiterleitung tatsächlich ein Problem verursacht hat. Könnte es nicht möglich sein, dass ein Programmpaar auf verschiedenen Hosts so arbeitet, dass je nach Zustand manchmal der Hörer und manchmal der andere der Hörer war? Solange die Weiterleitung nicht dazu führt, dass beide versuchen, gleichzeitig auf den gleichen Port zu hören, würde ich erwarten, dass das in Ordnung ist.

Das Endergebnis ist, dass die Dinge aufgrund einer Vereinfachung, die ich gemacht habe, jetzt zu funktionieren scheinen, aber ich würde gerne verstehen, warum die unnötige Komplexität tatsächlich ein Problem verursacht hat. Ich habe eine Menge Zeug gelesen, einschließlich der ausgezeichneten Erklärung von SSH und Tunneling in dem O'Reilly-Buch < Ich verstehe es immer noch nicht.

    
sootsnoot 17.11.2010, 03:30
quelle

Tags und Links