Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.UNIX.BSD
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.UNIX.BSD с датами от 18 Jan 11 22:51:00 до 16 Sep 24 17:28:15, всего сообщений: 10763
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 2422 из 10763 ===================================== RU.UNIX.BSD =
От   : Vassily Kiryanov                 2:5054/36          22 Jan 15 11:10:35
Кому : Constantin Stefanov                                 22 Jan 15 11:10:35
Тема : nginx не забирает полный ответ от apache
FGHI : area://RU.UNIX.BSD?msgid=2:5054/36+54c0de36
На   : area://RU.UNIX.BSD?msgid=<1187498950@ddt.demos.su>+663cf70d
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.UNIX.BSD?msgid=<1187498984@ddt.demos.su>+81e7c75d
Ответ: area://RU.UNIX.BSD?msgid=<1187498992@ddt.demos.su>+d0b501ad
==============================================================================
Hi Constantin!

21 Jan 15 13:43, Constantin Stefanov wrote to Vassily Kiryanov:
>>>> VK>> Hаступил на странные грабли. Есть система, на которой
>>>> VK>> несколько джэйлов, для апача, нгинкса, мускуля и прочего - по
>>>> VK>> задаче на джэйл. В в джэйле с апачем22 стоит и php56
>>>> VK>> (хотелось посвежее, но из pkg) вызываемый через suphp. В
>>>> VK>> итоге даже простейший файл с вызовом phpinfo клиенту от
>>>> VK>> нгинкса приходит неполным. В логе ошибок нгинкс строки вида:
>>>> VK>> [alert] 60985#0: *28 writev() failed (13: Permission denied)
>>>> VK>> while sending to client, client: 192.168.x.y

>>>> EG> Permission denied это, возможно, запрет пакетного фильтра.
>>>> EG> Какой файрвол используется?

>>>> Очень похоже, что представление авторов ядра FreeBSD на счёт того,
>>>> как нужно организовывать kernel NAT + ports redirect разительно
>>>> отличается от моего. Самое неприятное: начинаю подозревать, что
>>>> прав в этом заочном споре с ними отнюдь не я...

>> CS> А можно поподробнее о конфигурации?
>> CS> А то у меня примерно похожее (в хостовой системе nginx, в
>> CS> джейлах апачи с php и mysql), и все работает без проблем, и
>> CS> большие файлы ходят. Правда, port mapping  у меня использован
>> CS> только для того, чтоб ssh внутрь джейла пробросить, но через
>> CS> него большие файлы тоже отлично пролезают. Вот suphp нет.

>> Такая конфигурация, которую ты описываешь, у меня тоже работала без
>> проблем. У меня несколько сексуальнее: основная система, своя
>> подсеть адресов, три провайдера интернета (постоянно включены два),
>> в одном джэйле мускуль, в другом нгинкс, в третьем апач, в четвёртом
>> named. С трёх внешних адресов, на которых подняты три kernel-NAT, на
>> 80-й порт джэйла с нгинксом пробросы были через редирект порта. Будь
>> трансляция адресов одной-единственной, оно м.б. и заработало-бы, но
>> обратные пакеты пришлось отправлять через "ipfw nat global", может
>> это помешало. А может я просто не умею этих кошек готовить.

>> Сейчас сделаю, чтобы нгинкс в джэйле слушал на нескольких разных
>> портах и с каждого внешнего адреса по отдельному redirect на
>> _разные_ порты. Это избавит от необходимости ответные пакеты
>> сервисов пропускать через единый "nat global", если заработает -
>> оставлю так. Если не заработает - вообще уберу redirect_port-ы для
>> tcp, и воспользуюсь в основной системе несколькими datapipe (есть в
>> портах, удобная штука).
CS> Ясно, до такого я, действительно, не дошел. Если чего получится -
CS> расскажи, пожалуйста, чтоб знать на будущее.

Сделал, как собирался, конфигурацию на kernel-NAT, но бе "nat global". Появился неожиданный бонус - nginx теперь смог-бы вести логи отдельно по доступу на каждый внешний адрес, только мне это без надобности. Однако, основной результат без изменений - отдаются внешнему клиенту только первые 32-с-чем-то Кб ответа. Плюнул, тут-же поднял datapipe и всё заработало "как доктор прописал". Жотя это некрасиво, т.к. потребует перегонять пакеты через userland и потом отдавать обратно в kernel. Однако это не хуже, чем делать трансляцию адресов плюс редирект портов через natd, который тоже userland. В общем, пока что оставлю схему проброса на datapipe. Чтобы datapipe, имеющий свойство иногда вылетать, не оставил мои сервисы без запросов, нарисовал по-быстрому скрипт, который будет вызываться кроном, вот он:

=== dp-runner.sh ===
#!/bin/sh
#
prog="/usr/local/bin/datapipe"
LogFile='/var/log/datapipe.log'

Virt_Host=prov1_my
Virt_Port=80
Real_Host=jail_web
Real_Port=5080

$prog $Virt_Host $Virt_Port $Real_Host $Real_Port >> /dev/null 2>&1
ExitCode=${?:-255}
# $?=0 - datapipe started OK
# $?=20 - datapipe was already started an now working

if [ x$ExitCode = x0 ]; then
  DateStr=`/bin/date +"%Y-%m-%d %H:%M"`
  echo "$DateStr datapipe ($Virt_Host:$Virt_Port -> $Real_Host:$Real_Port) was started." >> $LogFile
fi

exit

if [ x$ExitCode = x20 ]; then
  DateStr=`/bin/date +"%Y-%m-%d %H:%M"`
  echo At $DateStr datapipe can not bind because address already in use! >> $LogFile 2>&1
fi

exit
=== dp-runner.sh ===

Придётся по отдельному datapipe (и отдельному перезапускающему скрипту) держать для каждого сервиса на каждом из внешних IP, но делать красиво и быстро - не хватает тяму, а делать красиво и не спеша - нет времени.

Всего хорошего.              "За верную и прибыльную дружбу!" (c) Яго.
                Vassily
---
* Origin: И бьется против геноцида Вася, и против Васи геноцид. (2:5054/36)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.088674 секунды