HAProxy reverse для Virtualmin Admin
Интересно, сделал ли это кто-нибудь еще ..
У меня есть два виртуальных сервера, web -1 и паутина-2. Я настроил HAProxy на нашем брандмауэре PFSense для правильного перехвата web- (1 | 2) .domain. 12 в 64-битной версии CentOS 6.8 через командную строку. Domino 9.0.1 установился без проблем. Когда я запускаю программу установки без вывода сообщений, я получаю следующую ошибку: ...
Я пытаюсь установить IBM Traveler 9.0.1.12 в 64-битной версии CentOS 6.8 через командную строку. Domino 9.0.1 установился без каких-либо проблем.
Когда я запускаю программу установки без вывода сообщений, я получаю следующую ошибку:
[root@traveler]# ./TravelerSetup -f installer.properties -i silent -l en
libgcc_s.so.1 must be installed for pthread_cancel to work
libgcc_s.so.1 must be installed for pthread_cancel to work
libgcc_s.so.1 must be installed for pthread_cancel to work
JVMDUMP039I Processing dump event "abort", detail "" at 2016/08/03 11:54:27 - please wait.
JVMDUMP032I JVM requested System dump using '/tmp/install.dir.1813/core.20160803.115427.1813.0001.dmp' in response to an event
JVMDUMP010I System dump written to /tmp/install.dir.1813/core.20160803.115427.1813.0001.dmp
JVMDUMP032I JVM requested Java dump using '/tmp/install.dir.1813/javacore.20160803.115427.1813.0002.txt' in response to an event
JVMDUMP010I Java dump written to /tmp/install.dir.1813/javacore.20160803.115427.1813.0002.txt
JVMDUMP032I JVM requested Snap dump using '/tmp/install.dir.1813/Snap.20160803.115427.1813.0003.trc' in response to an event
libgcc_s.so.1 must be installed for pthread_cancel to work
Aborted
Согласно документации IBM , для установки в автоматическом режиме я нужны эти библиотеки:
- glibc-2.12-1.7.el6.i686
- libgcc-4.4.4-13.el6.i686
- libstdc ++ - 4.4.4-13.el6.i686
Я сделал Конечно, все эти библиотеки были установлены с помощью yum, но я все равно получаю ту же ошибку. ничего особенного), в котором размещено простое приложение php, с которым мне нужно взаимодействовать из моего основного приложения на ...
У меня есть такая ситуация, которая меня совершенно сбивает с толку:
Настройка
недавно настроенного сервера (centos 7 , apache, mysql, ничего особенного), в котором размещено простое приложение php, с которым мне нужно взаимодействовать из моего основного приложения на другом сервере. Эта служба настроена для работы на service-name.domain.tld, в то время как основное приложение находится на domain.tld (просто упомянув, если это имеет значение).
Проблема
По какой-то причине, когда я пытаюсь получить доступ приложение службы с главного сервера, я получаю бесконечный цикл из 302 перенаправлений.
Если я выполняю curl -D - http: //service-name.domain.tld с главного сервера, я получаю :
HTTP/1.1 302 Found
Date: Wed, 03 Aug 2016 12:30:26 GMT
Server: Apache
Location: http://service-name.domain.tld
Content-Length: 218
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://email-blasts.upgradesale.co">here</a>.</p>
</body></html>
Если я выполняю ту же команду со своего компьютера, результат будет
HTTP/1.1 200 OK
Date: Wed, 03 Aug 2016 12:31:39 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.6.24
X-Powered-By: PHP/5.6.24
Cache-Control: no-cache
Content-Length: 30
Content-Type: text/html; charset=UTF-8
Welcome.
Как и должно быть. То же самое происходит с любым моим запросом (даже со статическими файлами). Также я должен указать, что такая же ситуация происходит с wget и get_file_contents в php
. Я действительно заблудился прямо сейчас, не зная, что делать дальше. Так что любое направление приветствуется.
ОБНОВЛЕНИЕ №1:
Я должен упомянуть, что 2 сервера не находятся в одной сети. Основное приложение размещено на LiquidWeb, а новый сервер - на Linode.
Кроме того, чтобы указать субдомен на сервер Linode, я создал запись A в редакторе DNS CPanel.
Выполнение ping с сервера domain.tld дает:
64 байта с li1014-180.members.linode.com (xx.xx.xx.xxx): icmp_seq = 1 ttl = 64 time = 0,022 мс
Та же команда с моего локального компьютера:
64 байта из (xx.xx.xx.xxx): icmp_seq = 0 ttl = 52 time = 114.982 мс
Следуя Дамиано s инструкции по запуску tcpdump Я обнаружил, что запросы от главного сервера не достигают нового сервера, вместо этого кажется, что главный сервер также отвечает. Квест продолжает выяснять, почему.
Также на главном сервере работает CPanel, так что это может иметь какое-то отношение к этому ...
ОБНОВЛЕНИЕ 2
При выполнении sudo tcpdump -n -i eth0 icmp на служебном сервере , если я ping service-name.domain.tld со своего локального компьютера, я могу видеть входящий и исходящий трафик на сервере, но та же команда, запущенная с главного сервера, не дает мне ничего на сервере службы (то же самое происходит, если я фильтрую http-трафик с помощью tcpdump и делаю запросы curl.)
ОБНОВЛЕНИЕ 3
Я сдался и клонировал Linode, получил новый IP, и теперь он работает нормально ... ¯_ (ツ) _ / ¯
Вы просили «направления», так что ... вот мои.
В ваших двух расшифровках стенограммы я видел, в первом, это:
[...]
Server: Apache
[...]
, а во втором, это:
[...]
Server: Apache/2.4.6 (CentOS) PHP/5.6.24
[...]
Даже если это два разных ответа HTTP ( 302 Найдено первый; 200 ОК второй), держу пари, что эти два ответа приходят от разных веб-серверы. Итак, давайте попробуем исследовать такую гипотезу ...
В качестве первого шага, как уже упоминалось в комментариях @HBruijn, нам необходимо убедиться, что оба HTTP-клиента открывают HTTP-соединение с одним и тем же HTTP-сервером. На каждом из них запустите:
ping service-name.domain.tld
и убедитесь, что в выводе вы видите тот же IP-адрес. Если нет, давайте остановимся на этом и ... вы можете перейти к другой проблеме: -)
Если оба ping разрешают один и тот же IP-адрес, то процесс устранения неполадок действительно отличается на основе «относительного» расположения трех хостов: подключены ли «Клиент A» и «Клиент B» к одной и той же локальной сети / сегменту Ethernet? подключен ли «Сервер C» к одной и той же локальной сети / сегменту Ethernet?
Если три машины подключены к одной и той же локальной сети, то следует проверить MAC-адрес, который получает как «Клиент A», так и «Клиент B» разрешение ARP IP-адреса «Сервера C». Сразу после PING (на «Клиенте A» и «Клиенте B» по сравнению с «Сервером C») запускается (на «Клиенте A» и «Клиенте B») arp -an . Вы получите что-то вроде:
verzulli@iMac-Chiara:~$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
[...]
verzulli@iMac-Chiara:~$ arp -an 192.168.2.1
? (192.168.2.1) associato a c0:c1:c0:e8:0f:12 [ether] su wlan0
verzulli@iMac-Chiara:~$
Здесь выше вы видите, что MAC-адрес моего «сервера» (192.168.2.1) - c0: c1: c0: e8: 0f: 12 . В вашем случае убедитесь, что это одно и то же для «Клиента А» и «Клиента Б». Опять же, обратите внимание, что это действительно только в том случае, если Клиент A и Клиент B находятся в одном сегменте Ethernet с Сервером C .
Если «Клиент A» и «Клиент B» находятся в разных сетях и / или «Сервер C» находится далеко от них, тогда наш единственный шанс - проверить, что поступает на «Сервер C», когда и «Клиент A», и «Клиент B» пытаются связаться с ним. К сожалению, и здесь у нас есть другой подход в зависимости от относительного расположения трех хостов. Предположим наихудший сценарий: «Клиент A» и «Клиент B» подключены к двум разным локальным сетям (возможно, к двум удаленным сайтам большой компании), а «Сервер C» подключен к третьему сайту (штаб-квартира большой компании). . И «Клиент A», и «Клиент B» подключены к NAT при достижении «Сервера C».
В таком случае нам необходимо обнаружить «общедоступный» IP-адрес, назначенный «Клиенту A» и «Клиенту B», когда достигнув «Сервера C». Есть много способов получить эту информацию. В качестве быстрого (... и очень грязного) способа получить результат вы можете запустить:
verzulli@iMac-Chiara:~$ curl -s http://ipinfo.io | grep '"ip":'
"ip": "2.239.77.181",
, где вы можете увидеть, что мой NAT-адрес (назначенный моим провайдером моему хосту при выходе из его сети) равен 2.239 .77.181 .
Итак, теперьНаконец, я могу попросить "Сервер C" показать мне трафик, идущий с моего IP, и ... просто посмотрите, действительно ли что-то входит.
На сервере:
[root@srv-01 ~]# tcpdump -n -i eth0 host 2.239.77.181 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
он .... начнет ждать, для входящих пакетов icmp (ping) с адреса 2.239.77.181. Как только я от клиента сделаю PING, будут показаны такие пакеты:
[root@srv-01 ~]# tcpdump -n -i eth0 host 2.239.77.181 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:28:21.031355 IP 2.239.77.181 > 78.47.127.152: ICMP echo request, id 60237, seq 1, length 64
16:28:21.031392 IP 78.47.127.152 > 2.239.77.181: ICMP echo reply, id 60237, seq 1, length 64
где вы можете увидеть PING (эхо-запрос icmp), исходящий от моего клиента, и, после этого, ответ от сервера (эхо-ответ icmp) .
Если вы предпочитаете проверять все виды трафика (а не только ICMP), вы можете попробовать (на «сервере C») с:
tcpdump -n -i eth0 host 2.239.77.181
из, если вы хотите проверить только HTTP-трафик:
tcpdump -n -i eth0 host 2.239.77.181 and port 80
Вот и все.
На основании вышеизложенного вы должны иметь возможность проверить, достигают ли оба «клиента A» и «клиент B» вашего «сервера C» (а не двух разных веб-серверов). Получив эту информацию, вернитесь сюда, чтобы подтвердить это, и ... Я могу обновить этот ответ, чтобы перейти.