Конечно, нет никаких проблем положить в X-Real-IP.
Однако, мой вопрос был про REMOTE_ADDR.
пт, 31 мая 2019 г. в 23:13, Vadim A. Misbakh-Soloviov :
> Если проксируется сквозь NginX, то, вроде как, вообще никаких проблем
> положить
> IP в какой-нибудь X-заголовок и брать оттуда...
>
> В письме от
а попробуйте вот так
if (ctx && ctx->ssi) {
сб, 1 июн. 2019 г. в 01:58, Alexey Galygin via nginx-ru :
> понятно, спасибо
> подумаем над отдельным инстансом
>
> на всякий случай я тикет завёл
>
> https://trac.nginx.org/nginx/ticket/1786#ticket
>
> в идеале бы, конечно кэш как-то пересчитывать бы
Если проксируется сквозь NginX, то, вроде как, вообще никаких проблем положить
IP в какой-нибудь X-заголовок и брать оттуда...
В письме от пятница, 31 мая 2019 г. 18:51:15 MSK пользователь Anton Kiryushkin
написал:
> Здравствуйте.
>
> Не подскажете, какова судьба вот этого тикета:
>
Вот бы ещё дождаться per-applicaton access и error-логов (с возможностью
указания путей)... :D
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Есть 3 конфига nginx:
1. общий для всех сайтов (домены типа sub1.site.ru, sub2.site.ru, ... ,
subn.site.ru)
2. общий для для всех статистик сайтов (домены типа stat.sub1.site.ru,
stat.sub2.site.ru, ... , stat.subn.site.ru)
3. общий для всех изображений (домены типа images.sub1.site.ru,
понятно, спасибо
подумаем над отдельным инстансом
на всякий случай я тикет завёл
https://trac.nginx.org/nginx/ticket/1786#ticket
в идеале бы, конечно кэш как-то пересчитывать бы надо после падения воркеров…
On 31 May 2019, 23:50 +0300, ngnx8810773a83 ,
wrote:
> Если воркер отваливается по
Если воркер отваливается по сигналу, то все что им было залочено в кеше
остается залоченым навечно (до перезапуска мастера). Мастер запускает нового
воркера поэтому внешне все продолжает работать,, но если в момент падения
были залочены элементы кеша то ой.. они залочены. снять лок некому,
с тестами попробовал на (тавтология) тестовой среде
худо бедно шло, в целом даже хорошо, но на одном это всё подвисло…
удалось разобрать корки всё же (доставить символы и правильно всё скормить gdb)
как я и предполагал – падает в наших кастомных Perl модулях на уровне nginx при
отправке данных
сб, 1 июн. 2019 г. в 00:34, Alexey Galygin :
> пересобрал с -ggdb
>
> NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # ./nginx -V
> nginx version: nginx/1.16.0
> built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> built with OpenSSL 1.1.1b 26 Feb 2019
> TLS SNI support enabled
> configure arguments:
пересобрал с -ggdb
NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # ./nginx -V
nginx version: nginx/1.16.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -ggdb -O2 -fstack-protector
судя по официальному сборщику (и мы похожим образом делали), отладочные
символы добавляются через --with-debug
http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116
придумаю, что у вас - расскажу)) нет идей
сб, 1 июн. 2019 г. в 00:21, Илья Шипицин :
> у программы, собранной с
у программы, собранной с отладочными символами должно быть вот так (with
debug_info, not stripped)
[ilia@localhost ~]$ gcc -g 1.c
[ilia@localhost ~]$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
теряюсь в догадках. "-g" у вас уже есть.
попробовать поменять "-g" на "-ggdb" ?
сб, 1 июн. 2019 г. в 00:16, Alexey Galygin :
> на CentOS /sbin – симлинк на /usr/sbin
> which nginx даёт /sbin/nginx
>
> но файл тот же
>
> $ file `which nginx`
> /sbin/nginx: ELF 64-bit LSB executable, x86-64,
на CentOS /sbin – симлинк на /usr/sbin
which nginx даёт /sbin/nginx
но файл тот же
$ file `which nginx`
/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not
прошу прощения, не заметил "not stripped" в вашем выводе.
попробуйте добавить в configure вот такую опцию --with-cc-opt="-g"
сб, 1 июн. 2019 г. в 00:01, Alexey Galygin :
> получил плоды ожидания корок
>
> $ file /usr/sbin/nginx
> /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1
покажите вывод
file `which nginx`
?
и такой момент. как можно с минимальным риском подменить бинарник
а) смотрим "nginx -V"
б) берем исходники, компилируем их с всем, что есть в пункте "a)" и
добавляем --with-debug
в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем
руками
получил плоды ожидания корок
$ file /usr/sbin/nginx
/usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
$ nm -g /usr/sbin/nginx | grep main
U
Здравствуйте.
Не подскажете, какова судьба вот этого тикета:
https://github.com/nginx/unit/issues/132
А так же, возможно, есть прямой способ, как получить в php, запускаемом
через unit клиентский айпишник? Сейчас там 127.0.0.1, что очень и очень
плохо и ставит использование unit под жирный
В error_log ничего на сегфолте не может записаться, нет особого смысла его
включать в debug
По bt full больше инфы будет
On Fri, May 31, 2019, 5:26 PM Alexey Galygin wrote:
> Илья, модули все из коробки
>
> ничего лишнего не доливаем
>
> из экстрима, пожалуй, только perl-модуль для ряда мелких
Илья, модули все из коробки
ничего лишнего не доливаем
из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2'
--with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro'
привет!
segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей
nginx.
можете показать вывод "nginx -V" ?
как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с
отладкой, при это не strip-нуть ее в момент инсталяции
команда "file `which nginx`" должна
всем привет
ПРОБЛЕМА
давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
что ряд страниц при обновлении кэша входят в вечный статус UPDATING
см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
происходит это совершенно на рандомных страницах, и
22 matches
Mail list logo
