nginx не забирает полный ответ от apache

Vassily Kiryanov написал(а) к All в Jan 15 16:13:26 по местному времени:

Нi All!

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

Без ошибок отрабатывает вызванная в джэйле апача команда
echo "<?php phpinfo(); ?>" | /usr/local/bin/php-cgi

С чего начать поиск причин грабель?

Вот кусок конфигурации nginx
=== Cut ===
server {
listen jailweb:80;
server_name testname.testdomain.ru www.testname.testdomain.ru;
access_log /usr/local/var/websites/www0001/logs/nginx-access.log;
error_log /usr/local/var/websites/www0001/logs/nginx-error.log error;
error_page 404 /404.html;
location / {
proxy_pass http://jailapache:80/;
proxy_redirect off;

proxysetheader Нost $host;
proxyset_header X-Real-IP $remoteaddr;
proxyset_header X-Forwarded-For $proxy_add_x_forwardedfor;

clientmax_bodysize 24m;
clientbody_buffersize 512k;

proxyconnecttimeout 15;
proxysendtimeout 15;
proxyreadtimeout 15;

# proxybuffersize 4k;
# proxy_buffers 4 32k;
# proxybusy_bufferssize 64k;
# proxytemp_file_writesize 64k;
}
# Static files location
# location ~* ^.+\.(html|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt| tar|wav|bmp|rtf|js)$
# { root /usr/local/var/websites/websites/www0001/www; }
}
=== Cut ===

Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.
Vassily
---

Vassily Kiryanov написал(а) к eugen@grosbein.net в Jan 15 12:17:43 по местному времени:

Нi eugen@grosbein.net!

20 Jan 15 18:56, Eugene Grosbein wrote to Vassily Kiryanov:

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

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

Вдогон: дело явно в пересылке ответов от nginx до клиента. Я догадался попробовать запрашивать центральную страницу и через nginx и напрямую от апача.
Вызывал из основной системы
curl --resolve mysite.mydomain.ru:80:jailapache http://mysite.mydomain.ru/ curl --resolve mysite.mydomain.ru:80:jailnginx http://mysite.mydomain.ru/ и ответы получались в первом случае через 61 секунду, но полный, вплоть до закрывающего тега </html> а во втором случае коротенькое "Gateway Timeout" через 15 секунд. Но это заглавная страница, на неё вебмастер всякой хрени натолкал, она тяжёлая слишком.

Аналогично делал с phpinfo.php и оба ответа были полными, за пару секунд.

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

В любом случае, спасибо вам за отклик и помощь.

Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.
Vassily
---

Constantin Stefanov написал(а) к Vassily Kiryanov в Jan 15 11:33:39 по местному времени:

From: Constantin Stefanov <cstef@mail.ru>

Василий, приветствую.

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

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

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

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

--
Константин Стефанов

Если у вас нет паранойи, это не значит, что за вами не следят.
--- ifmail v.2.15dev5.4

Vassily Kiryanov написал(а) к Constantin Stefanov в Jan 15 14:25:16 по местному времени:

Нi Constantin!

21 Jan 15 11:33, Constantin Stefanov wrote to Vassily Kiryanov:

>> VK>> Наступил на странные грабли. Есть система, на которой несколько
>> VK>> джэйлов, для апача, нгинкса, мускуля и прочего - по задаче на
>> VK>> джэйл. В в джэйле с апачем22 стоит и php56 (хотелось посвежее,
>> VK>> но из pkg) вызываемый через suphp. В итоге даже простейший файл
>> VK>> с вызовом phpinfo клиенту от нгинкса приходит неполным. В логе
>> VK>> ошибок нгинкс строки вида: [alert] 60985#0: *28 writev() failed
>> VK>> (13: Permission denied) while sending to client, client:
>> VK>> 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", если заработает - оставлю так. Если не заработает - вообще уберу redirectport-ы для tcp, и воспользуюсь в основной системе несколькими datapipe (есть в портах, удобная штука).

Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.
Vassily
---

Constantin Stefanov написал(а) к Vassily Kiryanov в Jan 15 13:43:16 по местному времени:

From: Constantin Stefanov <cstef@mail.ru>

On 21.01.2015 14:25, Vassily Kiryanov wrote:
>>> VK>> Наступил на странные грабли. Есть система, на которой несколько
>>> VK>> джэйлов, для апача, нгинкса, мускуля и прочего - по задаче на
>>> VK>> джэйл. В в джэйле с апачем22 стоит и php56 (хотелось посвежее,
>>> VK>> но из pkg) вызываемый через suphp. В итоге даже простейший файл
>>> VK>> с вызовом phpinfo клиенту от нгинкса приходит неполным. В логе
>>> VK>> ошибок нгинкс строки вида: [alert] 60985#0: *28 writev() failed
>>> VK>> (13: Permission denied) while sending to client, client:
>>> VK>> 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
> (есть в портах, удобная штука).
Ясно, до такого я, действительно, не дошел. Если чего получится -
расскажи, пожалуйста, чтоб знать на будущее.

--
Константин Стефанов

А Мусоргский - бухал!
--- ifmail v.2.15dev5.4

Vassily Kiryanov написал(а) к Constantin Stefanov в Jan 15 11:10:35 по местному времени:

Нi Constantin!

21 Jan 15 13:43, Constantin Stefanov wrote to Vassily Kiryanov:
>>>> VK>> Наступил на странные грабли. Есть система, на которой
>>>> 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Нost=prov1my
Virt_Port=80
RealНost=jailweb
Real_Port=5080

$prog $VirtНost $Virt_Port $Real_Нost $RealPort >> /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 %Н:%M"`
echo "$DateStr datapipe ($VirtНost:$Virt_Port -> $Real_Нost:$RealPort) was started." >> $LogFile
fi

exit

if [ x$ExitCode = x20 ]; then
DateStr=`/bin/date +"%Y-%m-%d %Н:%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
---

Constantin Stefanov написал(а) к Vassily Kiryanov в Jan 15 11:03:35 по местному времени:

From: Constantin Stefanov <cstef@mail.ru>

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


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

Спасибо.

--
Константин Стефанов

Если у вас нет паранойи, это не значит, что за вами не следят.
--- ifmail v.2.15dev5.4

Valentin Davydov написал(а) к Vassily Kiryanov в Jan 15 13:38:42 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Vassily Kiryanov <Vassily.Kiryanov@f36.n5054.z2.fidonet.org>
> Date: Thu, 22 Jan 2015 11:10:35 +0300
>
>Сделал, как собирался, конфигурацию на kernel-NAT, но бе "nat global". Появился
>неожиданный бонус - nginx теперь смог-бы вести логи отдельно по доступу на
>каждый внешний адрес, только мне это без надобности. Однако, основной результат
>без изменений - отдаются внешнему клиенту только первые 32-с-чем-то Кб ответа.
>Плюнул, тут-же поднял datapipe и всё заработало "как доктор прописал". Жотя это
>некрасиво, т.к. потребует перегонять пакеты через userland и потом отдавать
>обратно в kernel. Однако это не хуже, чем делать трансляцию адресов плюс
>редирект портов через natd, который тоже userland.

Апачи с мускулем у тебя, стало быть, не userland?

Вал. Дав.

--- ifmail v.2.15dev5.4

Vassily Kiryanov написал(а) к Valentin Davydov в Jan 15 17:46:38 по местному времени:

Нi Valentin!

22 Jan 15 13:38, Valentin Davydov wrote to Vassily Kiryanov:

>> From: Vassily Kiryanov <Vassily.Kiryanov@f36.n5054.z2.fidonet.org>
>> Date: Thu, 22 Jan 2015 11:10:35 +0300
>>
>> Сделал, как собирался, конфигурацию на kernel-NAT, но бе "nat
>> global". Появился неожиданный бонус - nginx теперь смог-бы вести логи
>> отдельно по доступу на каждый внешний адрес, только мне это без
>> надобности. Однако, основной результат без изменений - отдаются
>> внешнему клиенту только первые 32-с-чем-то Кб ответа. Плюнул, тут-же
>> поднял datapipe и всё заработало "как доктор прописал". Жотя
>> это некрасиво, т.к. потребует перегонять пакеты через userland и
>> потом отдавать обратно в kernel. Однако это не хуже, чем делать
>> трансляцию адресов плюс редирект портов через natd, который тоже
>> userland.

VD> Апачи с мускулем у тебя, стало быть, не userland?

С чего вдруг такое мнение?
Просто если использовать datapipe вместо redirect_port, то на один выход из kernel в userland плюс вход из userland обратно в kernel будет больше.
Или ты считаешь, что пакеты, попав в распоряжение datapipe, попадут в сервис (ну, хоть тот-же nginx) минуя kernel?
То, что программы, предоставляющие сервисы, крутятся в userland я отрицать и не думал.


Всего хорошего. "За верную и прибыльную дружбу!" (c) Яго.
Vassily
---

Valentin Davydov написал(а) к Vassily Kiryanov в Jan 15 19:12:23 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>

> From: Vassily Kiryanov <Vassily.Kiryanov@f36.n5054.z2.fidonet.org>
> Date: Thu, 22 Jan 2015 17:46:38 +0300
>
>>> From: Vassily Kiryanov <Vassily.Kiryanov@f36.n5054.z2.fidonet.org>
>>> Date: Thu, 22 Jan 2015 11:10:35 +0300
>>>
>>> Сделал, как собирался, конфигурацию на kernel-NAT, но бе "nat
>>> global". Появился неожиданный бонус - nginx теперь смог-бы вести логи
>>> отдельно по доступу на каждый внешний адрес, только мне это без
>>> надобности. Однако, основной результат без изменений - отдаются
>>> внешнему клиенту только первые 32-с-чем-то Кб ответа. Плюнул, тут-же
>>> поднял datapipe и всё заработало "как доктор прописал". Жотя
>>> это некрасиво, т.к. потребует перегонять пакеты через userland и
>>> потом отдавать обратно в kernel. Однако это не хуже, чем делать
>>> трансляцию адресов плюс редирект портов через natd, который тоже
>>> userland.
>
>VD> Апачи с мускулем у тебя, стало быть, не userland?
>
>С чего вдруг такое мнение?

Ну это как бы сарказм. Апач с мускулем на формирование того пакета
угробят столько переключенй контекста (файловые операции, межпроцессное
взаимодействие и т.д.), что прогнать пакет ещё разок через natd незаметно
будет. Единственное, где разница существенна - это отдача тяжёлого статика
nginxом, который умеет sendfile() и тем самым переключает контекст per file,
а не per packet, но это, как ты говорил, не твой случай.

>Просто если использовать datapipe вместо redirect_port, то на один выход из
>kernel в userland плюс вход из userland обратно в kernel будет больше.
>Или ты считаешь, что пакеты, попав в распоряжение datapipe, попадут в сервис
>(ну, хоть тот-же nginx) минуя kernel?
>То, что программы, предоставляющие сервисы, крутятся в userland я отрицать и не
>думал.

Ну так, казалось бы, и нат/редирект можно рассматривать как сервисы и крутить
в юзерланде. А там всё куда проще с настройкой и диагностикой.

Вал. Дав.
--- ifmail v.2.15dev5.4