У меня XAMPP 1.7.3a работает на 32-битном экземпляре Amazon Linux (производного от Centos) в облаке Amazon EC2. Я скачал / встроил / установил XDEBUG 2.1.0. Соответствующие элементы в выводе phpinfo () выглядят так:
Directive Local Value Master Value
xdebug.idekey ECLIPSE_DBGP ECLIPSE_DBGP
xdebug.default_enable On On
xdebug.remote_autostart On On
xdebug.remote_connect_back Off Off
xdebug.remote_cookie_expire_time 3600 3600
xdebug.remote_enable On On
xdebug.remote_handler dbgp dbgp
xdebug.remote_host 127.0.0.1 127.0.0.1
xdebug.remote_mode req req
xdebug.remote_port 9000 9000
xdebug.remote_log /opt/lampp/logs/xdebug_log
/opt/lampp/logs/xdebug_log
Я получаю доступ к Linux-блоку с ноутбука под управлением Windows XP с пакетом обновления 3 (SP3), используя SSH-клиент в PuTTY версии 0.60. Также на ноутбуке я установил Eclipse PDT (идентификатор сборки Helios Service Release 1 Build ID: 20100917-0705), и я думаю, что он настроен правильно для удаленной отладки XDEBUG через порт 9000. Я говорю, что я думаю , потому что мне было трудно понять, как это сделать и как использовать Eclipse PDT в целом. Но мне удалось настроить его и работать для «удаленной» отладки PHP-кода, выполняемого веб-страницами, обслуживаемыми с помощью XAMPP для Windows 1.7.3 на локальном хосте (127.0.0.1), с использованием порта 9000. Вывод phpinfo () для сервера на ноутбуке с возможностью отладки PDT - 1007 * - то же, что и выше, за исключением:
xdebug.idekey my_username no value
xdebug.remote_host localhost localhost
xdebug.remote_log no value no value
Я почти уверен, что эти различия не связаны с проблемой. Фактически, xdebug.idekey изначально был «корневым именем» в Linux, который я затем изменил на ECLIPSE_DBGP, отредактировав php.ini и установив переменную окружения DBGP_IDEKEY в сценарии sudo-ed, который запускает apache, напрасно надеясь, что все заработает.
У меня есть брандмауэры и маршрутизатор NAT между ноутбуком и Linux. Поэтому я пытаюсь использовать переадресацию портов через ssh-туннель PuTTY, чтобы заставить Linux XDEBUG общаться с Windows PDT. Я использовал пересылку X11 с PuTTY в течение нескольких месяцев без каких-либо проблем. Я установил туннель в PuTTY с локальным портом 9000, перенаправленным на порт 9000 на компьютере Linux, и портом 9000 на компьютере Linux, перенаправленным на порт 9000 на 127.0.0.1, панель туннеля PuTTY показывает:
L9000 host...amazonaws.com:9000
R9000 127.0.0.1:9000
При просмотре журнала событий PuTTY при настройке туннеля проблем не возникает:
2010-11-16 18:07:59 Local port 9000 forwarding to host...amazonaws.com:9000
2010-11-16 18:07:59 Requesting remote port 9000 forward to 127.0.0.1:9000
2010-11-16 18:07:59 Remote port forwarding from 9000 enabled
Но затем, когда я перехожу к PDT и нажимаю «Отладка» в конфигурации, в которой указан удаленный веб-сервер, PDT показывает фоновую активность в нижнем правом углу, которая застревает на 57%, и если я щелкаю значок, чтобы перейти к представлению «Ход выполнения» , который показывает «Запуск: ожидание сеанса XDebug».
Когда это происходит, журнал событий PuTTY показывает:
2010-11-16 19:05:42 Received remote port 9000 open request from 127.0.0.1:54474
2010-11-16 19:05:42 Attempting to forward remote port to 127.0.0.1:9000
2010-11-16 19:05:42 Forwarded port opened successfully
2010-11-16 19:05:42 Opening forwarded connection to host...amazonaws.com:9000
2010-11-16 19:05:42 Forwarded connection refused by server: Connect failed [Connection refused]
2010-11-16 19:05:42 Forwarded port closed
В окне Linux / var / log / secure просто показывает:
Nov 16 19:01:51 ip-10-194-9-67 sshd[14555]: error: connect_to host...amazonaws.com port 9000: failed.
Я проверил мой / etc / ssh / sshd_config, и я думаю, что все в порядке, даже явно изменив его на «AllowTcpForwarding yes», даже если это предполагается по умолчанию. В моих поисках решения в Интернете я наткнулся на одну строку linuxquestions , где в окончательном ответе говорится что-то довольно загадочное о том, что sshd необходимо разрешить имя хоста:
это, кажется, исправило это:
Имя хоста всегда было domain-serv, так как я всегда
думал о моем роутере как domain.com ... так что после запуска
hostname domain.com ... бац! Это наконец работает ...
Наверное, иногда это слишком просто. sshd должен был разрешать domain.com
к моему роутеру, поэтому соединение не удалось.
Похоже, это может быть связано с моей проблемой, но для меня это не имеет никакого смысла, и поскольку оно довольно старое, и автор, похоже, тоже этого не понимал, я решил спросить здесь, а не там ...
Я заметил, что подобный вопрос был задан на этом форуме почти год назад, на который был получен только один ответ с нулевым значением, предположительно потому, что вопрос был настолько недостаточным, что его нельзя было ответить. Я надеюсь, что у этого достаточно информации, и она не такая длинная, чтобы кто-нибудь мог направить меня правильно. После прочтения часто задаваемых вопросов и того, как задать вопрос, для меня не было совершенно очевидно, правильно ли было использовать форум для публикации чего-либо в рамках этого оригинального плохо задаваемого, но идентичного содержанию вопроса, или для публикации этого нового - я я уверен, что кто-то сообщит мне, что было правильным выбором: -)
Я схожу с ума от этой штуки, и я подозреваю, что это что-то довольно очевидное для человека с опытом. Я новичок в большинстве этих вещей (PHP, веб-программирование, администратор сети и этот форум), но не в старомодном программировании на C и настройке Linux и Windows на уровне пользователя.