Ситуация: сервер под управлением RHEL, Apache и т. Д. С mod_proxy. Работал нормально до недавнего перезапуска. Теперь выдает сообщение «(111) В соединении отказано: прокси: HTTP: попытка подключения к <IP>: 8000 (address.com) не удалась».
Больше информации:
1) сервер, к которому он пытается подключиться, является самим собой, но на порту 8000
2) до перезапуска все работало нормально
3) нет никаких свидетельств изменений в httpd.conf или iptables до перезапуска
Я не знаком с mod_proxy, поэтому есть несколько вопросов:
1) требуется ли, чтобы iptables имел открытый порт 8000? «nmap -P0 server -p 8000» показывает, что этот порт закрыт. Нет свидетельств того, что этот порт когда-либо специально открывался.
2) требуется ли, чтобы httpd.conf имел "Listen 8000"? Его там нет.
Так что я озадачен, как это отладить. Это проблема с iptables? или проблема с httpd.conf? Я попытался добавить директиву Listen 8000, но это не устранило проблему. И поскольку файл httpd.conf не редактировался годами, я предполагаю, что этой строки там никогда не было.
Запуск RHEL AS Release 3 (Taroon Update 9) - без SELinux.
Эту систему мне свалил рассерженный бывший сотрудник, который недавно уволился. Он настроил его с помощью многочисленных "наборов инструментов", к которым он подключался с разных сайтов.
Ой.
Итак, вы не хотите, чтобы Apache слушал 8000 - это почти наверняка был другой веб-сервер.
Перед вами стоит небольшая задача судебной экспертизы - другой веб-сервер может быть настроен как служба и не запускается при загрузке (в этом случае должен быть сценарий для него в /etc/init.d, или он может иметь (содрогаться) только началось и nohupСделал вручную после перезагрузки вашим бывшим коллегой.
Если в init.d, лучшим первым шагом может быть проверка пользователя root history чтобы увидеть, похоже ли что-нибудь на запуск программного обеспечения веб-сервера.
Существует просто множество различных вариантов веб-серверов, поэтому трудно специально копаться в системе для веб-серверов в целом, но мы можем сузить круг вопросов. Вы знаете, что использовали эти «инструменты» и какой тип динамического контента они использовали (Java? Ruby? Python?)? Если мы знаем, что это за контент и где он хранится, тогда будет проще отследить веб-сервер, который обрабатывал контент.