Re: Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX
На данный момент - никаких. -- Igor Sysoev > On 19 Jan 2022, at 20:20, Илья Шипицин wrote: > > Какие планы, если не секрет? > > On Wed, Jan 19, 2022, 7:08 PM Igor Sysoev wrote: > Да, всё когда-то заканчивается. > У меня всё хорошо. > У nginx и F5, надеюсь, тоже будет всё хорошо. > > > -- > Igor Sysoev > > > On 19 Jan 2022, at 13:57, Vitaliy Okulov wrote: > > > > Прошла эпоха, надеюсь Игорь хорошо вышел из компании. > > > > вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > > уволился из компании F5 Network, в которой после продажи компании NGINX > > Inc находился в числе технических руководителей проекта NGINX. > > Отмечается, что уход обусловлен желанием проводить больше времени в > > семье и заниматься личными проектами. В компании F5 Игорь занимал > > должность главного архитектора. Руководство разработкой NGINX теперь > > сосредоточится в руках Максима Коновалова, занимающего пост > > вице-президента по инжинирингу группы продуктов NGINX. > > > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > > году практически в одиночку занимался всей разработкой. С 2012 года > > Игорь отстранился от рутинного написания кода NGINX и основную работу по > > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > > Роман Арутюнян. После 2012 года участие Игоря в разработке было > > сосредоточено на сервере приложений NGINX Unit и движке njs. > > > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > > культура и подход к разработке останутся неизменными, как не изменится и > > отношение к сообществу, прозрачности процессов, инновациям и открытому > > коду. Оставшаяся команда разработчиков постарается соответствовать той > > высокой планке, которую задал Игорь. > > > > > > -- > > Best regards, > > Gena > > ___ > > nginx-ru mailing list -- nginx-ru@nginx.org > > To unsubscribe send an email to nginx-ru-le...@nginx.org > > ___ > > nginx-ru mailing list -- nginx-ru@nginx.org > > To unsubscribe send an email to nginx-ru-le...@nginx.org > > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX
Да, всё когда-то заканчивается. У меня всё хорошо. У nginx и F5, надеюсь, тоже будет всё хорошо. -- Igor Sysoev > On 19 Jan 2022, at 13:57, Vitaliy Okulov wrote: > > Прошла эпоха, надеюсь Игорь хорошо вышел из компании. > > вт, 18 янв. 2022 г. в 23:15, Gena Makhomed : > > https://www.opennet.ru/opennews/art.shtml?num=56535 > > Игорь Сысоев ушёл из компаний F5 Network и покинул проект NGINX > > Игорь Сысоев, создатель высокопроизводительного HTTP-сервера NGINX, > уволился из компании F5 Network, в которой после продажи компании NGINX > Inc находился в числе технических руководителей проекта NGINX. > Отмечается, что уход обусловлен желанием проводить больше времени в > семье и заниматься личными проектами. В компании F5 Игорь занимал > должность главного архитектора. Руководство разработкой NGINX теперь > сосредоточится в руках Максима Коновалова, занимающего пост > вице-президента по инжинирингу группы продуктов NGINX. > > Игорь основал NGINX в 2002 году и до создания компании NGINX Inc в 2011 > году практически в одиночку занимался всей разработкой. С 2012 года > Игорь отстранился от рутинного написания кода NGINX и основную работу по > сопровождению кодовой базы подхватили Максим Дунин, Валентин Бартенев и > Роман Арутюнян. После 2012 года участие Игоря в разработке было > сосредоточено на сервере приложений NGINX Unit и движке njs. > > Отмечается, что после ухода Игоря из проекта, созданные при его участии > культура и подход к разработке останутся неизменными, как не изменится и > отношение к сообществу, прозрачности процессов, инновациям и открытому > коду. Оставшаяся команда разработчиков постарается соответствовать той > высокой планке, которую задал Игорь. > > > -- > Best regards, > Gena > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org > ___ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org ___ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
Re: Разный контент для пользователей разных сетей
Возможно, кэширование в браузере. Попробуйте curl’ом. -- Igor Sysoev > On 31 Mar 2021, at 21:30, budarin wrote: > > Игорь, спасибо за ответ! > > но к сожалению получаю global в локальной сети на машине где стоит nginx и > где тестирую > похоже что не срабатывает geo модуль - как можно проверить? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,291116,291118#msg-291118 > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Разный контент для пользователей разных сетей
geo $geo {
default global;
192.168.1.0/24 local;
}
server {
location / {
index $geo.html;
}
location = /global.html {
internal;
}
location = /local.html {
internal;
}
}
--
Igor Sysoev
> On 31 Mar 2021, at 20:59, budarin wrote:
>
> Нужно отдавать разный index.html для локальных пользователей и пользователей
> интернета
> Делаю так
>
>location /local.html {
>allow 192.168.1.0/24;
>deny all;
>internal;
>}
>
>location /global.html {
>deny 192.168.1.0/24;
>allow all;
>internal;
>}
>
>location / {
>try_files /global.html /local.html =404;
>}
>
> пользователи локальной сети видят global.html да и напрямую если указать урл
> конкретного документа имеется доступ (
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,291116,291116#msg-291116
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx. редирект урла без слеша в конце?
Уберите реврайты из конфига, возможно срабатывает какой-то реврайт.
location /ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo/
return 301
https://apteka-ds.com.ua/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/;
}
--
Igor Sysoev
> On 15 Jul 2020, at 16:31, akoval wrote:
>
> location /ua/about/loyalty-program { return 301
> https://apteka-ds.com.ua/discount; }
> location /ua/about { return 301 https://apteka-ds.com.ua/about-us permanent;
> }
> location /ua/about/contacts { return 301 https://apteka-ds.com.ua/contacts
> permanent; }
> location /ua/files/docs/loyalty/Договір_Клієнта.pdf { return 301
> https://apteka-ds.com.ua/loyalty/Договір_Клієнта.pdf permanent; }
>
> # articles
> rewrite /ua/articles/koronavirus-vse-shcho-potribno-znaty-pro-nogo/
> https://apteka-ds.com.ua/blog-item/koronavirus-vse-shcho-potribno-znaty-pro-noho/
> permanent;
>
>
> в данном контексте при заходе на
> http://apteka-ds.com.ua/ua/about/loyalty-program
> перекидає на https://apteka-ds.com.ua/about-us
> ?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx. редирект урла без слеша в конце?
> On 15 Jul 2020, at 15:13, akoval wrote:
>
> Напр:
> rewrite http://site1.com/aaa/ https://site1.com/bbb permanent; - работает
> rewrite http://site1.com/aaa https://site1.com/bbb permanent; - а так уже не
> хочет
>
> Пробую разные регулярки, но пока не работает:
> rewrite ^/ua/about/loyalty-program/?$ https://apteka-ds.com.ua/discount
> permanent;
location /ua/about/loyalty-program {
return 301 https://apteka-ds.com.ua/discount;
}
--
Igor Sysoev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
> On 7 Apr 2019, at 22:16, Anton Kiryushkin wrote:
>
> Я взял код из лога и попробовал его собрать ровно так, как написано.
> Строка моего configure следующая:
> ./configure --prefix=/usr --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error.log
> --http-client-body-temp-path=/var/lib/nginx/body
> --http-fastcgi-temp-path=/var/lib/nginx/fastcgi
> --http-log-path=/var/log/nginx/access.log
> --http-proxy-temp-path=/var/lib/nginx/proxy
> --http-scgi-temp-path=/var/lib/nginx/scgi
> --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock
> --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module
> --with-http_dav_module --with-http_geoip_module
> --with-http_gzip_static_module --with-http_realip_module
> --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module
> --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl
> --add-module=/usr/src/naxsi/naxsi_src --with-debug --with-http_v2_module
> --with-cc-opt="-static -static-libgcc" --with-ld-opt="-static -lm"
> --with-cpu-opt=generic --with-openssl=./openssl-1.0.2r --with-stream
> --with-stream_ssl_module --user=www-data --with-http_image_filter_module
>
> Что-то тут уже устаревшее, но это не очень важно.
> Выпадает ошибка:
> checking for GD library ... not found
> checking for GD library in /usr/local/ ... not found
> checking for GD library in /usr/pkg/ ... not found
> checking for GD library in /opt/local/ ... not found
>
> Окей. Берем код автотеста:
>
> #include
> #include
> #include
>
> int main(void) {
> gdImagePtr img = gdImageCreateFromGifPtr(1, NULL);
> (void) img;
> return 0;
> }
>
> Собираем:
> cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
> /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib
> -lgd (строчка из того же лога).
> Не собирается.
> Однако, если подвинуть -lm в конец:
> cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I
> /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd
> -lm
>
> Все соберется.
>
> Вопрос, как передвинуть на уровне сборки?
Штатно не двигается.
Можно добавить в auto/lib/libgd/conf:
- ngx_feature_libs="-L/usr/pkg/lib -lgd"
+ ngx_feature_libs="-L/usr/pkg/lib -lgd -lm"
В динамической libgd.so зависимость от libm.so записана,
а в статической такой возможности нет.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
А статическая libm.a есть? Можно попробовать поставить -lm до -static: --with-ld-opt="-lm -static ... -- Igor Sysoev http://nginx.com > On 6 Apr 2019, at 14:57, Anton Kiryushkin wrote: > > Ситуация очень напоминает предыдущую: > > cc -static -static-libgcc -lm -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -lm -L/usr/pkg/lib > -lgd > -- > > > checking for GD library in /opt/local/ > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > collect2: error: ld returned 1 exit status > -- > > Версия nginx 1.15.10. gcc version 4.8.2. > > сб, 6 апр. 2019 г. в 12:14, Igor Sysoev : > А что в autoconf.err ? > > -- > Igor Sysoev > http://nginx.com > > > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > > > Добавил и не помогло. > > > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > > > Здравствуйте. > > > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может > > > собраться статически с libgd: > > > > > > -- > > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > > > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib > > > -lgd > > > -- > > > > > > > > > checking for GD library in /opt/local/ > > > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > > collect2: error: ld returned 1 exit status > > > -- > > > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > > > действительно нужна статическая сборка
Re: Статическая сборка nginx с GD
А что в autoconf.err ? -- Igor Sysoev http://nginx.com > On 6 Apr 2019, at 14:07, Anton Kiryushkin wrote: > > Добавил и не помогло. > > сб, 6 апр. 2019 г. в 11:06, Igor Sysoev : > > On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > > > Здравствуйте. > > > > Подскажите, пожалуйста, почему nginx в данном случае никак не может > > собраться статически с libgd: > > > > -- > > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib > > -lgd > > -- > > > > > > checking for GD library in /opt/local/ > > > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > > collect2: error: ld returned 1 exit status > > -- > > > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > > действительно нужна статическая сборка. Остается страдать и все же так не > > делать или есть способ что-то тут сделать? > > Нужно добавить "-lm" в --with-ld-opt > > > -- > Igor Sysoev > http://nginx.com > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > -- > Best regards, > Anton Kiryushkin > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Статическая сборка nginx с GD
> On 6 Apr 2019, at 12:54, Anton Kiryushkin wrote: > > Здравствуйте. > > Подскажите, пожалуйста, почему nginx в данном случае никак не может собраться > статически с libgd: > > -- > cc -static -static-libgcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I > /usr/pkg/include -o objs/autotest objs/autotest.c -static -L/usr/pkg/lib -lgd > -- > > > checking for GD library in /opt/local/ > > /opt/local/lib/libgd.a(gd.o): In function `lsqrt': > /usr/src/libgd/src/gd.c:1722: undefined reference to `sqrt' > /opt/local/lib/libgd.a(gd.o): In function `gdImageDashedLine': > /usr/src/libgd/src/gd.c:1471: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1471: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1520: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1520: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageLine': > /usr/src/libgd/src/gd.c:1394: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1394: undefined reference to `sin' > /usr/src/libgd/src/gd.c:1333: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:1333: undefined reference to `cos' > /opt/local/lib/libgd.a(gd.o): In function `gdImageAALine': > /usr/src/libgd/src/gd.c:3514: undefined reference to `atan2' > /usr/src/libgd/src/gd.c:3514: undefined reference to `sin' > /opt/local/lib/libgd.a(gd.o): In function `gdImageCopyRotated': > /usr/src/libgd/src/gd.c:2792: undefined reference to `sincos' > /usr/src/libgd/src/gd.c:2791: undefined reference to `sqrt' > collect2: error: ld returned 1 exit status > -- > > Сам libgd собран в /opt/local с флагом static. К сожалению, мне > действительно нужна статическая сборка. Остается страдать и все же так не > делать или есть способ что-то тут сделать? Нужно добавить "-lm" в --with-ld-opt -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
NGINX to Join F5
Сегодня исторический день для NGINX. Мы подписали соглашение о присоединении к компании F5. Команда и я считаем это событие значимым этапом для наших открытых проектов, сообщества и компании. Для F5 крайне важны наши freeware opensource проекты. Мы не планируем никаких изменений в их названиях, лицензиях, командах разработчиков, периодичности выпусков и во всё остальном. F5 приложит все усилия, чтобы проекты NGINX были ещё лучше. Наш CEO Гас Робертсон написал об этом более подробно: https://www.nginx.com/blog/nginx-joins-f5/ -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Nginx Unit + Ruby from rvm.io
> On 17 Jul 2018, at 14:21, Reborns wrote: > > Приветствую. > Суть вопроса ... можно ли как то использовать юнит если руби стоит не из APT > ? Тоесть в системе есть ruby и rack .и все это работает на nginx + > passenger .. но как обяснить юниту что бы смотрел не в /usr/lib/ruby а в > /usr/local/rvm/gems/ruby-2.4.1 итп. итд. > > для passenger а например в конфиге nginx а есть настройки типа... > >passenger_root /usr/local/rvm/gems/ruby-2.4.1/gems/passenger-5.3.3; >passenger_ruby /usr/local/rvm/gems/ruby-2.4.1/wrappers/ruby; >passenger_env_var PATH > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; > > > Хочу отказаться от пассенджера в пользу юнита , но при условии что руби > будет ставиться не из пакетов а через RVM .. Для этого придётся собрать unit из исходников с нужными параметрами, например, так: ./configure --prefix=/usr/local/ Возможные параметры можно посмотреть так: ./configure --help Какие параметры используются в уже собранном unitd, можно узнать так: /path/to/unitd --help После этого нужно сконфигурировать модуль ruby: ./configure ruby --ruby=/usr/local/rvm/gems/ruby-2.4.1/bin/ruby Потом собрать и установить: make sudo make install Итак, всё вместе: ./configure --prefix=/usr/local/ ./configure ruby --ruby=/usr/local/rvm/gems/ruby-2.4.1/bin/ruby make sudo make install -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx конфиг для домена
> On 17 Mar 2018, at 12:52, iuerhiguerhg wrote:
>
> подскажите пожалуйста что прописать в location конфига домена чтоб при
> запросе domain.com/1.html отдавало /var/www/www-root/25.html
location = /1.html {
alias /var/www/www-root/25.html;
}
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
> On 23 Nov 2017, at 19:28, Gena Makhomed wrote: > > Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx: > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html Интересно, откуда он это придумал про двойной fork()? Во FreeBSD используется только один fork() что в 2017 году: https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025&view=co что в 1994: https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573&view=co -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
> On 20 Oct 2017, at 22:50, Andrey Oktyabrskiy wrote: > > Andrey Velikoredchanin wrote: >> Кстати, а для perl предвидится реализация модуля? Он, конечно, староват, >> но на нем еще много чего написано и пишется. > Я бы обобщил вопрос: насколько сложно пришить к юниту новый интерпретатор? С точки зрения юнита, языки делятся на две категории: 1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют некий стандартный интерфейс для встраивания в веб-сервер; 2) встраивание модуля юнита в приложение: Go, Node.js, Java. Первое сделать, как правило, проще. Но перл не в ближних планах, поскольку его популярность падает. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
> On 20 Oct 2017, at 22:03, S.A.N wrote: > > Будет хорошо создать здесь отдельные maillist для Unit. http://mailman.nginx.org/mailman/listinfo/unit Но это только английский. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
> On 20 Oct 2017, at 18:21, Виктор Вислобоков wrote: > > Ничего накладного не вижу. nginx релоадится вообще прозрачно и незаметно. В 2002 году я тоже так думал. А вообще есть сайты с тысячами SSL-сертификатов, переконфигурованием раз в минуту и соединениями, живущими сутками, из-за которых в памяти висят тысячи воркеров. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
> On 20 Oct 2017, at 17:34, Виктор Вислобоков wrote: > > >> В unit главный процесс сначала форкается, а потом динамически подгружает > >> нужный модуль, который слинкован с соответствующей версией php/python. > >> Поэтому можно одновременно запускать разные версии языков. > Эээ... не совсем понял. > А вот этот "нужный модуль" это часть Unit? Если да, то каким образом > достигается его линковка например с разными версиями PHP одновременно? Или > это целый набор "нужных модулей" каждый под нужную нам версию PHP? Если да, > то получается мы должны собрать каждый такой "нужный модуль" для каждой > версии PHP которую планируем использовать? Да: ./configure ./configure php --config=php53-config --module=php53 ./configure php --config=php71-config --module=php71 make В build будут собраны php53.unit.so и php71.unit.so. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: unit-0.2 beta release
> On 20 Oct 2017, at 17:21, Slawa Olhovchenkov wrote: > > On Fri, Oct 20, 2017 at 05:13:37PM +0300, Виктор Вислобоков wrote: > >>>> Так в таком случае использование unit еще выгоднее: ему не надо держать >> master-процесс для каждой версии php, не говоря о процессе для каждого >> пользователя. >> Не представляю как это будет работать. >> Возьмём mod_php для апача - весь PHP грузится модулем в веб-сервер (а >> безопасность обеспечивает скажем mod_ruid, переключая userid), но в этом >> случае не получится загрузить в один веб-сервер несколько версий этого >> модуля. > > на самом деле загрузить-то получится (наверное, не проверял), а вот > активировать нужный для конкретно URL может быть проблемой. > > впрочем, возможно проблему решит правка сырцов для замены директив > php_* на phpXY_*. > > в любом случае, nginx unit не решает проблему с pear и pecl, например, в > случае php (и я не смотрел как он решает проблему с собственно php > разных версий). В unit главный процесс сначала форкается, а потом динамически подгружает нужный модуль, который слинкован с соответствующей версией php/python. Поэтому можно одновременно запускать разные версии языков. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
unit-0.2 beta release
http://unit.nginx.org Changes with Unit 0.219 Oct 2017 *) Feature: Go package improvements. *) Feature: configuration persistence. *) Feature: improved handling of configuration errors. *) Feature: application "timeout" property. *) Bugfix: Go application crashed under load. *) Bugfix: POST request for PHP were handled incorrectly. *) Bugfix: the router exited abnormally if all listeners had been deleted. *) Bugfix: the router crashed under load. *) Bugfix: memory leak in the router. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginScript response.status равен 0
On 10 Jun 2017, at 19:15, Дмитрий Герасимов wrote: > Всем доброго дня. Вопрос по сути в названии темы - > https://nginx.org/ru/docs/http/ngx_http_js_module.html > > "Объект ответа имеет следующие свойства: > > status > статус ответа, доступно для записи" > > Понадобилось мне при условии response['status'] === 200 добавить заголовок и > оказалось, что он равен 0. Это так и задумывалось или ошибка? Ну и как в > этом случае задать условие? nginScript - пока не умеет фильтровать ответы, а может только создавать. Он должен сам поставить нужный response.status. До этого момента статус равен нулю. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NJS module string to lowercase
On 28 Aug 2016, at 11:48, Alexander Moskalenko
wrote:
> В spec для 1.10.1 RPM прописано -add-dynamic-module=njs-1c50334fbea6/nginx
Это версия как раз перед добавлением toLowerCase:
changeset: 100:b7442865d9fa
user: Igor Sysoev
date:Fri Apr 15 18:01:19 2016 +0300
summary: String.toLowerCase().
changeset: 99:1c50334fbea6
user: Igor Sysoev
date:Thu Apr 14 18:23:09 2016 +0300
summary: "new Date()" incorrectly returned always Jan 1, 1970.
В mainline 1.11.3 более современная.
--
Igor Sysoev
Join us at nginx.conf, Sept. 7-9, Austin, TX: http://nginx.com/nginxconf
> 2016-08-28 10:39 GMT+02:00 Roman Arutyunyan :
> Речь идет про версию njs, а не nginx.
>
> On Sun, Aug 28, 2016 at 10:26:58AM +0200, Alexander Moskalenko wrote:
> > Игорь, можно подробнее про версию?
> > Сейчас стоит nginx version: nginx/1.10.1
> >
> > И где можно документацию смотреть?
> >
> > 2016-08-28 9:17 GMT+02:00 Igor Sysoev :
> >
> > > On 27 Aug 2016, at 21:04, Alexander Moskalenko <
> > > alexander.moskale...@gmail.com> wrote:
> > >
> > > Приветствую!
> > >
> > > Есть локейшн задача которого делать редирект с приведением uri к нижнему
> > > регистру.
> > > В данный момент используется LUA, который хотелось бы заменить на "родной"
> > > модуль.
> > >
> > > LUA блок выглядит так:
> > > location ~ [A-Z] {
> > > rewrite_by_lua_block {
> > > return ngx.redirect((string.lower(ngx.var.uri)),301);
> > > }
> > > }
> > >
> > > NJS блок:
> > > js_run "function f(req, res) {
> > > res.status = 301;
> > > res.headers.location = req.uri.toLowerCase();
> > > res.sendHeader();
> > > res.finish();
> > > }";
> > >
> > > упорно получаю js exception: TypeError
> > >
> > > Вопрос: что я делаю не так?
> > > typeof(req.uri) возвращает string
> > > т.к. документации толком нет пытаюсь использовать "родные" методы JS
> > >
> > >
> > > Должно работать. Скорее всего, используется старая версия,
> > > в которой toLowerCase ещё не было.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NJS module string to lowercase
On 27 Aug 2016, at 21:04, Alexander Moskalenko
wrote:
> Приветствую!
>
> Есть локейшн задача которого делать редирект с приведением uri к нижнему
> регистру.
> В данный момент используется LUA, который хотелось бы заменить на "родной"
> модуль.
>
> LUA блок выглядит так:
> location ~ [A-Z] {
> rewrite_by_lua_block {
> return ngx.redirect((string.lower(ngx.var.uri)),301);
> }
> }
>
> NJS блок:
> js_run "function f(req, res) {
> res.status = 301;
> res.headers.location = req.uri.toLowerCase();
> res.sendHeader();
> res.finish();
> }";
>
> упорно получаю js exception: TypeError
>
> Вопрос: что я делаю не так?
> typeof(req.uri) возвращает string
> т.к. документации толком нет пытаюсь использовать "родные" методы JS
Должно работать. Скорее всего, используется старая версия,
в которой toLowerCase ещё не было.
--
Join us at nginx.conf, Sept. 7-9, Austin, TX
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подмена бинарника в докере
On 05 May 2016, at 18:55, Anton Bessonov wrote: > On 26.04.2016 22:19, Igor Sysoev wrote: >> On 26 Apr 2016, at 19:27, Anton Bessonov wrote: >> >>> Спасибо большое, работает. И с демонизацией тоже. >>> >>> Но наблюдаю эффект, что если убить мастера, то воркер остаётся один. И >>> только после убивания воркера ломается контейнер. Можно сделать как-то >>> (trap?), что бы контейнер или воркер с мастером ломались? А то состояние >>> странное. >> Убить как - kill -9 или просто kill ? Во втором случае воркеры должны >> выходить. >> > Как kill -9. С просто kill воркер выходит. По kill -9 мастер уже ничего не может сделать. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подмена бинарника в докере
On 26 Apr 2016, at 19:27, Anton Bessonov wrote: > Спасибо большое, работает. И с демонизацией тоже. > > Но наблюдаю эффект, что если убить мастера, то воркер остаётся один. И только > после убивания воркера ломается контейнер. Можно сделать как-то (trap?), что > бы контейнер или воркер с мастером ломались? А то состояние странное. Убить как - kill -9 или просто kill ? Во втором случае воркеры должны выходить. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подмена бинарника в докере
On 25 Apr 2016, at 22:55, Anton Bessonov wrote: > Так и есть, ppid становится 1: Всё должно работать. Можно даже "daemon off” не ставить. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подмена бинарника в докере
On 25 Apr 2016, at 20:33, Anton Bessonov wrote: > Здравстуйте, > > на сколько я помню, то энджин не посзоляет обновлять конфигурацию, если > менять параметры некоторых директив, таких как пути к кэшам. Актуально > использую подмену бинарника - вроде помогает. > > Сейчас эксперементирую с тем же самым, только в контейнере. По умолчанию > энджин имеет PID 1, что убивает контейнер после kill -QUIT 1. > > В docker-compose делаю следующее: > > version: '2' > services: > nginxt: >image: nginx >ports: > - "6283:80" >command: /bin/bash -c '$$(exec /usr/sbin/nginx -g "daemon off;")' > > Вроде работает: > > # ps auxf > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 7 0.1 0.3 20224 3208 ?Ss 17:07 0:00 bash > root12 0.0 0.2 17496 2064 ?R+ 17:07 0:00 \_ ps auxf > root 1 0.0 0.2 20044 2704 ?Ss 17:06 0:00 /bin/bash -c > $(exec /usr/sbin/nginx -g "daemon off;") > root 5 0.0 0.4 31684 4860 ?S17:06 0:00 nginx: > master process /usr/sbin/nginx -g daemon off; > nginx6 0.0 0.2 32068 2860 ?S17:06 0:00 \_ nginx: > worker process > > # kill -USR2 5 > # ps auxf > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 7 0.0 0.3 20224 3208 ?Ss 17:07 0:00 bash > root15 0.0 0.2 17496 2048 ?R+ 17:08 0:00 \_ ps auxf > root 1 0.0 0.2 20044 2704 ?Ss 17:06 0:00 /bin/bash -c > $(exec /usr/sbin/nginx -g "daemon off;") > root 5 0.0 0.4 31684 4860 ?S17:06 0:00 nginx: > master process /usr/sbin/nginx -g daemon off; > nginx6 0.0 0.2 32068 2860 ?S17:06 0:00 \_ nginx: > worker process > root13 0.0 0.4 31688 5080 ?S17:08 0:00 \_ nginx: > master process /usr/sbin/nginx -g daemon off; > nginx 14 0.0 0.2 32068 2880 ?S17:08 0:00 \_ nginx: > worker process > > # kill -WINCH 5 > # ps auxf > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 7 0.0 0.3 20224 3208 ?Ss 17:07 0:00 bash > root16 0.0 0.1 17496 1956 ?R+ 17:09 0:00 \_ ps auxf > root 1 0.0 0.2 20044 2704 ?Ss 17:06 0:00 /bin/bash -c > $(exec /usr/sbin/nginx -g "daemon off;") > root 5 0.0 0.4 31684 4860 ?S17:06 0:00 nginx: > master process /usr/sbin/nginx -g daemon off; > nginx6 0.0 0.2 32068 2860 ?S17:06 0:00 \_ nginx: > worker process > root13 0.0 0.4 31688 5080 ?S17:08 0:00 \_ nginx: > master process /usr/sbin/nginx -g daemon off; > nginx 14 0.0 0.2 32068 2880 ?S17:08 0:00 \_ nginx: > worker process > > # kill -QUIT 5 > # ps auxf > USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND > root 7 0.0 0.3 20224 3208 ?Ss 17:07 0:00 bash > root17 0.0 0.2 17496 2064 ?R+ 17:09 0:00 \_ ps auxf > root 1 0.0 0.2 20044 2704 ?Ss 17:06 0:00 /bin/bash -c > $(exec /usr/sbin/nginx -g "daemon off;") > root13 0.0 0.4 31688 5080 ?S17:08 0:00 nginx: > master process /usr/sbin/nginx -g daemon off; > nginx 14 0.0 0.2 32068 2880 ?S17:08 0:00 \_ nginx: > worker process > > > Теперь вопросы. > > А оно работает? То есть какие проблемы могут возникнуть из-за такого > изврашённого способа? Или есть способ лучше? (Ну в голову пришло ещё просто > стартовать новый контейнер, подменивать днс и выкидывать старый... но я в > этом не сильно шарю - как там ttl и всё такое, если нужно срочно). А что показывает ps axw -o pid,ppid,user,%cpu,vsz,wchan,command В апгрэйде самое главное, чтобы ppid у мастер-процеса был 1. > И ещё вопрос: А после -WINCH воркеры не должны вымирать? Должны. Но при автоматическом апгрэйде достаточно USR2/QUIT. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Redirect в случае если файл присутствует
On 18 Apr 2016, at 13:33, siroco wrote: Вот это ># we are checking files plus ".sha256" extentions >set $filetocheck $uri.sha256; > >set $cdn_server_name our-cdn.domain.com; лучше сразу подставить в директивы. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Redirect в случае если файл присутствует
On 18 Apr 2016, at 12:09, siroco wrote:
> Привет!
>
> Хочется сделать такую вещь - проверять наличие файла (это файл с контрольной
> суммой, например, "/myfile.txt.sha256") и в случае наличия файла делать
> редирект на CDN на "/myfile.txt". А в случае отсутствия файла - просто
> выдавать 404.
>
> Поскольку "if"(ы) это плохо, то напрашивается решение с try_files.
>
> Однако вот такой вот конфиг редиректит на CDN только в случае отсутствия
> файла с контрольной суммой:
>
># if file with checksum exists then redirect to CDN
>location / {
>root /var/www/myfiles;
>try_files $uri.sha256 @redirect_to_cdn;
>}
>
>location @redirect_to_cdn {
>return 302 http://mycdn.domain.com$request_uri;
>}
>
>
> Возможно ли как-то инвертировать условие try_files?
if это, конечно, плохо, но в сочетании с return не имеет побочных эффектов.
Можно использовать.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: модуль на заказ
On 25 Feb 2016, at 07:48, Alexander Uskov wrote: > Попробую Lua, так как яваскрипт пока нефункционален (нет класса Math), А что нужно в Math? -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx mainline version from source with libslz
On 15 Jan 2016, at 10:18, Aleksei wrote: > Доброго времени суток, > возможно ли собрать Nginx c libslz вместо zlib. > моя попытка оказалась неудачной, возможно мало опыта или звёзды расположились > на небе.. > хотел бы устлышать отзывы. может вообще не стоит тратить время. libslz - не drop in replacement zlib. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx -v и stdout
On 09 Dec 2015, at 00:46, greenh wrote: > В процессе развертывания и дебага случайно выяснилось, что nginx -V и nginx > -v вываливают ответ в stdout. Если не секрет - зачем? )) Потому что GCC, Python и Java вываливают в stderr, а Perl, Ruby, PHP, Node.js, Apache, SQLlite3 и memcached — в stdout. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Аналог ProxyPassReverse
On 04 Nov 2015, at 13:45, Alex Domoradov wrote:
> Столкнулся с проблемой необходимости перевести apache на nginx. На данный
> момент в apache в настройках виртуалхоста есть директивы
>
> ProxyPassReverse / http://javaclr.example.net/
> ProxyPassReverse / http://imagesclr.example.net/
> ProxyPassReverse / http://aspclr.example.net/
> ProxyPassReverse / http://vsclr.example.net/
>
> В офф документации nginx -
> https://www.nginx.com/resources/wiki/start/topics/examples/likeapache/
> говорится, что достаточно использовать proxy_pass и передавать соотв хедеры.
>
> Но тут возникает вопрос, а как мне в одном location использовать несколько
> директив proxy_pass. Или единственный выход использовать map, что то вида
>
> map $host $proxy_host {
> default "";
> "~(javaclr|imagesclr|aspclr|vsclr)\.example\.net" "$host";
> }
>
> server {
> listen 80;
> server_name javaclr.example.net imagesclr.example.net aspclr.example.net
> vsclr.example.net;
>
>location / {
> proxy_pass http://$proxy_host;
> proxy_set_header X-Forwarded-Host $host;
> proxy_set_header X-Forwarded-Server $host;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>}
> }
>
Аналог ProxyPassReverse - proxy_redirect:
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_redirect
Но, возможно, правильнее не валить всё в одну кучу, а сделать несколько
серверов.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: include *
On 24 Sep 2015, at 00:58, Синицкий Павел Евгеньевич wrote: > В каком порядке считывается сабж? зависит ли от ОС? Изменения в nginx 1.3.10 25.12.2012 *) Изменение: теперь при использовании директивы include с маской на Unix-системах включаемые файлы сортируются в алфавитном порядке. До этой версии использовался не сортированный порядок. На Windows до сих пор сортировка не гарантируется, но на обычно выполняется на NTFS. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
javascript in nginx
Сегодня на конференции nginx.conf/2015 мы объявили о выпуске предварительной версии javascript в nginx’е. Репозитарий: http://hg.nginx.org/njs/ Примеры использования: https://www.nginx.com/blog/launching-nginscript-and-looking-ahead Интересно ваше мнение об JS-интерфейсе к внутренностям nginx’а. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Отмена error page
On 10 Jun 2015, at 12:22, dant4z wrote: > Есть ли возможность отменить унаследованную директиву error_page с уровня > server (вернуться к поведению по умолчанию) в одном конкретном location? В > этом location бэкенд возвращает код 403 и нужно отдать тело, которое он > прислал, а не заменять его на заглушку. В других же надо оставить заглушку. > Очень неудобно было бы прописывать для всех, кроме одного, location одно и > тоже. http://nginx.org/ru/docs/http/ngx_http_core_module.html#error_page Директивы error_page наследуются с предыдущего уровня при условии, что на данном уровне не заданы свои директивы error_page. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: syslog в nginx 1.8
On 24 Apr 2015, at 15:49, Vitaliy Okulov wrote: > Платная версия syslog-ng умеет гарантировать доставку. В этой ситуации стоит > поднять локальный syslog. > А что будет с syslog-ng, если удалённый хост не доступен, он будет полученное локально складировать? Гарантируется ли, что запись в syslog-ng не будет блокировать записывающий процесс дольше, чем запись на диск? -- Igor Sysoev http://nginx.com > 24 апр. 2015 г. 15:46 пользователь "Igor Sysoev" написал: > On 24 Apr 2015, at 15:25, Иван Мишин wrote: > >> Лучше бы поддержка syslog была по rfc5424 > > > Если нужна надёжная доставка логов, то их надо записывать в локальные > файлы, ротировать их хоть каждую минуту и копировать в централизованное > хранилище. Логирование в syslog - это для тех, кому надёжная доставка не > критична. > > > -- > Igor Sysoev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: syslog в nginx 1.8
On 24 Apr 2015, at 15:25, Иван Мишин wrote: > Лучше бы поддержка syslog была по rfc5424 Если нужна надёжная доставка логов, то их надо записывать в локальные файлы, ротировать их хоть каждую минуту и копировать в централизованное хранилище. Логирование в syslog - это для тех, кому надёжная доставка не критична. -- Igor Sysoev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: CVE-2015-0235 - GHOST
On 30 Jan 2015, at 00:01, Vadim A. Misbakh-Soloviov wrote: > В письме от Чт, 29 января 2015 23:50:49 пользователь Igor Sysoev написал: >> В сочетании nginx/glibc тоже нет уязвимости. > > В общем случае — да :) > > Но, на сколько я понял намёк ОП, он имеет в виду, что (не смотря на > отсутствие > PoC) потенциальная уязвимость есть (если подшаманить на основе > exim-эксплойта) > + иметь необновляемую годами систему "старым" glibс (2.2x<2.18), то может > можно и словить. > > Мало ли, какие [умные люди] крутят NgX 0.7.x на МСВС каком-нибудь :) Ну, или > какой-нибудь там Debian old-stable (а то и Maemo какой-нибудь. Любителей > нестандартных развлечений ведь много). > > А так, да, в большинстве систем, где не забывают обновлять пакетную базу и > вовремя "стабилизировать" новые версии (а юзеры не забывают обновляться) > проблем быть, конечно, не должно. nginx перед вызовом gethostbyname() вызывает свой аналог inet_addr() и сам обрабатывает длинный адрес, поэтому даже в комбинации nginx-0.7.0/glibс-2.3 проблемы нет. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: CVE-2015-0235 - GHOST
On 29 Jan 2015, at 23:33, Vadim A. Misbakh-Soloviov wrote: > Так уязвимость в glibc же ж, а не в коде приложений :) В сочетании nginx/glibc тоже нет уязвимости. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Запретить использовать SPDY
On 20 Jan 2015, at 14:28, Gena Makhomed wrote: > On 19.01.2015 14:42, Валентин Бартенев wrote: > >>>> Вопрос мой ведь в другом, можно ли обойтись иными способами? >>> >>> теоретически - да, если научить nginx смотреть на имя сервера >>> в SNI и на основании этого имени включать или выключать SPDY >> >> nginx научить то можно, а клиентов кто при этом научит не ходить >> на этот сервер по spdy? >> >> С точки зрения протокола spdy, его анонс на каком-либо соединении >> эквивалентен анонсу на всех виртуальных серверах с тем же портом, >> чьи домены резолвятся в тот же ip, имеют тот же порт и для которых >> валиден сертификат. Это позволяет запрашивать эти хосты в том же, >> уже открытом spdy-соединении, тем самым экономя хэндшейки - основной >> смысл spdy. >> >> Всё несколько сложнее, чем кажется. > > Раньше было необходимо для каждого HTTPS сайта покупать отдельный IP. > > Сейчас - поддержка SNI появилась уже практически во всех серверах > и клиентах. Кроме того изменились ситуация с поисковыми машинами > и появилась возможность получить бесплатный SSL сертификат: > > http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html > > https://letsencrypt.org/ > > https://www.cloudflare.com/ssl > > Поэтому в ближайшее время можно ожидать массовое использование SNI > для HTTPS сайтов, в результате на одном и том же listen сокете IP:PORT > будут десятки а то и сотни разных HTTPS-сайтов с разными сертификатами. > > Соответственно - можно будет управлять включением/выключением поддержки > протокола SPDY для каждого из этих сайтов в отдельности. > То есть, теоретически - это сделать возможно. Теоретичкески - невозможно. Есть два сервера на одном listen сокете. Один со SPDY, второй - нет. Пользователь запросил первый сервер. Браузер установил SPDY-соединение к первому. Потом пользователь запросил второй сервер. Браузер пошлёт этот запрос по этому же самому SPDY-соединению. Как его обработать не в рамках SPDY-протокола? Закрыть stream? Вполне возможно, что браузер после этого вообще перестанет работать с данным IP-адресом по SPDY. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Максимально возможные значения для fastcgi_connect_timeout и fastcgi_read_timeout
On 25 Nov 2014, at 14:25, Алексей Сундуков wrote: > Т.е. согласно директиве fastcgi_connect_timeout nginx для сокета выставляет > заданный в конфиге таймаут, но эта величина будет игнорироваться если она > превышает заданную для ядра? Она не игнорируется. Просто ядро возвращает ошибку до того, как срабатывает таймаут nginx’а. > Т.е. кроме увеличения fastcgi_connect_timeout в конфиге nginx нужно еще > изменять настройки ядра, так? Да. > А почему тогда в документации говорится: "что этот таймаут обычно не может > превышать 75 секунд"? Я к тому, почему именно 75? Потому что исторически этот таймаут был равен 75 секундам, но в Линуксе, как обычно, проявили самодеятельность. Почитайте статью, там объясняется, как получается 75 и 20 секунд. -- Igor Sysoev http://nginx.com > 25 ноября 2014 г., 14:17 пользователь Igor Sysoev написал: > On 25 Nov 2014, at 11:48, Алексей Сундуков wrote: > >> Всем привет! >> >> Когда-то давно я помню, что было обсуждение этих директив и было упоминание, >> что >> http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_connect_timeout >> поднять выше 75 секунд нельзя и это захаркожено и исходниках. В связи с чем >> вопросы: >> >> 1) Где в коде эти 75 секунд заданы в случае, если нужно этот лимит поднять? >> 2) Есть ли для fastcgi_read_timeout подобных хардкод, и если да, то где он? > > > Это ограничения ядра, а не nginx’а. > > Вот тут > http://www.sekuda.com/overriding_the_default_linux_kernel_20_second_tcp_socket_connect_timeout > утверждается, что на Линуксе этот таймаут максимум 20 секунд и даны > рекомендации, > как его увеличить. Не проверял. > > > -- > Igor Sysoev > http://nginx.com > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Максимально возможные значения для fastcgi_connect_timeout и fastcgi_read_timeout
On 25 Nov 2014, at 11:48, Алексей Сундуков wrote: > Всем привет! > > Когда-то давно я помню, что было обсуждение этих директив и было упоминание, > что > http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_connect_timeout > поднять выше 75 секунд нельзя и это захаркожено и исходниках. В связи с чем > вопросы: > > 1) Где в коде эти 75 секунд заданы в случае, если нужно этот лимит поднять? > 2) Есть ли для fastcgi_read_timeout подобных хардкод, и если да, то где он? Это ограничения ядра, а не nginx’а. Вот тут http://www.sekuda.com/overriding_the_default_linux_kernel_20_second_tcp_socket_connect_timeout утверждается, что на Линуксе этот таймаут максимум 20 секунд и даны рекомендации, как его увеличить. Не проверял. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: location /pics/ только для картинок
On 24 Nov 2014, at 13:11, cilrill wrote:
> Добрый день.
>
> Нужно все запросы картинок jpg|jpeg|gif|png в uri которых присутствует
> /pics/ проксировать на отдельный сервер.
> Ссылки вида example.com/pics/goods/big/komplekt_4-2.jpg
>
> Пока сделал так и работает.
>
> location /pics/ {
> location ~* \.(jpg|jpeg|gif|png) {
> include /etc/nginx/ext-pics.conf;
> }
> }
>
> Верно ли использовать такую конструкцию
Верно.
> или можно обойтись без вложения location ?
Можно, но не нужно.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: server_name regexp
On 23 Nov 2014, at 03:12, Anton Kiryushkin wrote: > Здравствуйте. > > Какая-то ерунда наблюдается. Вот есть у меня хост, у которого есть поддомены. > И каждый поддомен должен идти на свой бэкенд. Но так же, у этого хоста есть и > https. > Вопрос первый. Правда ли, что с этом случае нельзя использовать регулярное > выражение для описания имени этого хоста? Если так, то нужно использовать > regexp имя и *.site.com ? > Вопрос второй. Я вот попробовал использовать такую конструкцию для описания > этого хоста, как в map, так и в server_name: > ~^(?).+site\.com$ > > И ни в map, ни в server_name я не получаю значение $n. > > Я попробовал так: > ~^(?.+site\.com)$ > > И получил весь $http_host, вместо $n. > > Что я делаю не так? ~^(?).+site\.com$ ~^(?.+)site\.com$ Но вот, чтобы такой ерунды больше не наблюдалось, я бы посоветовал не пытаться впихнуть всё в один сервер, а разнёс бы поддомены (если их конченое число), на разные сервера. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL единый HTTP/HTTPS сервер
On 24 Nov 2014, at 11:23, dwow wrote:
> Потому что часть пользователей целенаправленно направляется через HTTP, а
> часть через HTTPS.
А что мешает сделать
server {
listen ssl;
listen 6667;
...
}
?
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL единый HTTP/HTTPS сервер
On 21 Nov 2014, at 23:52, dwow wrote: > например, на разных портах настроены тестовые сервера. Я имел в виду, зачем серверу на одном порту работать по обоим протоколам - HTTP и HTTPS? -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL единый HTTP/HTTPS сервер
On 21 Nov 2014, at 15:22, dwow wrote: > Добрый день, > есть ли возможность сделать единный HTTP/HTTPS сервер на отличном порту? > Например, чтобы example.com: работал и по HTTP и по HTTPS? А в чём смысл такого сервера? -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx и /etc/hosts
On 02 Oct 2014, at 15:06, Anton Kiryushkin wrote: > А можно у вас уточнить еще два момента. > 1. Зачем nginx вызывает эти функции libc, например, если в нашем случае мы не > используем в proxy_pass домены, а только IP. Верно ли предположение, что > происходит вызов gethostbyname на IP? Если в proxy_pass описан upstream с серверами, заданными IP, то при сборке —with-ipv6 используется getaddrinfo(). А уж что оно делает, зависит от libc. > 2. Как оптимизировать это место, если файл hosts достаточно большой? Собрать без ipv6. -- Igor Sysoev Join us for nginx.conf 2014, October 20-22, San Francisco. Get 25% off with code NGINXUG: http://nginx.com/nginxconf/___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx и /etc/hosts
On 02 Oct 2014, at 04:28, Anton Kiryushkin wrote: > Мы тут заметили, что при старте nginx, он довольно часто перечитывает > /etc/hosts и /etc/resolv.conf. Можно ли как-то узнать зачем. Причем ладно бы > один раз, а то ведь раз 5, по ощущениям. Это делает libc при вызове gethostbyname() и getaddrinfo(). -- Igor Sysoev Join us for nginx.conf 2014, October 20-22, San Francisco. Get 25% off with code NGINXUG: http://nginx.com/nginxconf/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Нет uwsgi set header, чем заменить?
On 15 Jul 2014, at 12:18, Budulianin wrote: > Всем привет. > > Хочу задать заголовки. Но в доке не вижу uwsgi_set_header. > Как для uwsgi задать заголовки? http://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_param -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Об одной малоизвестной уязвимости в веб сайтах
On 17 Jun 2014, at 20:03, Maxim Dounin wrote: >>> В своё время, однако, nginx'у потребовалось от этой практики отказаться: >>> >>> http://hg.nginx.org/nginx/rev/b9de93d804ea >>> >>> Если мне не изменяет память, причина была всё та же - реальная >>> жизнь заставила. >> >> Можно подробнее узнать про причину? > > Это вопрос к Игорю, может быть он помнит подробности. В переписке следов не нашёл, но помню строки из error_log’а с десятками строк “Host” в одном запросе, по-моему от MSIE. Видел, скорее всего, в рамблеровских логах. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL и алгоритмы ГОСТ
On Mar 20, 2014, at 23:28 , Phil Kulin wrote:
> 20 марта 2014 г., 23:26 пользователь Igor Sysoev написал:
>
>>> Есть nginx, хочется делать соединение SSL с ГОСТовскими ключами. В том
>>> числе приём клиентских сертификатов. Стоит OpenSSL 1.0.1, конфиг есть,
>>> BIND например всё видит и домены ключами ГОСТ подписаны (где-то здесь
>>> минутка саморекламы :).
>>> В nginx надо что-то прописывать особенное? Или "сам поймёт"? Или
>>> наоборот "не поймёт"?
>> Насчёт клиентских сертификатов сказать не могу, а вообще должно работать.
>
> А вот этот список ssl_cipher? По умолчанию оставить? Просто в том же
> BIND надо чего-то сказать ему при сборке. Но я плохо разбираюсь в
> библиотеке
По-моему, ничего не нужно специально настраивать, достаточно правильного
/etc/openssl.conf.
Если не получится, то
ssl_engine gost;
http {
ssl_ciphers "GOST2001-GOST89-GOST89";
...
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: SSL и алгоритмы ГОСТ
On Mar 20, 2014, at 23:17 , Phil Kulin wrote: > Есть nginx, хочется делать соединение SSL с ГОСТовскими ключами. В том > числе приём клиентских сертификатов. Стоит OpenSSL 1.0.1, конфиг есть, > BIND например всё видит и домены ключами ГОСТ подписаны (где-то здесь > минутка саморекламы :). > > В nginx надо что-то прописывать особенное? Или "сам поймёт"? Или > наоборот "не поймёт"? Насчёт клиентских сертификатов сказать не могу, а вообще должно работать. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Отдавать 444 тем, у кого в запросе содержится "//"
On Mar 17, 2014, at 22:07 , grisha2217 wrote:
> Заметил, что сайт подвергается ддос атакам, в логах такие запросы:
> //?msg=SuckBith!!!&msg2=ITISDD0S!
> //??-?
> //?=E73994C7=BLA>E3<6=5789
>
>
> Как сделать универсальный bad_request для таких запросов.
>
> Так?
> $request ~* "//?*"
>
>
> Я боюсь блокировать запросы, содержащие //, так как пользователь может
> ошибиться и ввести случайно 2 слэша. Нужно, чтобы влетали только те
> айпишники, которые посылают запрос // + минимум один символ
if ($request_uri ~ "^//\?") {
return 444;
}
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Re[2]: Процессная модель
On Mar 1, 2014, at 21:46 , Михаил Монашёв wrote: > Здравствуйте, Igor. > >> Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые >> процессы. Вот там проблемы, так проблемы. Сигналы - это семечки. > > А есть желание эти проблемы преодолевать? Т.е. есть желание покорять > венду с её вендо-админами? Конкретно эти проблемы - проблемы взаимодействия и передачи данных из мастера в воркеры - уже преодолены. Это к вопросу о том, что проще - делать fork() или fork()/exec() для родственных процессов. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Процессная модель
On Feb 27, 2014, at 22:22 , AlexyFrost wrote: > Anton Yuzhaninov Wrote: > --- >> On 02/26/14 03:17, AlexyFrost wrote: >> Мусора в том, что наследуется нет. >> >> listen socket нужен. >> других сокетов, открытых в мастере не должно быть. >> >> Обработчики сигналов AFAIK переопределяются, если нужно. > > Вот об этом я и говорил: с использованием fork() воркер попадает в сильную > зависимость от того, что должно и не должно быть инициализировано в мастере, > т.е., какие контр-действия придётся ему делать (закрытие чего то, отключение > сигналов etc). Понятное дело, что для компилируемой программы этот аргумент > не столь важен, но, тем не менее, для большого и сложного проекта, который > пишет не один человек, такие сайд-эффекты вполне существенны, мне кажется. > > К тому же, если форки используются для разных типов воркеров (обработка > соединений, какой то кеш, какие то сервисные штуки), то у них могут быть > разные реакции на унаследованные от мастера данные - кому то надо сделать > то, кому то это, и в случае внесения изменений в мастер (добавили новый > сигнал?) придётся править код всех воркеров. > >> То что worker-ы используют память мастера (через COW) очень даже >> полезно - >> большая геобаза загруженная мастером будет использоваться всеми >> процессами и не >> надо будет загружать её N раз в каждый worker отдельно. > > Для подобных данных можно использовать shared memory, что так же выглядит > логичнее, чем "копия" данных мастера, да и в случе потребностей горячей > замены таких данных сделать это будет проще в одном месте. Shared memory в неродственных процессах сочетании с ASRL превращается в ад. >> В адресное пространство воркеров попадает часть кода и данных, не >> нужных >> worker-ом, но ничего плохого в этом нет. > > Меня, в целом, не столько беспокоят "левые" данные мастера в воркере, > сколько потенциальные проблемы, которые они могут привнести (выше > перечислял). Ввиду отсутствия fork()а на Windows, nginx/Windows запускает новые процессы. Вот там проблемы, так проблемы. Сигналы - это семечки. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Custom 400 error for client-certificate-authenticated site
On Feb 3, 2014, at 13:23 , siroco wrote: > Прошу прощения, дело было в кешах Хрома. > Все работает после включения 495 и 496. С 495 есть только одна проблема - она возвращается на примерно 30 ошибок проверки сертификата. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Custom 400 error for client-certificate-authenticated site
On Feb 3, 2014, at 13:00 , siroco wrote: >> Ошибка "No required SSL certificate was sent" имеет специальный >> код 496, и именно его надо перехватывать директивой error_page. > > Код 496 прекрасно справляется с ситуацией перехвата ситуации с отсутствующим > сертификатом. > > Но если срок действия сертификата, то все равно вылетаем ошибка "400 Bad > Request > No required SSL certificate was sent") > > Если какая-то возможность показывать кастомную ошибку в ситуации, когда > сертификат уже не действителен (по времени)? > Пробовал добавить и ошибку 495 тоже (вместе с 496), но ничего не помогло.. 495 должна работать. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: анализ аргументов в arg*
On Feb 1, 2014, at 2:57 , denis wrote:
> Потребовалось сделать редирект на базе одного из ряда аргументов, логично
> было бы так
> if ($arg_SID=110) {
>
> А заработало так
> if ($args ~ SID=110) {
>
> Что с $arg_SID не так? Вариант с if ($arg_SID~110) { также не заработал. И
> почему с args заработало вообще.
>
> вызов типа ?SID=11&PID=200
$arg_SID должен работать.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: журнал исходящих и входящих соединений
On Jan 24, 2014, at 12:20 , misha_shar53 wrote: > Есть ли в NGINX журнал входящих и исходящих соединений. Если есть то как его > подключить и где посмотреть? >access_log /home/misha/Devel/wrk/nginx/access.log; >access_log on; "access_log on" создал дополнительный лог-файл "on": http://nginx.org/ru/docs/http/ngx_http_log_module.html#access_log > Это ничего не дало. В access.log должны быть запросы клиентов, можно туда добавать переменных, связанных с исходящими соединениями: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#variables Настаривается это с помощью log_format: http://nginx.org/ru/docs/http/ngx_http_log_module.html#log_format -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Поддержка Range в subrequest
On Jan 22, 2014, at 12:45 , akashihi wrote:
> Добрый день.
>
>
>
> Разбирался с одной проблемой производительности и обнаружил, что nginx не
> умеет читать части файлов (то есть не поддерживает range) в subrequest'ах.
>
> Например, если запрашивать файл напрямую, то читается только запрошенный
> участок файла:
> curl --header "Range: bytes=2-21000"
> http://localhost:8081/largefile.txt
> open("/home/./largefile.txt", O_RDONLY|O_NONBLOCK) = 13
> fstat(13, {st_mode=S_IFREG|0644, st_size=10485760, ...}) = 0
> pread(13,
> "G\2220cT+>\214r\0056\321#\202k\6\215\36\214\32\34X\267\350\302r\242\275\311\6\203f"...,
> 1001, 2) = 1001
>
> Но, если я обращаюсь к файлу из модуля с помощью subrequest, то читается
> всегда весь файл:
> curl --header "Range: bytes=2-21000"
> http://localhost:8081/subrequest.txt
> open("/home/.../largefile.txt", O_RDONLY|O_NONBLOCK) = 13
> fstat(13, {st_mode=S_IFREG|0644, st_size=10485760, ...}) = 0
> pread(13,
> "\210\336\212k3\355g\nOH\"0\20\3152\265\v4\25\253\21\2U/\234!\257\331Uh\350\245"...,
> 32768, 0) = 32768
> pread(13,
> "\32\310\270>\245K\21\271\230\235\230\345\35]=\266@q\373}\204\367.\352\355i\224\215d\200\322\37"...,
> 32768, 32768)
> итд
>
>
> В коде ngx_http_range_filter_module есть явная проверка, не subrequest ли
> обрабатывается и если да, то передаётся следующему фильтру:
>if (r->http_version < NGX_HTTP_VERSION_10
>|| r->headers_out.status != NGX_HTTP_OK
>|| r != r->main
>|| r->headers_out.content_length_n == -1
>|| !r->allow_ranges)
>{
>return ngx_http_next_header_filter(r);
>}
>
>
> То есть это не баг, а осознанное решение. Но вот чем оно вызвано? Беглое
> чтение кода не прояснило ничего.
Подзапросы делались прежде всего для включений SSI, к которым ranges не
применимы.
--
Igor Sysoev
http://nginx.com
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование статики, которую генерирует бэкэнд
On Jan 20, 2014, at 15:27 , Anatoly Mikhailov wrote:
>
> On 20 Jan 2014, at 11:02, Igor Sysoev wrote:
>
>> On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote:
>>
>>> в нашем случае - локально настроенная Jira с 10 пользователями,
>>> сомневаюсь, что приложение загнется при такой нагрузке.
>>>
>>> и все же, кто как кэширует статику, сгенерированную налету?
>>
>> http {
>>proxy_cache_path /path/to/cache keys_zone=CACHE:20M;
>>proxy_temp_path /path/to/temp;
>>
>>server {
>>location /static/ {
>>proxy_pass http://backend;
>>proxy_cache CACHE;
>>proxy_cache_valid 1h;
>>}
>>}
>> }
>
> Игорь, спасибо, проблема решена, но возможно не оптимальным образом:
>
> proxy_cache_path /.../nginx/cache levels=1:2 keys_zone=STATIC:20M;
> proxy_temp_path /.../nginx/tmp;
>
> server {
> listen8000;
>
> location /jira {
> proxy_passhttp://jira_upstream/jira;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-for $remote_addr;
> proxy_redirectoff;
> proxy_connect_timeout 120;
> proxy_send_timeout120;
> proxy_read_timeout180;
> }
>
> location /jira/s/ {
> proxy_passhttp://jira_upstream/jira/s/;
> proxy_set_header Host $host;
> proxy_set_header X-Real-IP $remote_addr;
> proxy_set_header X-Forwarded-for $remote_addr;
> proxy_redirectoff;
> proxy_connect_timeout 120;
> proxy_send_timeout120;
> proxy_read_timeout180;
>
> proxy_ignore_headers "Set-Cookie";
Ещё нужно
proxy_hide_header Set-Cookie;
иначе клиенты будут получать чужие куки.
--
Igor Sysoev
http://nginx.com
> proxy_cache STATIC;
> proxy_cache_valid60m;
> }
>
>
> Анатолий
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Кэширование статики, которую генерирует бэкэнд
On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote:
> в нашем случае - локально настроенная Jira с 10 пользователями,
> сомневаюсь, что приложение загнется при такой нагрузке.
>
> и все же, кто как кэширует статику, сгенерированную налету?
http {
proxy_cache_path /path/to/cache keys_zone=CACHE:20M;
proxy_temp_path /path/to/temp;
server {
location /static/ {
proxy_pass http://backend;
proxy_cache CACHE;
proxy_cache_valid 1h;
}
}
}
--
Igor Sysoev
> Анатолий
>
> On 20 Jan 2014, at 10:35, Илья Шипицин wrote:
>
>> у jira, teamcity узкое место - само приложение. оно начинает
>> загибаться гораздо раньше, чем становятся заметны проблемы с отдачей
>> статики.
>> оптимизировать именно статику в данном случае - предпосылка непонятная
>>
>> 20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov
>> написал:
>>> Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http
>>> запросы за ее получением через Catalina.
>>>
>>> Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка
>>> прикрыть глупость организации отдачи контента, который, во многих случаях,
>>> не меняется никогда. Одно дело - все эти украшения для статики, которую
>>> отдает Nginx напрямую с диска, но в данном случае все это отдается через
>>> бэкэнд. Так и остается загадкой зачем было сделанно именно так.
>>>
>>> Суть задачи не меняется, кэшировать статику (в случае с jira: location /s/)
>>> после первого обращения к ней. Proxy pass cache - копать в эту сторону?
>>>
>>> Анатолий
>>>
>>>> On Jan 20, 2014, at 5:05 AM, Илья Шипицин wrote:
>>>>
>>>> teamcity очень мало статики отдает.
>>>> для jira лучше настроить keepalive до бекенда
>>>> а stash - это что именно ?
>>>>
>>>> 20 января 2014 г., 6:30 пользователь Anatoly Mikhaylov
>>>> написал:
>>>>> Добрый день,
>>>>>
>>>>> Есть несколько java-приложений (stash, jira, teamcity), в которых статика
>>>>> генерируется на ходу, файлов на диске с такими именами просто нет. Сейчас
>>>>> организовано элементарное проксирование proxy_pass и все работает, но
>>>>> медленно.
>>>>>
>>>>> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не
>>>>> препятствовало основному проксированию ответа бэкэнда?
>>>>>
>>>>> Анатолий
>>>>> ___
>>>>> nginx-ru mailing list
>>>>> nginx-ru@nginx.org
>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>> ___
>>>> nginx-ru mailing list
>>>> nginx-ru@nginx.org
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: ngx_http_geo_module range overlaps
04.01.2014, в 23:03, Валентин Бартенев написал(а):
> On Saturday 04 January 2014 22:09:29 Maxim Dounin wrote:
>> Hello!
>>
>> On Sat, Jan 04, 2014 at 06:12:25PM +0400, Валентин Бартенев wrote:
>>> On Saturday 04 January 2014 15:01:16 Ксения Юрьевна Блащук wrote:
>>>> Добрый день.
>>>> Возник вопрос по модулю ngx_http_geo_module. Почему-то нельзя внести
>>>> пересекающиеся диапазоны адресов. В документации:
>>>>
>>>> A value of the most specific match is used. For example, for the
>>>> 127.0.0.1
>>>> address the value "RU" will be chosen, not "US".
>>>>
>>>> Example with ranges:
>>>>
>>>> geo $country {
>>>>
>>>>ranges;
>>>>default ZZ;
>>>>127.0.0.0-127.0.0.0 US;
>>>>127.0.0.1-127.0.0.1 RU;
>>>>127.0.0.1-127.0.0.255 US;
>>>>10.1.0.0-10.1.255.255 RU;
>>>>192.168.1.0-192.168.1.255 UK;
>>>>
>>>> }
>>>>
>>>> Пытаюсь воспроизвести этот пример:
>>>>
>>>> /etc/init.d/nginx reload
>>>>
>>>> * Checking nginx' configuration ...
>>>>
>>>> nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps
>>>> "127.0.0.1-127.0.0.1"
>>>> in /etc/nginx/sites/test-geo.conf:6
>>>> nginx: configuration file /etc/nginx/nginx.conf test failed
>>>> nginx: [emerg] range "127.0.0.1-127.0.0.255" overlaps
>>>> "127.0.0.1-127.0.0.1"
>>>> in /etc/nginx/sites/test-geo.conf:6
>>>> nginx: configuration file /etc/nginx/nginx.conf test failed
>>>
>>> [..]
>>>
>>>> В чем может быть дело?
>>>> Спасибо.
>>>
>>> Это баг в проверке конфигурации.
>>>
>>> Чтобы его обойти можете поменять местами так чтобы вначале шел больший
>>>
>>> диапазон:
>>>127.0.0.1-127.0.0.255 US;
>>>127.0.0.1-127.0.0.1 RU;
>>
>> Это не баг, это фича. Код не умеет обрабатывать добавления
>> диапазонов, перекрывающих уже существующие диапазоны, и честно об
>> этом сообщает.
>>
>> При использовании range'ей последующими строками можно
>> переопределить часть ранее заданного диапазона адресов. Задать
>> диапазон, который бы включал в себя ранее заданные диапазоны -
>> нельзя.
>
> Фича, как известно, это задокументированная бага, а в данном же случае
> было не так. =)
>
> Можно и научить:
Нет, учить не надо. Изначально предполагался контроль данных с возможностью
последующего оверрайда некоторых диапазонов.
--
Igor Sysoev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: listen на всех ип кроме 127/8
On Dec 4, 2013, at 1:44 , Dmitry Morozovsky wrote: > On Wed, 4 Dec 2013, Nick Knutov wrote: > >> А нет ли способа сделать listen на всех ип (как *:80), кроме 127/8 (и, >> наверное, IPv6:::1) ? >> >> Контекст - на разных 127.0.0/24 висят разные бэкенды, и им надо висеть >> именно на 80ом порту, а внешний(ие) ип (на которые должен биндится >> нгинх) часто меняются (и их количество вообще может быть не известно, >> отвечать надо на всех). Хочется делать релоад нгинх без переписывания >> кучи конфигов (виртуалхостов - много, очень много). > > А что за система и ядро? Многие современные, [ не Линуксы ] > IIUC, позволяют одному слушать на > *:80 и остальным откусывать у него specific:80 -- Igor Sysoev ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Сервер по-умолчанию для конкретного домена
http://nginx.org/ru/docs/http/configuring_https_servers.html#name_based_https_servers -- Igor Sysoev http://nginx.com On Nov 1, 2013, at 11:12 , Nikita A Kardashin wrote: > Всем привет, > > Возникла задача: > > - На один nginx ссылаются >1 домена, при этом, для каждого из них должен быть > доступен SSL (есть сертификаты). > - Все запросы к несуществующим на сервере хостам должны попадать в некий хост > по-умолчанию (и редиректиться оттуда rewrite-ом, но это частности). > > Т.е, поступает запрос. Если есть сервер, для которого запрошенный хост > прописан в server_name - отправляем его туда. Если нет - в сервер > по-умолчанию для domain.tld, откуда его регулярка отправляет "по адресу" (на > главный сайт в зависимости от запрошенного домена). > > Классическая схема (сервера + один сервер с опцией default) прекрасно > работала до тех пор, пока домен был один, а сейчас - не вариант, т.к. мы не > можем прописать в сервере больше, чем 1 SSL-сертификат (в результате чего > пользователь при обращении к несуществующему серверу по домену, отличному от > первого вместо ожидаемого редиректа получает неожиданный > FailedCertificateAlert от браузера и блокировку дальнейшего редиректа). > > Если же создать сервер с server_name = *.domain.tld для каждого домена, то > туда попадают все запросы, даже те, для которых есть отдельные server-ы. > > Есть какой-то нормальный путь это обойти? Например, задавать приоритет > серверу (тогда можно поставить минимальный умолчальному серверу и запрос таки > будет улетать туда только тогда, когда более подходящих серверов нет). Или > выбирать сертификат в зависимости от домена (по IF-у)? > > -- > With best regards, > differentlocal (www.differentlocal.ru | differentlo...@gmail.com), > System administrator. > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx -t > Illegal instruction
On Oct 15, 2013, at 21:36 , Gena Makhomed wrote: > есть лучший вариант - стандартный и документированный способ > проверить, поддерживает __i386__ процессор команду cpuid или нет: > > http://wiki.osdev.org/CPUID > > такой патч был бы более универсальным и более полезным. > вопросы про 486 процессор без cpuid периодически возникают. Что-то я не припоминаю в рассылке периодических вопросов про процессоры двадцатилетней давности. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: NGinx + apache проверка работы
nginx -t nginx -s reload -- Igor Sysoev 11.10.2013, в 11:01, denis написал(а): > 10.10.2013 12:03, Daniel Yavorovich пишет: >> Здравствуйте! >> >> Ошибка возникает на этапе перегенерации конфигов nginx и его жёсткого >> перезапуска. Решить вопрос можно путём изменения способа перезагрузки nginx >> с restart на reload. >> >> Перечитать конфигурацию nginx без обрыва существующий соединений можно так: >> >> nginx -s reload > У релоада есть большая проблема: он некорректно делает конфигтест, поэтому > если есть ошибки в конфиге, reload может сказать что всё ок, а restart > говорит о реальных проблемах. И после такого релоада сначала всё работает, но > по мере обновления воркеров появляются отказы. > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: использование X-Accel-Charset ?
On Oct 7, 2013, at 21:31 , Илья Шипицин wrote: > Добрый день! > > приведите, пожалуйста, пример, как можно использовать X-Accel-Charset ? > не могу придумать такую ситуацию. В Рамблере использовалось. Для чего - уже не помню и из переписки не ясно. Может, Макс вспомнит - в почте оно тоже использовалось. Возможно, для интеграции с поиском. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: directio_alignment
On Sep 20, 2013, at 18:43 , Anton Sayetsky wrote: > 20 сентября 2013 г., 17:38 пользователь Igor Sysoev написал: >> Нет. > Тогда можно ли краткий экскурс на тему того, почему стоит это делать > только для XFS? На XFS это не оптимизация, а вынужденная мера. Потому что на XFS размеры блоков не 512 байт, а 4096, и при выровненным на 512 чтении байт возвращается ошибка. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: directio_alignment
On Sep 20, 2013, at 18:27 , Anton Sayetsky wrote: > Приветствую, > Имеет ли смысл данный параметр ставить в 4к при ФС с соответствующими > блоками на SSD? Нет. -- Igor Sysoev http://nginx.com ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Request Entity Too Large
On Mar 28, 2013, at 17:34 , Aleksandr Sytar wrote:
> Я бы резюмировал бы так - дайте возможность вносить многострочные комментарии
Наверное, это стоит сделать в виде:
disable server {
...
}
disable location /dir/ {
...
}
и в более общем виде
disable {
...
}
Более короткое слово "off" хуже, потому что его сложно искать - будет
совпадений с флагами директив - on/off.
--
Igor Sysoev
http://nginx.com/services.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: rewrite & $remote_user
On Mar 12, 2013, at 14:59 , Oleg wrote:
> Здравствуйте.
>
> Есть следующая конфигурация:
>
>location /test {
>auth_basic "test zone";
>auth_basic_user_file /var/www/test/.htpasswd;
>root /var/www;
>
>rewrite ^/test/?$ /test/user/$remote_user/f redirect;
> }
>
> Хочется, что бы после аутентификации пользователя редиректило на его
> страницу. Порядок (сначало аутентификация, потом перенаправление) работает
> как подразумевается, а, вот, подстановка $remote_user не работает. В браузере
> http://host/test даёт http://host/test/user//f. Если использовать, для
> примера,
> $remote_addr, то подстановка работает как надо.
location /test {
auth_basic "test zone";
auth_basic_user_file /var/www/test/.htpasswd;
root /var/www;
location = /test {
return 301 http://$host/test/user/$remote_user/f;
}
location = /test/ {
return 301 http://$host/test/user/$remote_user/f;
}
}
--
Igor Sysoev
http://nginx.com/services.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: WebSocket проксирование
On Mar 12, 2013, at 10:07 , Modigar wrote:
>server {
>listen 443 ssl; # порт https
>server_name localhost; # ваш сайт
>
>ssl_certificate/usr/local/nginx/sert/cert.pem;
> ssl_certificate_key /usr/local/nginx/sert/cert.key;
Вот это:
>if ( $scheme = "http" ) {
> rewrite ^/(.*)$ https://$host/$1 permanent;
>}
бессмыслица. Нужно так:
error_page 497 =301 http://$host$request_uri;
--
Igor Sysoev
http://nginx.com/support.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: каскад проксирующих серверов
On Mar 7, 2013, at 0:08 , Anatoly Mikhailov wrote:
> On Mar 6, 2013, at 7:53 PM, Igor Sysoev wrote:
>
>> On Mar 6, 2013, at 23:35 , Anatoly Mikhailov wrote:
>>
>>> добрый день,
>>>
>>> Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока
>>> склоняюсь к использованию
>>> Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx -
>>> Unicorn) x 5.
>>>
>>> У нас связка Nginx+Unicorn на нескольких независимых серверах разного
>>> назначения (Main, Admin, API, Mobile-API),
>>> но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main)
>>> приложение поставить
>>> за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно
>>> Nginx-B), которые
>>> и будут непосредственно проксировать на Unicorn.
>>>
>>> В роли балансировщика выступают 2 кандидата: Nginx и Haproxy.
>>> С первым все понятно:
>>> - SSL-offload, и чистый http между Nginx-A и Nginx-B
>>> - с одной стороны, знакомая и понятная настройка
>>> - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1
>>> между A и B )
>>
>> Между nginx'ами можно поставить 1.1, поскольку для второго nginx'а
>> постоянные соедиения
>> дешёвые.
>
> Да, Игорь, спасибо, что прояснили этот момент.
> Если я правильно понимаю, то конфигурация Nginx-A будет:
>
>
> upstream http_backend {
> server 10.0.0.1:8080; # Nginx-B
> server 10.0.0.1:8080; # Nginx-B
> keepalive 16;
> }
keepalive можно поставить значительно больше.
--
Igor Sysoev
http://nginx.com/support.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: каскад проксирующих серверов
On Mar 6, 2013, at 23:35 , Anatoly Mikhailov wrote: > добрый день, > > Вопрос балансировки нагрузки не дает мне покоя несколько дней, пока склоняюсь > к использованию > Nginx в роли балансировщика. Таким образом будет каскад Nginx - (Nginx - > Unicorn) x 5. > > У нас связка Nginx+Unicorn на нескольких независимых серверах разного > назначения (Main, Admin, API, Mobile-API), > но сейчас, ввиду растущей нагрузки, есть необходимость основное (Main) > приложение поставить > за балансировщиком (условно Nginx-А), получив 5 бэк-энд серверов (условно > Nginx-B), которые > и будут непосредственно проксировать на Unicorn. > > В роли балансировщика выступают 2 кандидата: Nginx и Haproxy. > С первым все понятно: > - SSL-offload, и чистый http между Nginx-A и Nginx-B > - с одной стороны, знакомая и понятная настройка > - с другой стороны, какие параметры proxy надо настроить (нужен ли http-1.1 > между A и B ) Между nginx'ами можно поставить 1.1, поскольку для второго nginx'а постоянные соедиения дешёвые. > Haproxy: > - банально "типичное решение" > - нетривиальная и запутанная конфигурация -- Igor Sysoev http://nginx.com/support.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fastcgi cache valid для разных location'ов
On Mar 2, 2013, at 14:29 , Namaste wrote: > Ясно, спасибо. > Длиннющий же правда конфиг получится.. :) Нужно выбирать - или мы быстро лабаем короткий конфиг из реврайтов, а потом проклинаем их при каждом изменении конфигурации (но переделывать реврайты всё равно не хотим), или же описываем в каждом location'е всё необходимую функциональность, а потом при изменении конфигурации быстро добавляем/изменяем нужное с помощью любимого редактора. -- Igor Sysoev http://nginx.com/support.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: fastcgi cache valid для разных location'ов
On Mar 2, 2013, at 2:45 , Namaste wrote:
> Привет!
>
> Есть примерно такой вот конфиг:
>
> location /aaa/ {
>rewrite ^/aaa/([0-9]+)\.html$ /test.php?p1=$1 last;
> }
>
> location /bbb/ {
>rewrite ^/bbb/([0-9]+)\.html$ /test2.php?p1=$1 last;
> }
>
> location ~ \.php$ {
>fastcgi_pass 127.0.0.1:9000;
>fastcgi_index index.php;
>fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
>include fastcgi_params;
>fastcgi_cache mycache;
>fastcgi_cache_key $scheme$host$request_uri$request_method;
>fastcgi_cache_valid 200 301 302 60m;
> }
>
> Хотелось бы сделать чтоб если срабатывал aaa location, то выдача
> хэшировалась скажем 5 минут, location bbb - 10 минут. Остальное час.
> Как такое сделать?
location /aaa/ {
location ~ ^/aaa/([0-9]+)\.html$ {
fastcgi_pass 127.0.0.1:9000;
includefastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/test1.php;
fastcgi_param QUERY_STRING p1=$page;
fastcgi_cache mycache;
fastcgi_cache_key $scheme$host$request_uri$request_method;
fastcgi_cache_valid 200 301 302 5m;
}
}
и так далее.
--
Igor Sysoev
http://nginx.com/support.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: if_modified_since
On Feb 27, 2013, at 22:44 , Namaste wrote: > Привет! > > Интересно, почему if_modified_since по дефолту установлен в exact, а не в > before? По историческим причинам. Долгое время в nginx'е не было поддержки ETag'а и точное совпадение с If-Modified-Since было некоторым аналогом ETag. Сейчас ETag появился для поддержки download resume в MSIE и, в принципе, можно убрать exact совсем. -- Igor Sysoev http://nginx.com/support.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подскажите как запретить доступ к POST с определенных IP
On Feb 23, 2013, at 19:12 , Andrey Repin wrote:
> Здравствуйте, Уважаемый(-ая, -ое) Maxim Dounin!
>
> MD> Hello!
>
> MD> On Sat, Feb 23, 2013 at 01:26:30PM +0200, Станислав wrote:
>
>>> Подскажите пожалуйста как лучше реализовать запрет на доступ к
>>> методу POST с определенных IP.
>
> MD> Как-то так:
>
> MD> limit_except GET {
> MD> allow 192.168.1.0/32;
> MD> deny all;
> MD> }
>
> Имейте в виду, это убьёт ВСЕ запросы, кроме GET.
Кроме GET и HEAD. Но обычно это и нужно. PUT, DELETE, COPY и
MOVE - это обычно не то, что хочется разрешить для всех.
--
Igor Sysoev
http://nginx.com/support.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Подскажите как запретить доступ к POST с определенных IP
On Feb 23, 2013, at 20:54 , Maxim Dounin wrote:
> Hello!
>
> On Sat, Feb 23, 2013 at 02:30:21PM +0200, Станислав wrote:
>
>> 23.02.2013 13:35, Maxim Dounin пишет:
>>> Hello!
>>>
>>> On Sat, Feb 23, 2013 at 01:26:30PM +0200, Станислав wrote:
>>>
>>>> Подскажите пожалуйста как лучше реализовать запрет на доступ к
>>>> методу POST с определенных IP.
>>> Как-то так:
>>>
>>>limit_except GET {
>>>allow 192.168.1.0/32;
>>>deny all;
>>>}
>>>
>>> http://nginx.org/r/limit_except/ru
>>>
>> Спасибо Максим!
>>
>> Подскажите пожалуйста можно ли избавится от if в такой конструкции:
>>
>> geo $redirect_ip {
>>default0;
>>127.0.0.1 1;
>>192.168.1.0/24 1;
>> }
>>
>> limit_except POST {
>>
>> if ($redirect_ip) {
>> return 301 http://domain.com;
>> }
>>
>> }
>
> Сделав ровно то, что написано выше - написав правила allow/deny
> вместо if'а.
>
> Если тех, кому нельзя, нужно куда-то перенаправлять - то вынести
> эту логику в обработку 403, как-то так:
>
>error_page 403 = /403;
>
> location / {
>limit_except GET {
>allow 127.0.0.1;
>allow 192.168.1.0/2;
>deny all;
>}
>
>...
>}
>
>location = /403 {
>return 301 http://domain.com;
>}
Можно сразу
error_page 403 =301 http://domain.com;
--
Igor Sysoev
http://nginx.com/support.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
