From nginx-forum на forum.nginx.org Fri Dec 1 01:54:33 2017 From: nginx-forum на forum.nginx.org (kjtrtm0) Date: Thu, 30 Nov 2017 20:54:33 -0500 Subject: diy home security systems manufacturers Message-ID: <6b8b456bbe9dc51670cebbcd30caf401.NginxMailingListRussian@forum.nginx.org> Established in 2000, Karassn Security&Protection Electronics Company Ltd is located in Quanzhou, China. We're a professional developer & manufacturer of excellent quality security products.Karassn's one members of China Security Industry Association and Quanzhou Security Technology Association. With strong R&D team, Karassn has developed 14 major lines of security products and more than 100 types of security products, which are widely used in home security, commercial security, and industrial security. We're fully with ISO 9001:2008 standards, and most products have been CCC and CE approved. We firmly believe that the key to the superior perfor-mance of our products is the strict monitoring of each step in the manufacturing process. Karassn History: On Nov. 24, 2000, Karassn was founded. In Mar. 2003, we received ISO9001 certification. In Sep. 2005, with advanced technology from the military, Karassn designed the Long-distance Wireless Receiver for use in extreme outdoor conditions. This design led to our prominent distinction in the field of wireless alarm systems. In Nov. 2005, Karassn was named as one of the "Top Ten Brands of Chinese Nation in Burglar Alarm" by A&S. In 2007 and 2008, Karassn was authorized as an executive member of the Chinese Security Protection Association. Since 2009, Karassn has been selected as one of the "Top Ten Brands in Chinese Security Protection Field" and one of the "Top Ten National Brands in Security Protection Field" by A&S. In Jul. 2011, Karassn was named as a "Security Protection Enterprise" 2012, we begin to develop ip camera and releated wifi products for home security. In May, 2015, established Karassn IP Business Division in Shenzhen, at Oct registered Shenzhen Karassn Smart Technology Co.,Ltd Our goal is to become the premier supplier of security products in China and around the world. We will continue to develop attractive and highest quality products to meet customers' various needs. Karassn Certificate as FCC CE Rosh etc.diy home security systems manufacturers website:http://www.karassnsecurity.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277608,277608#msg-277608 From nginx-forum на forum.nginx.org Fri Dec 1 08:13:48 2017 From: nginx-forum на forum.nginx.org (skeletor) Date: Fri, 01 Dec 2017 03:13:48 -0500 Subject: =?UTF-8?B?UmU6INCu0L3QuNC60YEt0YHQvtC60LXRgiDQuCBmYXN0Y2dpLg==?= In-Reply-To: <1854285.iv6Aee6HSk@cybernote> References: <1854285.iv6Aee6HSk@cybernote> Message-ID: <0f96d80fde18e4a3e7e92cde0c88ca47.NginxMailingListRussian@forum.nginx.org> Более того, я замечал залипания в работе бэкенда: запрос приходит, передаётся на php и на этом всё. Воркер php выглядит как рабочий, но юзер получает 502 (через несколько секунд ожидания). После отключения проблема не наблюдалась. Такое поведение было хаотичным и понять, что именно влияло не было возможности. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277593,277615#msg-277615 From sargaskn на gmail.com Fri Dec 1 13:32:23 2017 From: sargaskn на gmail.com (Sargas) Date: Fri, 1 Dec 2017 15:32:23 +0200 Subject: =?UTF-8?B?UmU6INCu0L3QuNC60YEt0YHQvtC60LXRgiDQuCBmYXN0Y2dpLg==?= In-Reply-To: <0f96d80fde18e4a3e7e92cde0c88ca47.NginxMailingListRussian@forum.nginx.org> References: <1854285.iv6Aee6HSk@cybernote> <0f96d80fde18e4a3e7e92cde0c88ca47.NginxMailingListRussian@forum.nginx.org> Message-ID: Влияло использование в php http://php.net/manual/ru/function.fastcgi-finish-request.php Если в upstream включить keepalive, и выставить в on http://nginx.org/ru/docs/http/ngx_http_fastcgi_module.html#fastcgi_keep_conn , то при использование fastcgi_finish_requestв скриптах ловится 502 1 декабря 2017 г., 10:13 пользователь skeletor написал: > Более того, я замечал залипания в работе бэкенда: запрос приходит, > передаётся на php и на этом всё. Воркер php выглядит как рабочий, но юзер > получает 502 (через несколько секунд ожидания). После отключения проблема > не > наблюдалась. Такое поведение было хаотичным и понять, что именно влияло не > было возможности. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,277593,277615#msg-277615 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Dec 5 09:38:03 2017 From: nginx-forum на forum.nginx.org (Set) Date: Tue, 05 Dec 2017 04:38:03 -0500 Subject: =?UTF-8?B?0JjQt9C80LXQvdC40YLRjCDRgdGC0LDQvdC00LDRgNGC0L3Rg9GOINGB0YLRgNCw?= =?UTF-8?B?0L3QuNGG0YMgNDAwIEJhZCBSZXF1ZXN0?= Message-ID: Добрый день. Коллеги, подскажите, как можно заменить стандартную страницу error_page 400 Bad Request на свою? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277648#msg-277648 From rogat1y на gmail.com Tue Dec 5 09:47:43 2017 From: rogat1y на gmail.com (Maxim K) Date: Tue, 5 Dec 2017 12:47:43 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: Message-ID: https://nginx.ru/ru/docs/http/ngx_http_core_module.html#error_page error_page 400 /400.html; и в root положить 400.html 5 декабря 2017 г., 12:38 пользователь Set написал: > Добрый день. > Коллеги, подскажите, как можно заменить стандартную страницу error_page 400 > Bad Request на свою? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,277648,277648#msg-277648 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From jd на jdwuzhere.ru Tue Dec 5 19:23:34 2017 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Tue, 5 Dec 2017 22:23:34 +0300 Subject: $is_args Message-ID: <1E043DD1-2793-4D40-BF64-01C6CCA9A3B3@jdwuzhere.ru> Привет! Есть вот такой формат лога log_format full '$remote_addr - $remote_user [$time_local] "$request_method $uri$is_args$args $server_protocol" $status $body_bytes_sent "$http_referer” При этом при запросе без параметров в лог пишется вот такой 93.190.229.25 - - [05/Dec/2017:22:20:27 +0300] "GET /login.php- HTTP/1.1" 200 2253 "http://example.com” хотя в доках указано $is_args “?” if a request line has arguments, or an empty string otherwise Баг или ЧЯДНТ? С уважением, ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From sejo412 на gmail.com Wed Dec 6 11:28:36 2017 From: sejo412 на gmail.com (Pavel Sinitskiy) Date: Wed, 6 Dec 2017 14:28:36 +0300 Subject: $is_args In-Reply-To: <1E043DD1-2793-4D40-BF64-01C6CCA9A3B3@jdwuzhere.ru> References: <1E043DD1-2793-4D40-BF64-01C6CCA9A3B3@jdwuzhere.ru> Message-ID: Добрый день, Вас тире смущает? если хочется отсутствие тире, если нет аргументов, то можно попробовать примерно так: map $is_args $r_args { default ''; '?' '?$args'; } log_format full '$remote_addr - $remote_user [$time_local] "$request_method $uri$r_args $server_protocol" $status $body_bytes_sent "$http_referer” не проверено 5 декабря 2017 г., 22:23 пользователь Vladimir Sopot написал: > Привет! > > Есть вот такой формат лога > > log_format full '$remote_addr - $remote_user [$time_local] > "$request_method $uri$is_args$args $server_protocol" $status > $body_bytes_sent "$http_referer” > > При этом при запросе без параметров в лог пишется вот такой > > 93.190.229.25 - - [05/Dec/2017:22:20:27 +0300] "GET /login.php- HTTP/1.1" > 200 2253 "http://example.com” > > хотя в доках указано > > $is_args > “?” if a request line has arguments, or an empty string otherwise > > Баг или ЧЯДНТ? > > С уважением, > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- best reguards Pavel Sinitskiy ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From annulen на yandex.ru Wed Dec 6 11:33:47 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Wed, 06 Dec 2017 14:33:47 +0300 Subject: $is_args In-Reply-To: References: <1E043DD1-2793-4D40-BF64-01C6CCA9A3B3@jdwuzhere.ru> Message-ID: <1137481512560027@web2g.yandex.ru> Вложение в формате HTML было извлечено… URL: From jd на jdwuzhere.ru Wed Dec 6 11:36:12 2017 From: jd на jdwuzhere.ru (Vladimir Sopot) Date: Wed, 6 Dec 2017 14:36:12 +0300 Subject: $is_args In-Reply-To: References: <1E043DD1-2793-4D40-BF64-01C6CCA9A3B3@jdwuzhere.ru> Message-ID: Спасибо Dmitry Pryadko @nginx.com, уже разобрались: “-“ в логе относится не к $is_args, а к $args. Так что всё работает, как надо. > On 6 Dec 2017, at 14:28, Pavel Sinitskiy wrote: > > Добрый день, > > Вас тире смущает? если хочется отсутствие тире, если нет аргументов, то можно попробовать примерно так: > map $is_args $r_args { > default ''; > '?' '?$args'; > } > > log_format full '$remote_addr - $remote_user [$time_local] "$request_method $uri$r_args $server_protocol" $status $body_bytes_sent "$http_referer” > > не проверено > > 5 декабря 2017 г., 22:23 пользователь Vladimir Sopot > написал: > Привет! > > Есть вот такой формат лога > > log_format full '$remote_addr - $remote_user [$time_local] "$request_method $uri$is_args$args $server_protocol" $status $body_bytes_sent "$http_referer” > > При этом при запросе без параметров в лог пишется вот такой > > 93.190.229.25 - - [05/Dec/2017:22:20:27 +0300] "GET /login.php- HTTP/1.1" 200 2253 "http://example.com ” > > хотя в доках указано > > $is_args > “?” if a request line has arguments, or an empty string otherwise > > Баг или ЧЯДНТ? > > С уважением, > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > > -- > > best reguards > Pavel Sinitskiy > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Dec 6 13:01:17 2017 From: nginx-forum на forum.nginx.org (Set) Date: Wed, 06 Dec 2017 08:01:17 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: Message-ID: <0ee6c7082365150cb55942d08e44a7ff.NginxMailingListRussian@forum.nginx.org> Не получатся. Пробовал указать и отдельно локеишином. Что делаю не так? 1. error_page 400 /400.html; 2. error_page 400 /400.html; location = /400.html { root /usr/share/nginx/html/; } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277664#msg-277664 From mdounin на mdounin.ru Wed Dec 6 15:23:20 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 6 Dec 2017 18:23:20 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: <0ee6c7082365150cb55942d08e44a7ff.NginxMailingListRussian@forum.nginx.org> References: <0ee6c7082365150cb55942d08e44a7ff.NginxMailingListRussian@forum.nginx.org> Message-ID: <20171206152320.GL78325@mdounin.ru> Hello! On Wed, Dec 06, 2017 at 08:01:17AM -0500, Set wrote: > Не получатся. Пробовал указать и отдельно локеишином. Что делаю не так? > > 1. error_page 400 /400.html; > > > 2. error_page 400 /400.html; > location = /400.html { > root /usr/share/nginx/html/; > } Скорее всего - вы делаете не там. Ошибки 400 в nginx'е обычно возникают до того, как выбран виртуальный сервер, и соответственно как-то переопределить такую ошибку можно только в сервере по умолчанию. Но вообще я бы не рекомендовал трогать 400-е ошибки. Смысла в этом исчезающе мало, так как пользователь (если он вообще есть) скорее всего эту страницу не увидит - ибо речь идёт про синтаксичеки некорректный запрос. А нарваться на ненужные проблемы - вполне реально, так как nginx'у приходится полноценно обрабатывать такой некорректный запрос. -- Maxim Dounin http://mdounin.ru/ From a.vasilishin на kpi.ua Thu Dec 7 09:02:45 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Thu, 7 Dec 2017 11:02:45 +0200 Subject: =?UTF-8?B?0J3QtSDQv9GA0LDQstC40LvRjNC90YvQuSDQt9Cw0L/RgNC+0YEg0L3QsCDQsdGN?= =?UTF-8?B?0LrQtdC90LQg0L/QvtGB0LvQtSDRgNC10YDQsNC50YLQsA==?= Message-ID: Всем привет! Есть такой локейшн location = /robots.txt { rewrite ^(.*)$ /robots.php last; } в котором прописан рерайт robots.txt -> robots.php, все срабатывает корректно, после рерайта запрос идет в location ~ \.php$ где запрос проксируется на бэкенд и почему в логе вижу передается заголовок: 2017/12/07 00:09:06 [debug] 28037#28037: *264176 http proxy header: "GET /robots.txt HTTP/1.1 и соответственно апач вместо того, чтобы выполнить скрипт robots.php, отдает содержимое файла robots.txt Что делать? # nginx -V nginx version: nginx/1.13.4 built by gcc 4.7.2 (Debian 4.7.2-5) built with OpenSSL 1.0.1t 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' From alex.hha на gmail.com Thu Dec 7 12:31:54 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 7 Dec 2017 14:31:54 +0200 Subject: =?UTF-8?B?0J3QtSDQv9C+0L3Rj9GC0L3QvtC1INC/0L7QstC10LTQtdC90LjQtSDQv9GA0Lgg?= =?UTF-8?B?0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LggcHJveHlfcGFzcyDQsiDQu9C+?= =?UTF-8?B?0LrQtdC50YjQtdC90LU=?= Message-ID: ​​ Привет всем, столкнулся с непонятным поведением # nginx -v nginx version: nginx/1.12.1 # nginx -V nginx version: nginx/1.12.1 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid --lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_stub_status_module --with-http_perl_module=dynamic --with-http_auth_request_module --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ld-opt=' -Wl,-E' Это амазоновская сборка, если это имеет значение # rpm -qa | grep nginx nginx-1.12.1-1.33.amzn1.x86_64 Есть простой конфиг для проксирование запросов на elk server { listen 443 ssl; server_name elk.example.com; ssl_certificate /etc/ssl/nginx/server.crt ssl_certificate_key /etc/ssl/nginx/server.key; ssl_dhparam /etc/ssl/nginx/dhparams.pem; ssl_session_timeout 5m; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:1m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers '..:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK'; location / { auth_basic "Authorization required!"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_set_header Authorization ""; proxy_http_version 1.1; proxy_set_header Connection "Keep-Alive"; proxy_set_header Proxy-Connection "Keep-Alive"; proxy_pass https://elk.us-west-1.es.amazonaws.com; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; } с этой частью никаких проблем нет, она работает как и проложено. Но в этом же сервере есть один тестовый локейшен location /test/ { resolver 172.23.16.2 valid=10s; resolver_timeout 10s; proxy_pass http://fake-upstream.example.com/; error_log /var/log/nginx/debug.log debug; proxy_set_header Authorization ""; proxy_http_version 1.1; proxy_set_header Connection "Keep-Alive"; proxy_set_header Proxy-Connection "Keep-Alive"; proxy_set_header Host "sys-adm.org.ua"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; } Создаю временную запись fake-upstream.example.com с ttl 60s и указываю на свой домен sys-adm.org.ua. Все работает, потом удаляю запись, проверяю что на сервере с nginx она тоже не видится # host fake-upstream.example.com 172.23.16.2 Using domain server: Name: 172.23.16.2 Address: 172.23.16.2#53 Aliases: Host fake-upstream.example.com not found: 3(NXDOMAIN) но при этом nginx все так же проксирует запросы, которые попадают в этот location. Это так и задумано? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Thu Dec 7 12:35:01 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 7 Dec 2017 15:35:01 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/RgNCw0LLQuNC70YzQvdGL0Lkg0LfQsNC/0YDQvtGBINC90LAg?= =?UTF-8?B?0LHRjdC60LXQvdC0INC/0L7RgdC70LUg0YDQtdGA0LDQudGC0LA=?= In-Reply-To: References: Message-ID: <20171207123501.GN78325@mdounin.ru> Hello! On Thu, Dec 07, 2017 at 11:02:45AM +0200, Андрей Василишин wrote: > > Всем привет! > Есть такой локейшн > > > location = /robots.txt { > rewrite ^(.*)$ /robots.php last; > } > > в котором прописан рерайт robots.txt -> robots.php, все срабатывает > корректно, после рерайта запрос идет в location ~ \.php$ где запрос > проксируется на бэкенд и почему в логе вижу передается заголовок: > > 2017/12/07 00:09:06 [debug] 28037#28037: *264176 http proxy header: > "GET /robots.txt HTTP/1.1 > > > и соответственно апач вместо того, чтобы выполнить скрипт robots.php, > отдает содержимое файла robots.txt > > Что делать? Для начала - посмотреть внимательно на то, что написано в proxy_pass. -- Maxim Dounin http://mdounin.ru/ From a.vasilishin на kpi.ua Thu Dec 7 12:38:35 2017 From: a.vasilishin на kpi.ua (=?UTF-8?B?0JDQvdC00YDQtdC5INCS0LDRgdC40LvQuNGI0LjQvQ==?=) Date: Thu, 7 Dec 2017 14:38:35 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0L/RgNCw0LLQuNC70YzQvdGL0Lkg0LfQsNC/0YDQvtGBINC90LAg?= =?UTF-8?B?0LHRjdC60LXQvdC0INC/0L7RgdC70LUg0YDQtdGA0LDQudGC0LA=?= In-Reply-To: <20171207123501.GN78325@mdounin.ru> References: <20171207123501.GN78325@mdounin.ru> Message-ID: <2669075d-b3f0-e72f-ccfc-778b6106bf18@kpi.ua> > Для начала - посмотреть внимательно на то, что написано в > proxy_pass. > Спасибо, Максим! proxy_pass http://backend$request_uri; Странно что там не proxy_pass http://backend$uri; From mdounin на mdounin.ru Thu Dec 7 12:45:22 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 7 Dec 2017 15:45:22 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: References: Message-ID: <20171207124522.GO78325@mdounin.ru> Hello! On Thu, Dec 07, 2017 at 02:31:54PM +0200, Alex Domoradov wrote: > Привет всем, столкнулся с непонятным поведением [...] > с этой частью никаких проблем нет, она работает как и проложено. Но в этом > же сервере есть один тестовый локейшен > > location /test/ { > resolver 172.23.16.2 valid=10s; > resolver_timeout 10s; > proxy_pass http://fake-upstream.example.com/; [...] > Создаю временную запись fake-upstream.example.com с ttl 60s и указываю на > свой домен sys-adm.org.ua. Все работает, потом удаляю запись, проверяю что > на сервере с nginx она тоже не видится > > # host fake-upstream.example.com 172.23.16.2 > Using domain server: > Name: 172.23.16.2 > Address: 172.23.16.2#53 > Aliases: > > Host fake-upstream.example.com not found: 3(NXDOMAIN) > > но при этом nginx все так же проксирует запросы, которые попадают в этот > location. Это так и задумано? Да. Имена, явно написанные в конфиге, резолвятся на этапе чтения конфигурации. Если они изменились и надо обновить конфигурацию - следует сказать nginx'у, чтобы он перезагрузил конфигурацию, см. http://nginx.org/ru/docs/control.html#reconfiguration. Исключения - "server ... resolve" в nginx-plus (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve) и случаи, когда в proxy_pass используются переменные, и соответственно имена не известны в момент парсинга конфигурации. В этих случаях будет использован resolver. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Dec 7 12:52:04 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 7 Dec 2017 15:52:04 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/RgNCw0LLQuNC70YzQvdGL0Lkg0LfQsNC/0YDQvtGBINC90LAg?= =?UTF-8?B?0LHRjdC60LXQvdC0INC/0L7RgdC70LUg0YDQtdGA0LDQudGC0LA=?= In-Reply-To: <2669075d-b3f0-e72f-ccfc-778b6106bf18@kpi.ua> References: <20171207123501.GN78325@mdounin.ru> <2669075d-b3f0-e72f-ccfc-778b6106bf18@kpi.ua> Message-ID: <20171207125204.GP78325@mdounin.ru> Hello! On Thu, Dec 07, 2017 at 02:38:35PM +0200, Андрей Василишин wrote: > > > Для начала - посмотреть внимательно на то, что написано в > > proxy_pass. > > > > Спасибо, Максим! > > proxy_pass http://backend$request_uri; Что и объясняет наблюдаемое поведение. > Странно что там не > proxy_pass http://backend$uri; Так точно не надо. В общем случае $uri - это URI запроса со снятным эскейпингом, в то время как proxy_pass ожидает корректно поэскейпленный аргумент. Использование $uri в proxy_pass без контроля содержимого гарантировано приведёт к security-проблемам. Правильно просто ничего не указывать: proxy_pass http://backend; тогда nginx сформирует URI запроса на бэкенд самостоятельно исходя из текущего URI запроса. -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Thu Dec 7 13:01:56 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 7 Dec 2017 15:01:56 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <20171207124522.GO78325@mdounin.ru> References: <20171207124522.GO78325@mdounin.ru> Message-ID: Понятно, просто изначально проблема была немного другой. В location /test/ не было указано никаких резолверов, и он проксировал на тестовый инстанс elk, который со временем удалили, при этом перестало работать проксирование и на основной elk, который находится в корневом локейшене. Пользователи стали получать - "504 Gateway Time-out". В error.log при этом было 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream " search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46 Это тоже нормальное поведение, что если в любом из локейшенов в пределах одного сервера, перестает резолвиться апстрим, то перестает работать весь сервер? Я пробовал воспроизвести проблему, но не получилось. Единственное отличие это то, что в первом случае, когда стал не доступен корневой апстрим, с момента запуска nginx до момента возникновения проблемы прошел месяц. Такое ощущение, что сбросились какие то кеши. 2017-12-07 14:45 GMT+02:00 Maxim Dounin : > Hello! > > On Thu, Dec 07, 2017 at 02:31:54PM +0200, Alex Domoradov wrote: > > > Привет всем, столкнулся с непонятным поведением > > [...] > > > с этой частью никаких проблем нет, она работает как и проложено. Но в > этом > > же сервере есть один тестовый локейшен > > > > location /test/ { > > resolver 172.23.16.2 valid=10s; > > resolver_timeout 10s; > > proxy_pass http://fake-upstream.example.com/; > > [...] > > > Создаю временную запись fake-upstream.example.com с ttl 60s и указываю > на > > свой домен sys-adm.org.ua. Все работает, потом удаляю запись, проверяю > что > > на сервере с nginx она тоже не видится > > > > # host fake-upstream.example.com 172.23.16.2 > > Using domain server: > > Name: 172.23.16.2 > > Address: 172.23.16.2#53 > > Aliases: > > > > Host fake-upstream.example.com not found: 3(NXDOMAIN) > > > > но при этом nginx все так же проксирует запросы, которые попадают в этот > > location. Это так и задумано? > > Да. Имена, явно написанные в конфиге, резолвятся на этапе чтения > конфигурации. Если они изменились и надо обновить конфигурацию - > следует сказать nginx'у, чтобы он перезагрузил конфигурацию, см. > http://nginx.org/ru/docs/control.html#reconfiguration. > > Исключения - "server ... resolve" в nginx-plus > (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve) > и случаи, когда в proxy_pass используются переменные, и > соответственно имена не известны в момент парсинга конфигурации. > В этих случаях будет использован resolver. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Thu Dec 7 13:25:23 2017 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Thu, 7 Dec 2017 16:25:23 +0300 Subject: =?UTF-8?B?0LDQv9GB0YLRgNC40Lwg0YDQtdC20LXRgiDQt9Cw0L/RgNC+0YHRiz8=?= Message-ID: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> Добрый день, Ситуация следующая: 1) В error логе куча ошибок вида: 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx", host: “xxx:8080" 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда около 4 секунд? Это похоже на то, что апстрим режет запросы rps фильтром? Евгений From mdounin на mdounin.ru Thu Dec 7 13:33:51 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 7 Dec 2017 16:33:51 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: References: <20171207124522.GO78325@mdounin.ru> Message-ID: <20171207133351.GQ78325@mdounin.ru> Hello! On Thu, Dec 07, 2017 at 03:01:56PM +0200, Alex Domoradov wrote: > Понятно, просто изначально проблема была немного другой. > > В location /test/ не было указано никаких резолверов, и он проксировал на > тестовый инстанс elk, который со временем удалили, при этом перестало > работать проксирование и на основной elk, который находится в корневом > локейшене. Пользователи стали получать - "504 Gateway Time-out". В > error.log при этом было > > 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream " > search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46 > > Это тоже нормальное поведение, что если в любом из локейшенов в пределах > одного сервера, перестает резолвиться апстрим, то перестает работать весь > сервер? Я пробовал воспроизвести проблему, но не получилось. Единственное > отличие это то, что в первом случае, когда стал не доступен корневой > апстрим, с момента запуска nginx до момента возникновения проблемы прошел > месяц. Такое ощущение, что сбросились какие то кеши. Если какое-либо из имён, указанных в конфигурации, не резолвится - то это повод отклонить такую конфигурацию. Приведённая ошибка - это как раз ошибка парсинга конфигурации. Соответственно, если такое происходит при попытке перезагрузить конфигурацию - то nginx просто продолжит работать со старой конфигурацией. Если же вы зачем-то сначала остановили nginx, а потом пытаетесь запустить его с конфигурацией, в которой указано несуществующее имя - то сначала придётся конфигурацию исправить, и только после этого nginx запустится. (Отмечу в скобках, что некоторые по привычке используют restart вместо reload при изменениях конфигурации. Так делать не надо - это, во-первых, приводит к потере запросов в момент перезапуска, а во-вторых - может привести к полной недоступности сервиса, если старый nginx завершится, а новый не сможет стартовать из-за каких-то проблем. Лучше всегда использовать reload, а при необходимости обновления исполняемого файла - upgrade. Такой подход позволяет гарантировать, что nginx продолжит работать в любых условиях. Подробнее про всё это написано на странице http://nginx.org/ru/docs/control.html.) -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Thu Dec 7 15:11:13 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Thu, 7 Dec 2017 17:11:13 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <20171207133351.GQ78325@mdounin.ru> References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> Message-ID: В том то и дело, что никто ни reload ни restart не делал. nginx работал с 7го ноября без каких либо вмешательств. И перестал сегодня утром. Попробую уточнить, когда был удален апстрим в локейшене test 2017-12-07 15:33 GMT+02:00 Maxim Dounin : > Hello! > > On Thu, Dec 07, 2017 at 03:01:56PM +0200, Alex Domoradov wrote: > > > Понятно, просто изначально проблема была немного другой. > > > > В location /test/ не было указано никаких резолверов, и он проксировал на > > тестовый инстанс elk, который со временем удалили, при этом перестало > > работать проксирование и на основной elk, который находится в корневом > > локейшене. Пользователи стали получать - "504 Gateway Time-out". В > > error.log при этом было > > > > 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream " > > search-testing.us-west-1.es.amazonaws.com" in > /etc/nginx/conf.d/elk.conf:46 > > > > Это тоже нормальное поведение, что если в любом из локейшенов в пределах > > одного сервера, перестает резолвиться апстрим, то перестает работать весь > > сервер? Я пробовал воспроизвести проблему, но не получилось. Единственное > > отличие это то, что в первом случае, когда стал не доступен корневой > > апстрим, с момента запуска nginx до момента возникновения проблемы прошел > > месяц. Такое ощущение, что сбросились какие то кеши. > > Если какое-либо из имён, указанных в конфигурации, не резолвится - > то это повод отклонить такую конфигурацию. Приведённая ошибка - > это как раз ошибка парсинга конфигурации. > > Соответственно, если такое происходит при попытке перезагрузить > конфигурацию - то nginx просто продолжит работать со старой > конфигурацией. > > Если же вы зачем-то сначала остановили nginx, а потом пытаетесь > запустить его с конфигурацией, в которой указано несуществующее > имя - то сначала придётся конфигурацию исправить, и только после > этого nginx запустится. > > (Отмечу в скобках, что некоторые по привычке используют restart > вместо reload при изменениях конфигурации. Так делать не надо - > это, во-первых, приводит к потере запросов в момент перезапуска, а > во-вторых - может привести к полной недоступности сервиса, если > старый nginx завершится, а новый не сможет стартовать из-за > каких-то проблем. Лучше всегда использовать reload, а при > необходимости обновления исполняемого файла - upgrade. Такой > подход позволяет гарантировать, что nginx продолжит работать в > любых условиях. Подробнее про всё это написано на странице > http://nginx.org/ru/docs/control.html.) > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Dec 8 13:36:43 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 8 Dec 2017 16:36:43 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> Message-ID: <20171208133642.GR78325@mdounin.ru> Hello! On Thu, Dec 07, 2017 at 05:11:13PM +0200, Alex Domoradov wrote: > В том то и дело, что никто ни reload ни restart не делал. nginx работал с > 7го ноября без каких либо вмешательств. И перестал сегодня утром. Попробую > уточнить, когда был удален апстрим в локейшене test Процитированное сообщение об ошибке: > > > 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream "search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46 чётко и однозначно говорит о том, что nginx парсил конфигурацию и в процессе произошла ошибка. Сам по себе nginx подобным в процессе работы не занимается - его тем или иным способом об этом попросили. Как именно и кто попросил - это уже, боюсь, разбираться вам. Чтобы было проще - стоит включить логгирование как минимум на уровне notice, там, в частности, логгируются все полученные nginx'ом сигналы (а начиная с 1.13.0 ещё и указывается PID отправившего сигнал процесса, но у вас версия старее). Отмечу также, что: - на линуксах часто в процессе обновления пакетов практикуется restart сервиса. Если пакет для nginx'а сделан криво и не умеет делать upgrade - то обновление пакетов может быть причиной restart'а и всех сопутствующих проблем. - зачастую всякие скрипты вращения логов и тому подобного - делают не просто странное (скажем, HUP, то есть configuration reload, вместо USR1), а очень странное, вплоть до restart'а или даже просто остановки сервера без попыток его запустить обратно. -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Fri Dec 8 14:11:19 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 8 Dec 2017 16:11:19 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <20171208133642.GR78325@mdounin.ru> References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> <20171208133642.GR78325@mdounin.ru> Message-ID: Да, это я знаю. Тогда у меня возникает вопрос Скорее всего ошибка host not found in upstream " search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46 действительно была вызвана попыткой сделать reload/restart. Но раз nginx работал, значит restart не производился. Возможно действительно был reload. Но он бы не применился по причине ошибки резолвинга. Сам домен был удален примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда перестал открываться ELK(кибана) Больше никаких ошибок в error.log не было. Тогда не понятно, почему перестало работать проксирование из корневого локейшена, а возвращалась 504 ошибка? У меня к сожалению не удалось воспроизвести это поведение > зачастую всякие скрипты вращения логов и тому подобного - делают не просто странное (скажем, HUP, то есть configuration reload, вместо USR1), а очень странное, вплоть до restart'а или даже просто остановки сервера без попыток его запустить обратно. Я глянул, логротейт выглядит вот так # rpm -ql nginx | grep logrotate | xargs cat /var/log/nginx/*log { create 0644 nginx nginx daily rotate 10 missingok notifempty compress sharedscripts postrotate /etc/init.d/nginx reopen_logs endscript } сама функция выглядит вот так reopen_logs() { configtest_q || return 6 echo -n $"Reopening $prog logs: " killproc -p $pidfile $prog -USR1 retval=$? echo return $retval } Вроде как ничего необычного 2017-12-08 15:36 GMT+02:00 Maxim Dounin : > Hello! > > On Thu, Dec 07, 2017 at 05:11:13PM +0200, Alex Domoradov wrote: > > > В том то и дело, что никто ни reload ни restart не делал. nginx работал с > > 7го ноября без каких либо вмешательств. И перестал сегодня утром. > Попробую > > уточнить, когда был удален апстрим в локейшене test > > Процитированное сообщение об ошибке: > > > > > 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream " > search-testing.us-west-1.es.amazonaws.com" in > /etc/nginx/conf.d/elk.conf:46 > > чётко и однозначно говорит о том, что nginx парсил конфигурацию и > в процессе произошла ошибка. Сам по себе nginx подобным в > процессе работы не занимается - его тем или иным способом об этом > попросили. > > Как именно и кто попросил - это уже, боюсь, разбираться вам. > Чтобы было проще - стоит включить логгирование как минимум на > уровне notice, там, в частности, логгируются все полученные > nginx'ом сигналы (а начиная с 1.13.0 ещё и указывается PID > отправившего сигнал процесса, но у вас версия старее). > > Отмечу также, что: > > - на линуксах часто в процессе обновления пакетов практикуется > restart сервиса. Если пакет для nginx'а сделан криво и не умеет > делать upgrade - то обновление пакетов может быть причиной > restart'а и всех сопутствующих проблем. > > - зачастую всякие скрипты вращения логов и тому подобного - делают > не просто странное (скажем, HUP, то есть configuration reload, > вместо USR1), а очень странное, вплоть до restart'а или даже > просто остановки сервера без попыток его запустить обратно. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Dec 8 14:23:14 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 8 Dec 2017 17:23:14 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> <20171208133642.GR78325@mdounin.ru> Message-ID: <20171208142314.GS78325@mdounin.ru> Hello! On Fri, Dec 08, 2017 at 04:11:19PM +0200, Alex Domoradov wrote: > Да, это я знаю. Тогда у меня возникает вопрос > > Скорее всего ошибка host not found in upstream " > search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46 > действительно была вызвана попыткой сделать reload/restart. Но раз nginx > работал, значит restart не производился. Возможно действительно был reload. > Но он бы не применился по причине ошибки резолвинга. Сам домен был удален > примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда > перестал открываться ELK(кибана) > > Больше никаких ошибок в error.log не было. Тогда не понятно, почему > перестало работать проксирование из корневого локейшена, а возвращалась 504 > ошибка? У меня к сожалению не удалось воспроизвести это поведение Если 504 возвращал именно nginx, а не какой-нибудь ELB перед ним, то a) очевидно, что nginx был запущен и работал, и б) проблема была в том, что он не мог добраться до конкретного бэкенда. Почему не мог - отдельный вопрос. Например, такое могло случиться из-за того, что IP-адреса бэкендов поменялись, а reload nginx'у, чтобы он подобрал эти изменившиеся IP-адреса, никто не сказал. В результате nginx продолжал ходить на старые адреса, где ему не отвечали. В логах будут подробности на уровне error, включая IP-адреса, куда nginx пытался ходить. -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Fri Dec 8 14:44:12 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 8 Dec 2017 16:44:12 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <20171208142314.GS78325@mdounin.ru> References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> <20171208133642.GR78325@mdounin.ru> <20171208142314.GS78325@mdounin.ru> Message-ID: Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать только CNAME при ссылке на ELB так как адреса могут поменяться. Because the set of IP addresses associated with a LoadBalancer can change over time, you should never create an "A" record with any specific IP address. If you want to use a friendly DNS name for your load balancer instead of the name generated by the Elastic Load Balancing service, you should create a CNAME record for the LoadBalancer DNS name В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по выводу $ host search-production.us-west-1.es.amazonaws.com search-production.us-west-1.es.amazonaws.com has address 52.8.xxx.xxx search-production.us-west-1.es.amazonaws.com has address 13.57.xxx.xxx $ host 52.8.xxx.xxx xxx.xxx.8.52.in-addr.arpa domain name pointer ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com. $ host 13.57.xxx.xxx xxx.xxx.57.13.in-addr.arpa domain name pointer ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com. В моем случае получается, что nginx при старте отрезолвил имя search-production.us-west-1.es.amazonaws.com в одну пару ip адресов, а со временем они поменялись. И скорее всего я и получил эту ошибку. Отслеживать в ручную и делать reload это конечно не вариант. А как вообще стоит тогда настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать подобных проблем в будущем? 2017-12-08 16:23 GMT+02:00 Maxim Dounin : > Hello! > > On Fri, Dec 08, 2017 at 04:11:19PM +0200, Alex Domoradov wrote: > > > Да, это я знаю. Тогда у меня возникает вопрос > > > > Скорее всего ошибка host not found in upstream " > > search-testing.us-west-1.es.amazonaws.com" in > /etc/nginx/conf.d/elk.conf:46 > > действительно была вызвана попыткой сделать reload/restart. Но раз nginx > > работал, значит restart не производился. Возможно действительно был > reload. > > Но он бы не применился по причине ошибки резолвинга. Сам домен был удален > > примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда > > перестал открываться ELK(кибана) > > > > Больше никаких ошибок в error.log не было. Тогда не понятно, почему > > перестало работать проксирование из корневого локейшена, а возвращалась > 504 > > ошибка? У меня к сожалению не удалось воспроизвести это поведение > > Если 504 возвращал именно nginx, а не какой-нибудь ELB перед ним, > то a) очевидно, что nginx был запущен и работал, и б) проблема > была в том, что он не мог добраться до конкретного бэкенда. > Почему не мог - отдельный вопрос. > > Например, такое могло случиться из-за того, что IP-адреса бэкендов > поменялись, а reload nginx'у, чтобы он подобрал эти изменившиеся > IP-адреса, никто не сказал. В результате nginx продолжал ходить > на старые адреса, где ему не отвечали. В логах будут подробности > на уровне error, включая IP-адреса, куда nginx пытался ходить. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Dec 8 15:27:18 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 8 Dec 2017 18:27:18 +0300 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> <20171208133642.GR78325@mdounin.ru> <20171208142314.GS78325@mdounin.ru> Message-ID: <20171208152718.GU78325@mdounin.ru> Hello! On Fri, Dec 08, 2017 at 04:44:12PM +0200, Alex Domoradov wrote: > Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать > только CNAME при ссылке на ELB так как адреса могут поменяться. > > Because the set of IP addresses associated with a LoadBalancer can change > over time, you should never create an "A" record with any specific IP > address. If you want to use a friendly DNS name for your load balancer > instead of the name generated by the Elastic Load Balancing service, you > should create a CNAME record for the LoadBalancer DNS name > > В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по выводу > > $ host search-production.us-west-1.es.amazonaws.com > search-production.us-west-1.es.amazonaws.com has address 52.8.xxx.xxx > search-production.us-west-1.es.amazonaws.com has address 13.57.xxx.xxx > > $ host 52.8.xxx.xxx > xxx.xxx.8.52.in-addr.arpa domain name pointer > ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com. > > $ host 13.57.xxx.xxx > xxx.xxx.57.13.in-addr.arpa domain name pointer > ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com. > > В моем случае получается, что nginx при старте отрезолвил имя > search-production.us-west-1.es.amazonaws.com в одну пару ip адресов, а со > временем они поменялись. И скорее всего я и получил эту ошибку. Отслеживать > в ручную и делать reload это конечно не вариант. А как вообще стоит тогда > настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать > подобных проблем в будущем? Если вы проксируете на имена, которые не контроллируете, и IP-адреса могут меняться, то стоит посмотреть в сторону случаев, перечисленных в моём первом ответе, http://mailman.nginx.org/pipermail/nginx-ru/2017-December/060685.html: : Исключения - "server ... resolve" в nginx-plus : (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve) : и случаи, когда в proxy_pass используются переменные, и : соответственно имена не известны в момент парсинга конфигурации. : В этих случаях будет использован resolver. -- Maxim Dounin http://mdounin.ru/ From alex.hha на gmail.com Fri Dec 8 15:51:38 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Fri, 8 Dec 2017 17:51:38 +0200 Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg0L8=?= =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70YzQt9C+0LLQsNC90LjQuCBwcm94eV9wYXNzINCy?= =?UTF-8?B?INC70L7QutC10LnRiNC10L3QtQ==?= In-Reply-To: <20171208152718.GU78325@mdounin.ru> References: <20171207124522.GO78325@mdounin.ru> <20171207133351.GQ78325@mdounin.ru> <20171208133642.GR78325@mdounin.ru> <20171208142314.GS78325@mdounin.ru> <20171208152718.GU78325@mdounin.ru> Message-ID: Т.е. в бесплатной версии nginx у данной проблемы решения нет, я правильно понял? 2017-12-08 17:27 GMT+02:00 Maxim Dounin : > Hello! > > On Fri, Dec 08, 2017 at 04:44:12PM +0200, Alex Domoradov wrote: > > > Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать > > только CNAME при ссылке на ELB так как адреса могут поменяться. > > > > Because the set of IP addresses associated with a LoadBalancer can change > > over time, you should never create an "A" record with any specific IP > > address. If you want to use a friendly DNS name for your load balancer > > instead of the name generated by the Elastic Load Balancing service, you > > should create a CNAME record for the LoadBalancer DNS name > > > > В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по > выводу > > > > $ host search-production.us-west-1.es.amazonaws.com > > search-production.us-west-1.es.amazonaws.com has address 52.8.xxx.xxx > > search-production.us-west-1.es.amazonaws.com has address 13.57.xxx.xxx > > > > $ host 52.8.xxx.xxx > > xxx.xxx.8.52.in-addr.arpa domain name pointer > > ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com. > > > > $ host 13.57.xxx.xxx > > xxx.xxx.57.13.in-addr.arpa domain name pointer > > ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com. > > > > В моем случае получается, что nginx при старте отрезолвил имя > > search-production.us-west-1.es.amazonaws.com в одну пару ip адресов, а > со > > временем они поменялись. И скорее всего я и получил эту ошибку. > Отслеживать > > в ручную и делать reload это конечно не вариант. А как вообще стоит тогда > > настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать > > подобных проблем в будущем? > > Если вы проксируете на имена, которые не контроллируете, и > IP-адреса могут меняться, то стоит посмотреть в сторону случаев, > перечисленных в моём первом ответе, > http://mailman.nginx.org/pipermail/nginx-ru/2017-December/060685.html: > > : Исключения - "server ... resolve" в nginx-plus > : (http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve) > : и случаи, когда в proxy_pass используются переменные, и > : соответственно имена не известны в момент парсинга конфигурации. > : В этих случаях будет использован resolver. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vp7 на mail.ru Fri Dec 8 16:08:43 2017 From: vp7 на mail.ru (=?UTF-8?B?Vml0YWx5IFBvbm9tYXJldg==?=) Date: Fri, 08 Dec 2017 19:08:43 +0300 Subject: =?UTF-8?B?UmVbMl06INCd0LUg0L/QvtC90Y/RgtC90L7QtSDQv9C+0LLQtdC00LXQvdC40LUg?= =?UTF-8?B?0L/RgNC4INC40YHQv9C+0LvRjNC30L7QstCw0L3QuNC4IHByb3h5X3Bhc3Mg?= =?UTF-8?B?0LIg0LvQvtC60LXQudGI0LXQvdC1?= In-Reply-To: References: <20171208152718.GU78325@mdounin.ru> Message-ID: <1512749323.263570556@f450.i.mail.ru> Максим же написал, что можно использовать переменные в proxy_pass, а они (насколько я понял) доступны и в бесплатной версии. -- Отправлено из Mail.Ru для Android пятница, 08 декабря 2017г., 18:51 +03:00 от Alex Domoradov alex.hha на gmail.com : >Т.е. в бесплатной версии nginx у данной проблемы решения нет, я правильно понял? > >2017-12-08 17:27 GMT+02:00 Maxim Dounin < mdounin на mdounin.ru > : >>Hello! >> >>On Fri, Dec 08, 2017 at 04:44:12PM +0200, Alex Domoradov wrote: >> >>> Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать >>> только CNAME при ссылке на ELB так как адреса могут поменяться. >>> >>> Because the set of IP addresses associated with a LoadBalancer can change >>> over time, you should never create an "A" record with any specific IP >>> address. If you want to use a friendly DNS name for your load balancer >>> instead of the name generated by the Elastic Load Balancing service, you >>> should create a CNAME record for the LoadBalancer DNS name >>> >>> В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по выводу >>> >>> $ host search-production.us-west-1.es.amazonaws.com >>> search-production.us-west-1.es.amazonaws.com has address 52.8.xxx.xxx >>> search-production.us-west-1.es.amazonaws.com has address 13.57.xxx.xxx >>> >>> $ host 52.8.xxx.xxx >>> xxx.xxx.8.52.in-addr.arpa domain name pointer >>> ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com . >>> >>> $ host 13.57.xxx.xxx >>> xxx.xxx.57.13.in-addr.arpa domain name pointer >>> ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com . >>> >>> В моем случае получается, что nginx при старте отрезолвил имя >>> search-production.us-west-1.es.amazonaws.com в одну пару ip адресов, а со >>> временем они поменялись. И скорее всего я и получил эту ошибку. Отслеживать >>> в ручную и делать reload это конечно не вариант. А как вообще стоит тогда >>> настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать >>> подобных проблем в будущем? >> >>Если вы проксируете на имена, которые не контроллируете, и >>IP-адреса могут меняться, то стоит посмотреть в сторону случаев, >>перечисленных в моём первом ответе, >>http://mailman.nginx.org/pipermail/nginx-ru/2017-December/060685.html : >> >>: Исключения - "server ... resolve" в nginx-plus >>: ( http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#resolve ) >>: и случаи, когда в proxy_pass используются переменные, и >>: соответственно имена не известны в момент парсинга конфигурации. >>: В этих случаях будет использован resolver. >> >>-- >>Maxim Dounin >>http://mdounin.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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Dec 10 08:01:22 2017 From: nginx-forum на forum.nginx.org (IvanMiller) Date: Sun, 10 Dec 2017 03:01:22 -0500 Subject: =?UTF-8?B?0KfRgtC+INC00LXQu9Cw0LXRgiBuZ2lueA==?= Message-ID: Привет. Имеется nginx + php-fpm. Вот налетело пользователей 2.5 к чего то делают там на сайте. Все работает проблемм нет. При этом nginx в top на первых местах по нагрузке, за ним php-fpm, это при том, что сайт на скрипте. Как понять, почему nginx грузит проц, чем он занят ? Ведь основная логика на php, он и должен поедать все, как мне кажется. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277715,277715#msg-277715 From vovansystems на gmail.com Sun Dec 10 09:00:53 2017 From: vovansystems на gmail.com (VovansystemS) Date: Sun, 10 Dec 2017 12:00:53 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: References: Message-ID: > Вот налетело пользователей 2.5 к чего то делают там на сайте. > Все работает проблемм нет. При этом nginx в top на первых местах по > нагрузке, за ним php-fpm, это при том, что сайт на скрипте. > Как понять, почему nginx грузит проц, чем он занят ? Ведь основная логика на > php, он и должен поедать все, как мне кажется. а у Вас HTTPS есть? если есть, то, видимо, шифрует. особенно, если не настроено кеширование https сессий http://nginx.org/ru/docs/http/configuring_https_servers.html#optimization From chipitsine на gmail.com Sun Dec 10 10:33:50 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 10 Dec 2017 15:33:50 +0500 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: References: Message-ID: ngx google pertools попробуйте On Dec 10, 2017 1:01 PM, "IvanMiller" wrote: > Привет. > Имеется nginx + php-fpm. > Вот налетело пользователей 2.5 к чего то делают там на сайте. > Все работает проблемм нет. При этом nginx в top на первых местах по > нагрузке, за ним php-fpm, это при том, что сайт на скрипте. > Как понять, почему nginx грузит проц, чем он занят ? Ведь основная логика > на > php, он и должен поедать все, как мне кажется. > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,277715,277715#msg-277715 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Sun Dec 10 13:25:35 2017 From: nginx-forum на forum.nginx.org (IvanMiller) Date: Sun, 10 Dec 2017 08:25:35 -0500 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: References: Message-ID: Спасибо. Ознакомлюсь. Попробовал strace , интересно, но сильно много всего.... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277715,277719#msg-277719 From vbart на nginx.com Sun Dec 10 13:29:41 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 10 Dec 2017 16:29:41 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: References: Message-ID: <1902722.W2MOYlMe0u@vbart-laptop> On Sunday, 10 December 2017 11:01:22 MSK IvanMiller wrote: > Привет. > Имеется nginx + php-fpm. > Вот налетело пользователей 2.5 к чего то делают там на сайте. > Все работает проблемм нет. При этом nginx в top на первых местах по > нагрузке, за ним php-fpm, это при том, что сайт на скрипте. > Как понять, почему nginx грузит проц, чем он занят ? Ведь основная логика на > php, он и должен поедать все, как мне кажется. > Т.к. конфигурацию вы не показали, то остается пользоваться телепатическими методами. Одно из предположений gzip_comp_level 9 или около того. -- Валентин Бартенев From annulen на yandex.ru Sun Dec 10 14:34:27 2017 From: annulen на yandex.ru (Konstantin Tokarev) Date: Sun, 10 Dec 2017 17:34:27 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: <1902722.W2MOYlMe0u@vbart-laptop> References: <1902722.W2MOYlMe0u@vbart-laptop> Message-ID: <1139391512916467@web2j.yandex.ru> 10.12.2017, 16:29, "Валентин Бартенев" : > On Sunday, 10 December 2017 11:01:22 MSK IvanMiller wrote: >>  Привет. >>  Имеется nginx + php-fpm. >>  Вот налетело пользователей 2.5 к чего то делают там на сайте. >>  Все работает проблемм нет. При этом nginx в top на первых местах по >>  нагрузке, за ним php-fpm, это при том, что сайт на скрипте. >>  Как понять, почему nginx грузит проц, чем он занят ? Ведь основная логика на >>  php, он и должен поедать все, как мне кажется. > > Т.к. конфигурацию вы не показали, то остается пользоваться телепатическими > методами. > > Одно из предположений gzip_comp_level 9 или около того. Кстати, а есть планы по поддержке zstd? Эта штука жмет лучше gzip при меньших затратах CPU. Поддержка на стороне клиентов пока почти никакая, но должен же кто-то начинать :) https://tools.ietf.org/id/draft-kucherawy-dispatch-zstd-01.html > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Regards, Konstantin From nginx-forum на forum.nginx.org Sun Dec 10 15:56:31 2017 From: nginx-forum на forum.nginx.org (IvanMiller) Date: Sun, 10 Dec 2017 10:56:31 -0500 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: <1902722.W2MOYlMe0u@vbart-laptop> References: <1902722.W2MOYlMe0u@vbart-laptop> Message-ID: Gzip off стоит, включение оного на производительность никак не влияет. вот и конфиг. user www-data; worker_processes auto; pid /run/nginx.pid; events { worker_connections 768; use epoll; multi_accept on; } http { ## # Basic Settings ## sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 100000; types_hash_max_size 2048; # server_tokens off; client_max_body_size 20M; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; ## # SSL Settings ## log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; ssl_session_cache shared:SSL:10m; ssl_session_timeout 16m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; ssl_dhparam /ssl/dhparam.pem; ## # Logging Settings ## access_log off; # error_log off; #access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; ## # Gzip Settings ## gzip off; gzip_disable "msie6"; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; ## # Virtual Host Configs ## } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277715,277723#msg-277723 From alexey на remizov.org Mon Dec 11 08:16:04 2017 From: alexey на remizov.org (Alexey Remizov) Date: Mon, 11 Dec 2017 11:16:04 +0300 Subject: =?UTF-8?B?MS4xMi4yINC/0L7QtCBkZWJpYW4gd2hlZXp5?= Message-ID: <7d141904-bb05-e2f9-142a-d566fbea95c8@remizov.org> Здравствуйте. Сейчас последняя сборка под wheezy - 1.12.1. 1.12.2 забыли собрать или stable под wheezy больше официально не поддерживается? -- С уважением. WBR. Алексей. Alexey. mailto:alexey на remizov.org jabber:remizov на jabber.ru From thresh на nginx.com Mon Dec 11 08:41:09 2017 From: thresh на nginx.com (Konstantin Pavlov) Date: Mon, 11 Dec 2017 11:41:09 +0300 Subject: =?UTF-8?B?UmU6IDEuMTIuMiDQv9C+0LQgZGViaWFuIHdoZWV6eQ==?= In-Reply-To: <7d141904-bb05-e2f9-142a-d566fbea95c8@remizov.org> References: <7d141904-bb05-e2f9-142a-d566fbea95c8@remizov.org> Message-ID: <727d409a-3504-2ba0-64e2-278ed888d1ee@nginx.com> Здравствуйте, Alexey, On 11/12/2017 11:16, Alexey Remizov wrote: > Здравствуйте. > > Сейчас последняя сборка под wheezy - 1.12.1. > > 1.12.2 забыли собрать или stable под wheezy больше официально не > поддерживается? Wheezy больше не поддерживается, по ряду причин: 1/ EOL в Debian (да, я знаю про LTS, но это не совсем то, что можно назвать полноценной security-поддержкой) 2/ Некоторые изменения в debian/, которые не позволяют оставить совместимость с wheezy - поддержка systemd. Ну и в целом, использовать oldoldstable пора бы уже прекращать, в мае 2018 закончится даже волонтерский LTS для него. -- Konstantin Pavlov www.nginx.com From alex.hha на gmail.com Mon Dec 11 10:55:02 2017 From: alex.hha на gmail.com (Alex Domoradov) Date: Mon, 11 Dec 2017 12:55:02 +0200 Subject: =?UTF-8?B?0KHQsdC+0YDQutCwIG5naW54INGBIC0td2l0aC1kZWJ1Zw==?= Message-ID: Привет, подскажите, есть ли какие то накладные расходы при запуске nginx, который был собран с опцией --with-debug ? Ну кроме небольшого увеличения размера самого бинарника. Или пока мы нигде в error_log не указываем debug, то никаких "проседаний" по производительности и не будет? Например в вашем официальном docker образе идет два отдельных бинарника - nginx и nginx-debug. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Mon Dec 11 11:00:32 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 11 Dec 2017 14:00:32 +0300 Subject: =?UTF-8?B?UmU6INCh0LHQvtGA0LrQsCBuZ2lueCDRgSAtLXdpdGgtZGVidWc=?= In-Reply-To: References: Message-ID: <2351438.4gSzSTR5h4@vbart-laptop> On Monday, 11 December 2017 13:55:02 MSK Alex Domoradov wrote: > Привет, > > подскажите, есть ли какие то накладные расходы при запуске nginx, который > был собран с опцией --with-debug ? Ну кроме небольшого увеличения размера > самого бинарника. Или пока мы нигде в error_log не указываем debug, то > никаких "проседаний" по производительности и не будет? > > Например в вашем официальном docker образе идет два отдельных бинарника - > nginx и nginx-debug. > Несущественные, но есть. -- Валентин Бартенев From vbart на nginx.com Mon Dec 11 11:05:18 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Mon, 11 Dec 2017 14:05:18 +0300 Subject: =?UTF-8?B?UmU6INCn0YLQviDQtNC10LvQsNC10YIgbmdpbng=?= In-Reply-To: References: <1902722.W2MOYlMe0u@vbart-laptop> Message-ID: <1717483.im5cy8eRBH@vbart-laptop> On Sunday, 10 December 2017 18:56:31 MSK IvanMiller wrote: > Gzip off стоит, включение оного на производительность никак не влияет. вот и > конфиг. > [..] Конфигурация явно неполная. Основной потребитель ресурсов может быть включен и на уровне отдельно взятого блока location. Полная получается при запуске nginx с ключем -T. Кроме gzip, TLS может кушать ресурсы, а также модуль PageSpeed за этим замечен. -- Валентин Бартенев From nginx-forum на forum.nginx.org Tue Dec 12 05:59:31 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 00:59:31 -0500 Subject: 480*272 Resolution LCD Display brands Message-ID: <65a787f5187f1e5507b094f7050ec53c.NginxMailingListRussian@forum.nginx.org> Our products have almost been covered in our domestic market,they are also very hot sale in overseas markes like North American,Western Europe,Southern Europe,Northern Europe,Mid East,South Asia,Eastern Europe,Eastern Asia,South America,Central America,Southeast Asia,Africa,Oceania and so on. 8.Our Service: We supply 1 year warranty for all of our products from the date of shipment. Our products are free of functional defects and missing parts within 30 days from the date of shipment. a)For original brand LCD module;we will replace new products of functional defect products for our clients. b)For our CRD LCD module;we will replace the product with a new or refurbished product. "Refurbished"means a component that has been returned to its original specifications. If the products cannot be repaired,we will send the agreed quantity of new products free of charge with the next delivery to compensate for the loss. We do not give refunds or credit memos. 9.Packing & Shipping480*272 Resolution LCD Display brands website:http://www.wholesale-lcd-display.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277737,277737#msg-277737 From nginx-forum на forum.nginx.org Tue Dec 12 05:59:59 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 00:59:59 -0500 Subject: USB Travel Charger brands Message-ID: FAQ: Q: As for terms of payment, do we accept paypal or Escrow ? Yes, we accept paypal or Escrow for samples, but when order value up to 1500 USD, we accept T/T. Q: Is the quality guaranteed? How does SCGK do QC? A: all products are 100% tested before shipment., and the production line is always strictly controlled by our QC staff members.Welcome to our factory and it would be a honor for us to have you here to share everything with you, like our product showcase, our dust-free plant, and our machines etc. Q: Is it safe to deal with SCGK? A: Of course, SCGK has been a verified gold supplier of Alibaba, we has exported thousands of products to all over the world with rich exporting experience.we attend the Hong Kong Fair every year! Q: Are our products available in a variety of colors and sizes? A: Yes. We supply more than 10000 different models, available in a variety of colors and sizes for mobile phone accessories like car charger, wall charger, power bank, and cables. You can advise the size or color you need, all of our products could be customized.USB Travel Charger brands website:http://www.wholesaleusbcharger.com/travel-charger/usb-travel-charger/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277738,277738#msg-277738 From nginx-forum на forum.nginx.org Tue Dec 12 06:00:10 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:00:10 -0500 Subject: Android 6.0 Marshmallow Tv Box Made in china Message-ID: <881b00e2b190f4051133b2810bbeeac1.NginxMailingListRussian@forum.nginx.org> Our service Wihome Technology Commitment: 1. Manufacture high quality product 2. Provide excellent price for our customers 3. Provide comprehensive after-sales service 4.1 Year warranty Wihome Technology Have: 1. Experienced R&D team to support OEM/ODM service and after-sale service 2. More than 5 years' experience in manufacturing 3. 100% careful test before shipment OEM: 1. Logo printing on housing(silk screening or gold blocking) 2. Customized package 3. Software Customization: Booting image, UI, APP, Function,etc. ODM: 1. PCBA design 2. Housing design 3. Software CustomizationAndroid 6.0 Marshmallow Tv Box Made in china website:http://www.whtvbox.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277739,277739#msg-277739 From nginx-forum на forum.nginx.org Tue Dec 12 06:00:21 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:00:21 -0500 Subject: China Energy saving LED Lamp suppliers Message-ID: <7f309cbf62d115e2282e491472d06907.NginxMailingListRussian@forum.nginx.org> E27 E14 B22 Energy saving LED lighting New unique design 3W-25W B22 E14 E27 CE UL Energy Saving LED Lighting Efficient lighting, replace compact fluorescent bulb 75% energy saving compared with fluorescent tube Less replacement to save maintenance cost Standard IEC size, Standard lamp holder, compatible with electronic transformer Aluminum die-casting housing wrapped by thermal plastic and plastic cover · Model NO.: Energy Saving Light · Lamp Holder/Base: B22/E27/E14/E40 ·Tube Diameter: 9/12/14.5/17mm ·Plastic Material: PP/PC/PBT ·Lamp Holder Material: Nickel-plating ·Voltage: 110V/220V/240V ·Dimmable: Parts/Cap/Accessories/Plant/Base/Cup ·PCB: Capacitor/Component/Fixture/Flower/Global ·Glass: Lava/U Shape/Pi/8u/Machine/Equipment ·Accessories: Fluorescent/Corn/Grow/Outdoor/High Bay/Indoor ·Holder: PCB/Plug/Series/SKD/Bangladesh/GU10 11W 2700k ·Transport Package: Exportable Cartons ·HS Code: 8539319100 ·Shape: 2u/3u/4u/Full Spiral/Half Spiral ·Lamp Type: T2/T3/T4/T5/T8 ·Color Temperature: Nature/Cool/Warm White (2700k-6400k) ·Lamp Body Material: Plastic ·Certification: CE, RoHS, CCC, ISO9001, UL, SGS ·Parts: Dimmable/Ballast/Assembly Line/SupplierChina Energy saving LED Lamp suppliers website:http://www.wh-wirebinding.com/saving-lighting/energy-saving-lamp/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277740,277740#msg-277740 From nginx-forum на forum.nginx.org Tue Dec 12 06:00:40 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:00:40 -0500 Subject: cheap Countertop gas pizza oven Message-ID: E27 E14 B22 Energy saving LED lighting New unique design 3W-25W B22 E14 E27 CE UL Energy Saving LED Lighting Efficient lighting, replace compact fluorescent bulb 75% energy saving compared with fluorescent tube Less replacement to save maintenance cost Standard IEC size, Standard lamp holder,Our History Established in 1986, Guangzhou Junjian Kitchen Appliances & Refrigeration Equipment Co., Ltd. is a professional manufacturer and exporter that is concerned with the design, development and production of high-level stainless steel kitchenware, freezers, refrigerators, Salad bars and ice chip machines and different showcases for supermarkets. Our Product Commercial upright freezer,Salad bar refrigerator,Cake showcase series,Cake showcase series, Ice cube making machine, Cold drink freezer,Supermarket showcase, Kitchen appliances, Bakery equipment Product Application Hotel, Restaurant, Our Certificate CCC, CE Our service Our product has one year warranty period. if it is any small problems, we will provide the free spare parts and solution. cheap Countertop gas pizza oven website:http://www.wiberda.com/ compatible with electronic transformer Aluminum die-casting housing wrapped by thermal plastic and plastic cover · Model NO.: Energy Saving Light · Lamp Holder/Base: B22/E27/E14/E40 ·Tube Diameter: 9/12/14.5/17mm ·Plastic Material: PP/PC/PBT ·Lamp Holder Material: Nickel-plating ·Voltage: 110V/220V/240V ·Dimmable: Parts/Cap/Accessories/Plant/Base/Cup ·PCB: Capacitor/Component/Fixture/Flower/Global ·Glass: Lava/U Shape/Pi/8u/Machine/Equipment ·Accessories: Fluorescent/Corn/Grow/Outdoor/High Bay/Indoor ·Holder: PCB/Plug/Series/SKD/Bangladesh/GU10 11W 2700k ·Transport Package: Exportable Cartons ·HS Code: 8539319100 ·Shape: 2u/3u/4u/Full Spiral/Half Spiral ·Lamp Type: T2/T3/T4/T5/T8 ·Color Temperature: Nature/Cool/Warm White (2700k-6400k) ·Lamp Body Material: Plastic ·Certification: CE, RoHS, CCC, ISO9001, UL, SGS ·Parts: Dimmable/Ballast/Assembly Line/SupplierChina Energy saving LED Lamp suppliers website:http://www.wh-wirebinding.com/saving-lighting/energy-saving-lamp/ Our service Wihome Technology Commitment: 1. Manufacture high quality product 2. Provide excellent price for our customers 3. Provide comprehensive after-sales service 4.1 Year warranty Wihome Technology Have: 1. Experienced R&D team to support OEM/ODM service and after-sale service 2. More than 5 years' experience in manufacturing 3. 100% careful test before shipment OEM: 1. Logo printing on housing(silk screening or gold blocking) 2. Customized package 3. Software Customization: Booting image, UI, APP, Function,etc. ODM: 1. PCBA design 2. Housing design 3. Software CustomizationAndroid 6.0 Marshmallow Tv Box Made in china website:http://www.whtvbox.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277741,277741#msg-277741 From nginx-forum на forum.nginx.org Tue Dec 12 06:00:50 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:00:50 -0500 Subject: Solid alcohol fuel quote Message-ID: Canahot (Wuxi) Industrial has been providing the foodservice industry for over ten years.With high efficiency and convenience,and became popular and welcome among both domestic and oversea users. Our passion has always been developing a quality producr-one that is safe,reliable and innovative.Our products always deliver, giving you the peace of mind to focus on what really matters, the food you serve. We have an entire series of related products covering food beverage equipment,guestroom articles,and tableware for Chinese and western food in hotels,bars,etc. The consistent,excellent performance of all our products have enjoyed excellent consumer acceptance while compiling an outstanding reliability record.Solid alcohol fuel quote website:http://www.wickchafingfuel.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277742,277742#msg-277742 From nginx-forum на forum.nginx.org Tue Dec 12 06:01:07 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:01:07 -0500 Subject: Wireless Camera manufacturers Message-ID: <7ab82057867c3c3b0bfbf61c26f2a5ae.NginxMailingListRussian@forum.nginx.org> Product feature · 1280 x 720 Resolution 720P 1.0Megapixel · Supports Wi-Fi, a key WPS function; · Support for mobile video surveillance(iOS, android); · Support cloud service, network penetration, alarm information pushed to phone, etc. · Support Website Interface in IE, cloud ( XMEYE.NET ) in IE, firfox, Safari, Chrome and so on. · Support AP and Router Mode, one key connect WIFI without wired Ethernet in AP mode · Support motion detection alarm, Message Push · Day and Night Vision IR-Cut Product details About us: Product Qualification About Shipping:Wireless Camera manufacturers website:http://www.wifi-smart-devices.com/wireless-camera/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277743,277743#msg-277743 From nginx-forum на forum.nginx.org Tue Dec 12 06:01:20 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:01:20 -0500 Subject: wholesale Agricultural Plastic Message-ID: <9091e0cfdbcdba1b84cc5413c29ff0e7.NginxMailingListRussian@forum.nginx.org> Delivery Details: As your quantity and request: LCL(less than container load) or FCL (full container load) Air Shipping or Express Delivery (DHL, Fedex etc.) is available per requestwholesale Agricultural Plastic website:http://www.wigglewire.com/greenhouse-film/clear-greenhouse-covering-film/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277744,277744#msg-277744 From nginx-forum на forum.nginx.org Tue Dec 12 06:01:40 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:01:40 -0500 Subject: Customized Rising barrier gate Message-ID: <0a33032a744eb1d163c725e1fd093f30.NginxMailingListRussian@forum.nginx.org> Wiicontrol Information Technology Co.,Ltd. is a high-tech enterprises of Parking Management and Revenue Control Systems.It has strong R & D strength in providing the whole hardware product design, sample, production.Wiicontrol aims to change people's lives and provide more convenient products, determined to set up a leading provider for parking control systems. Wiicontrol provides parking lot equipment with expert service for all parking applications. Wiicontrol mainly specializes in entry & exit station, POS station, automated payment station, barrier gate and LPR solution and much more. Customized Rising barrier gate website:http://www.wiiparking.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277745,277745#msg-277745 From nginx-forum на forum.nginx.org Tue Dec 12 06:02:02 2017 From: nginx-forum на forum.nginx.org (ortjnfd0) Date: Tue, 12 Dec 2017 01:02:02 -0500 Subject: Roof & Wall Roll Forming Machine SGS Message-ID: <339dc469eedbc4b7fb74816cf6088001.NginxMailingListRussian@forum.nginx.org> Our Factory Zhejiang Willing International Co., Ltd. was established in March 2011, covers an area of 66,000 square meters, with a total construction area of about 50,000 square meters. It is a listed company in the NEEQ market, with stock code 839623. Our company engaged in top quality building materials equipment design , product and sale in a long-term, our product development along the Internet +, machine replacement, high-speed and other aspects of rapid development. The main business scope covers following items: 1)New construction industry prefabricated equipment unit 2)Intelligent molding equipment 3)Steel cold roll forming production line 4)Customized mechanical and electrical integration equipment 5)High-speed rolling equipment 6)Steel bar truss welding production line 7)Steel mesh forming units Especially our high speed rolling equipment, double steel truss welded molding production line and steel mesh forming units are successful to fill the gaps at home and abroad. During the past two years, our company has increased to the top quality photovoltaic stent production line and prefabricated building equipment investment, we get a widely recognition after adhere to the production series line, great customization line, and providing quality products while pay more attention to customer experience, advocate after-sales service quality and remote technology security. After several years of efforts, we increased the human resource and financial investment, our business performance achieved a rapid growth. We passed CE product certificate, ISO 9001:2008 certificate and SGS certificate, AAA credit enterprises and other honors, we also passed the global quality manufacturers GMC system certification, and SONCAP system certification. Our company also introduced the ERP management system, quality and effective control makes our factory to be a standard enterprise from raw materials to the products. Our products are exported to Europe, the United States, the Middle East, Africa, Southeast Asia, South America etc. more than 60 countries and regions, we established a long-term business realations with more than 400 customers in the world, our products and services are widely praised by customers.Roof & Wall Roll Forming Machine SGS website:http://www.willingtec.net/ website2:http://www.forming-machine.net/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277746,277746#msg-277746 From nginx-forum на forum.nginx.org Tue Dec 12 08:32:46 2017 From: nginx-forum на forum.nginx.org (Set) Date: Tue, 12 Dec 2017 03:32:46 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: <20171206152320.GL78325@mdounin.ru> References: <20171206152320.GL78325@mdounin.ru> Message-ID: Спасибо за развернутый ответ. Но всё-таки у меня не получается изменить стандартную страницу. Пробовал вставлять в сервер по умолчанию и в секцию http (nginx.conf) страница 400 Bad Request не меняется. Можете привести пример в какую секцию необходимо добавить error_page 400 /400.html; location = /400.html { root /usr/share/nginx/html; } Как тест сделал страницу /usr/share/nginx/html./400.html Error: 400 Bad Request

Error: 400 Bad Request

Test page.

Подскажите, пожалуйста, что не так сделано? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277747#msg-277747 From nginx-forum на forum.nginx.org Tue Dec 12 08:38:37 2017 From: nginx-forum на forum.nginx.org (Set) Date: Tue, 12 Dec 2017 03:38:37 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: <20171206152320.GL78325@mdounin.ru> Message-ID: nginx version: nginx/1.8.0 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277748#msg-277748 From andrey на kopeyko.ru Tue Dec 12 08:47:56 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 12 Dec 2017 11:47:56 +0300 (MSK) Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: <20171206152320.GL78325@mdounin.ru> Message-ID: On Tue, 12 Dec 2017, Set wrote: > Спасибо за развернутый ответ. Но всё-таки у меня не получается изменить > стандартную страницу. > > Пробовал вставлять в сервер по умолчанию и в секцию http (nginx.conf) > страница 400 Bad Request не меняется. Ровно в этом месте - нужно читать логи. Там будет написано, что таки у вас происходит. > Как тест сделал страницу /usr/share/nginx/html./400.html Вот эта точка в пути - это опечатка, или вы и в самом деле создали каталог "html."? -- Best regards, Andrey Kopeyko From nginx-forum на forum.nginx.org Tue Dec 12 08:58:02 2017 From: nginx-forum на forum.nginx.org (Set) Date: Tue, 12 Dec 2017 03:58:02 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: Message-ID: <4ef9371d8c6c59ad3a7d0814e5d3eff6.NginxMailingListRussian@forum.nginx.org> Andrey Kopeyko Wrote: ------------------------------------------------------- > On Tue, 12 Dec 2017, Set wrote: > > > Спасибо за развернутый ответ. Но всё-таки у меня не получается > изменить > > стандартную страницу. > > > > Пробовал вставлять в сервер по умолчанию и в секцию http > (nginx.conf) > > страница 400 Bad Request не меняется. > > Ровно в этом месте - нужно читать логи. Там будет написано, что таки у > вас > происходит. В access логах: 127.0.0.1 - [12/Dec/2017:11:24:25 +0300] "GET / HTTP/1.1" 400 644 "http://localhost" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/ Safari/537.36" "-" > > > Как тест сделал страницу /usr/share/nginx/html./400.html > > Вот эта точка в пути - это опечатка, или вы и в самом деле создали > каталог > "html."? Ссори опечатка. Сама страница из браузера доступна. > -- > Best regards, > Andrey Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277750#msg-277750 From andrey на kopeyko.ru Tue Dec 12 09:12:47 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 12 Dec 2017 12:12:47 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: <4ef9371d8c6c59ad3a7d0814e5d3eff6.NginxMailingListRussian@forum.nginx.org> References: <4ef9371d8c6c59ad3a7d0814e5d3eff6.NginxMailingListRussian@forum.nginx.org> Message-ID: Set писал 2017-12-12 11:58: > > В access логах: > 127.0.0.1 - [12/Dec/2017:11:24:25 +0300] "GET / HTTP/1.1" 400 644 > "http://localhost" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/ Safari/537.36" "-" > > Ссори опечатка. Сама страница из браузера доступна. Если из браузера видна ровно та страница ошибки, которую вы заменили, - разве это не есть решение вашей проблемы? P.S. Мне тут интересно другое - как вы _браузером_ ухитрились невалидный запрос сделать? Вероятнее всего, запрос вы делаете скриптом, задавая похожий на истину заголовок "User-Agent". -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Tue Dec 12 10:07:25 2017 From: nginx-forum на forum.nginx.org (Set) Date: Tue, 12 Dec 2017 05:07:25 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: Message-ID: <489ca521bf942a479e79a6c6be0ff901.NginxMailingListRussian@forum.nginx.org> Andrey Kopeyko Wrote: ------------------------------------------------------- > Set писал 2017-12-12 11:58: > > > > В access логах: > > 127.0.0.1 - [12/Dec/2017:11:24:25 +0300] "GET / HTTP/1.1" 400 644 > > "http://localhost" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.36 > > (KHTML, like Gecko) Chrome/ Safari/537.36" "-" > > > > Ссори опечатка. Сама страница из браузера доступна. > > Если из браузера видна ровно та страница ошибки, которую вы заменили, > - > разве это не есть решение вашей проблемы? Страница из браузера видна. Но при наступлении ошибки. Отдается, почему то стандартная страница 400 Bad Request. Должна отдаваться страница которую я заменил. > > P.S. > Мне тут интересно другое - как вы _браузером_ ухитрились невалидный > запрос сделать? > Вероятнее всего, запрос вы делаете скриптом, задавая похожий на истину > > заголовок "User-Agent". > Да, запрос делаю скриптом. > > -- > Best regards, > Andrey A. Kopeyko > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277752#msg-277752 From andrey на kopeyko.ru Tue Dec 12 10:24:39 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 12 Dec 2017 13:24:39 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: <489ca521bf942a479e79a6c6be0ff901.NginxMailingListRussian@forum.nginx.org> References: <489ca521bf942a479e79a6c6be0ff901.NginxMailingListRussian@forum.nginx.org> Message-ID: Set писал 2017-12-12 13:07: > > Страница из браузера видна. Но при наступлении ошибки. Отдается, почему > то > стандартная страница 400 Bad Request. Должна отдаваться страница > которую я > заменил. 1. Включите настоящий debug log -- недостаточно задать уровень "debug" в директиве "debug_log", нужно запускать собранный с поддержкой отладки бинарник - http://nginx.org/ru/docs/debugging_log.html -- задайте директиву debug_connection для отсечения лишнего шума в логе 2. Добейтесь наступления ошибки 3. Читайте в логе как именно шла обработка ошибочного запроса; из лога будет понятен контекст, в котором произошла ошибка. 4. Подправьте конфиг. 5. Повторяйте пункты 2-4 6. Выключите debug log P.S. Если нужна помощь - обращайтесь в почту. -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Tue Dec 12 12:58:37 2017 From: nginx-forum на forum.nginx.org (Set) Date: Tue, 12 Dec 2017 07:58:37 -0500 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: Message-ID: 2. Ошибка вызвана большим размером заголовка Cookie (Request Header Or Cookie Too Large). Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277648,277755#msg-277755 From andrey на kopeyko.ru Tue Dec 12 13:43:26 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Tue, 12 Dec 2017 16:43:26 +0300 Subject: =?UTF-8?B?UmU6INCY0LfQvNC10L3QuNGC0Ywg0YHRgtCw0L3QtNCw0YDRgtC90YPRjiDRgdGC?= =?UTF-8?B?0YDQsNC90LjRhtGDIDQwMCBCYWQgUmVxdWVzdA==?= In-Reply-To: References: Message-ID: Set писал 2017-12-12 15:58: > 2. Ошибка вызвана большим размером заголовка Cookie (Request Header Or > Cookie Too Large). В этом случае вам надо увеличивать размер буфера (начните с удвоения его) директивы "large_client_header_buffers" http://nginx.org/ru/docs/http/ngx_http_core_module.html#large_client_header_buffers -- Best regards, Andrey A. Kopeyko From alex.nikolaev.1900 на gmail.com Wed Dec 13 08:15:58 2017 From: alex.nikolaev.1900 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCd0LjQutC+0LvQsNC10LI=?=) Date: Wed, 13 Dec 2017 11:15:58 +0300 Subject: =?UTF-8?B?0J7QsdGK0ZHQvCDQvtGC0LTQsNC90L3QvtCz0L4g0LfQsNC/0YDQvtGB0LAg0YEg?= =?UTF-8?B?0YPRh9GR0YLQvtC8IFNTTC0gb3ZlcmhlYWQn0LA=?= Message-ID: Добрый день. Есть задача - сохранять в лог-файл полный объём ответа на запросы, как минимум с учётом затрат на SSL при HTTPS. $*bytes_sent* - содержит число байт, переданное клиенту, по HTTP (т.е. тело+заголовки), но не учитывает расходы трафик на транспорт (SSL, TCP/IP) При этом SSL обрабатывается самим nginx'ом и он вполне может иметь информацию по объёму переданной информации с учётом SSL overhead'а для логирования. Есть идеи (или может быть даже реализации), как получить желаемый результат с nginx'ом? -- С уважением, А.Н. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From andrey на kopeyko.ru Wed Dec 13 11:25:43 2017 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Wed, 13 Dec 2017 14:25:43 +0300 Subject: =?UTF-8?B?UmU6INCe0LHRitGR0Lwg0L7RgtC00LDQvdC90L7Qs9C+INC30LDQv9GA0L7RgdCw?= =?UTF-8?B?INGBINGD0YfRkdGC0L7QvCBTU0wtIG92ZXJoZWFkJ9Cw?= In-Reply-To: References: Message-ID: Александр Николаев писал 2017-12-13 11:15: > Добрый день. Добрый день, Александр! > Есть задача - сохранять в лог-файл > полный объём ответа на запросы, Тут дело такое: до того момента как полностью установится TLS-соединение - никакого запроса ещё нет. Т.е. измерять пока нечего, и в этом смысле - nginx действует правильно. > как минимум с учётом затрат на SSL при HTTPS. > > $_bytes_sent__ _ - содержит число байт, > переданное клиенту, по HTTP (т.е. > тело+заголовки), но не учитывает > расходы трафик на транспорт (SSL, TCP/IP) Значит, на транспортном уровне и надо мерять. Например, считать объём минутного TCP-трафика на порту и вычитать из него сумму значений $bytes_sent за ту же минуту. Правда, в этом случае вы потеряете разблюдовку по IP-адресам и по клиентам. > как получить желаемый результат с nginx'ом? Расскажите, пожалуста, по-подробнее - а для чего такая инфа нужна\полезна? может, эту вашу задачу окажется возможным решить каким-то другим способом? -- Best regards, Andrey A. Kopeyko From alex.nikolaev.1900 на gmail.com Wed Dec 13 12:09:51 2017 From: alex.nikolaev.1900 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCd0LjQutC+0LvQsNC10LI=?=) Date: Wed, 13 Dec 2017 15:09:51 +0300 Subject: =?UTF-8?B?UmU6INCe0LHRitGR0Lwg0L7RgtC00LDQvdC90L7Qs9C+INC30LDQv9GA0L7RgdCw?= =?UTF-8?B?INGBINGD0YfRkdGC0L7QvCBTU0wtIG92ZXJoZWFkJ9Cw?= In-Reply-To: References: Message-ID: > Есть задача - сохранять в лог-файл >> полный объём ответа на запросы, >> > > Тут дело такое: до того момента как полностью установится TLS-соединение - > никакого запроса ещё нет. Т.е. измерять пока нечего, и в этом смысле - > nginx действует правильно. > Это очевидно. Можно действовать, например, как mod_logio для apache с %O - добавлять хендшейк к размеру первого ответа. > > как минимум с учётом затрат на SSL при HTTPS. >> >> $_bytes_sent__ _ - содержит число байт, >> переданное клиенту, по HTTP (т.е. >> тело+заголовки), но не учитывает >> расходы трафик на транспорт (SSL, TCP/IP) >> > > Значит, на транспортном уровне и надо мерять. > Например, считать объём минутного TCP-трафика на порту и вычитать из него > сумму значений $bytes_sent за ту же минуту. > > Правда, в этом случае вы потеряете разблюдовку по IP-адресам и по клиентам. > > > как получить желаемый результат с nginx'ом? >> > > Расскажите, пожалуста, по-подробнее - а для чего такая инфа нужна\полезна? > может, эту вашу задачу окажется возможным решить каким-то другим способом? > Необходимо определять объём исходящего трафика в разрезе по server'ам и IP-адресам посетителей в name-based-схеме, когда много server'ов слушают одну пару IP:port. В идеале - с учётом всего overhead'а, но достаточно хотя бы учесть SSL. И хотелось бы эти цифры видеть в логе nginx'а для дальнейшей аналитики в любых других разрезах. -- С уважением, А.Н. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Wed Dec 13 12:58:56 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 13 Dec 2017 15:58:56 +0300 Subject: =?UTF-8?B?UmU6INCe0LHRitGR0Lwg0L7RgtC00LDQvdC90L7Qs9C+INC30LDQv9GA0L7RgdCw?= =?UTF-8?B?INGBINGD0YfRkdGC0L7QvCBTU0wtIG92ZXJoZWFkJ9Cw?= In-Reply-To: References: Message-ID: <20171213125856.GC78325@mdounin.ru> Hello! On Wed, Dec 13, 2017 at 11:15:58AM +0300, Александр Николаев wrote: > Добрый день. > > Есть задача - сохранять в лог-файл полный объём ответа на запросы, как > минимум с учётом затрат на SSL при HTTPS. > > $*bytes_sent* - содержит число байт, переданное клиенту, по HTTP (т.е. > тело+заголовки), но не учитывает расходы трафик на транспорт (SSL, TCP/IP) > > При этом SSL обрабатывается самим nginx'ом и он вполне может иметь > информацию по объёму переданной информации с учётом SSL overhead'а для > логирования. Есть идеи (или может быть даже реализации), как получить > желаемый результат с nginx'ом? Для работы с SSL nginx использует встроенные в OpenSSL возможности, и не пытается перехватывать работу с файловым дескриптором - а, наоборот, отдаёт дескриптор OpenSSL'ю с помощью функции SSL_set_fd(). Соответственно, информации о том, сколько байт было записано в SSL-соединение - у nginx'а нет. Теоретически - такие счётчики есть внутри OpenSSL, нужно добраться до write BIO на сокете (SSL_get_wbio(), BIO_next()) и попросить BIO_number_written(). И это наверное даже можно без особых проблем сделать в модуле, если вам зачем-то нужна такая функциональность. Отмечу на всякий случай, что там будут нюансы, связанные с тем, что извлечь эту инфмормацию можно только в рамках запроса (скажем, логгируя добавленную модулем переменную), соответственно a) данные для каждого следующего запроса в том же соединении будут включать в себя данные для предыдущих запросов, и б) shutdown не попадает вообще никуда. -- Maxim Dounin http://mdounin.ru/ From slw на zxy.spb.ru Wed Dec 13 13:44:51 2017 From: slw на zxy.spb.ru (Slawa Olhovchenkov) Date: Wed, 13 Dec 2017 16:44:51 +0300 Subject: =?UTF-8?B?UmU6INCe0LHRitGR0Lwg0L7RgtC00LDQvdC90L7Qs9C+INC30LDQv9GA0L7RgdCw?= =?UTF-8?B?INGBINGD0YfRkdGC0L7QvCBTU0wtIG92ZXJoZWFkJ9Cw?= In-Reply-To: References: Message-ID: <20171213134451.GF19373@zxy.spb.ru> On Wed, Dec 13, 2017 at 03:09:51PM +0300, Александр Николаев wrote: > > как минимум с учётом затрат на SSL при HTTPS. > >> > >> $_bytes_sent__ _ - содержит число байт, > >> переданное клиенту, по HTTP (т.е. > >> тело+заголовки), но не учитывает > >> расходы трафик на транспорт (SSL, TCP/IP) > >> > > > > Значит, на транспортном уровне и надо мерять. > > Например, считать объём минутного TCP-трафика на порту и вычитать из него > > сумму значений $bytes_sent за ту же минуту. > > > > Правда, в этом случае вы потеряете разблюдовку по IP-адресам и по клиентам. > > > > > > как получить желаемый результат с nginx'ом? > >> > > > > Расскажите, пожалуста, по-подробнее - а для чего такая инфа нужна\полезна? > > может, эту вашу задачу окажется возможным решить каким-то другим способом? > > > > Необходимо определять объём исходящего трафика в разрезе по server'ам и > IP-адресам посетителей в name-based-схеме, когда много server'ов слушают > одну пару IP:port. > В идеале - с учётом всего overhead'а, но достаточно хотя бы учесть SSL. И > хотелось бы эти цифры видеть в логе nginx'а для дальнейшей аналитики в > любых других разрезах. объем ssl оверхеда на хоть сколько-нибудь крупных запросах (больше 130К) существенно меньше tcp/ip оверхеда и почти весь содержится в начале сессии https://stackoverflow.com/questions/1615882/how-much-network-overhead-does-tls-add-compared-to-a-non-encrypted-connection From nginx-forum на forum.nginx.org Fri Dec 15 14:47:28 2017 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Fri, 15 Dec 2017 09:47:28 -0500 Subject: =?UTF-8?B?0JrQsNC6INC30LDRgdGC0LDQstC40YLRjCBOZ2lueCDQvtGC0LTQsNCy0LDRgtGM?= =?UTF-8?B?IGVycm9yIDUyMT8=?= Message-ID: Есть Nginx-frontend, он может вернуть Error 502 "Bad Gateway", если backend недоступен. Есть Nginx-backend, он тоже может вернуть Error 502. Как научить Nginx-frontend возвращать в случае недоступности backend'a не 502, а 523 "Origin is unreachable"? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277785,277785#msg-277785 From nginx на kinetiksoft.com Fri Dec 15 14:57:42 2017 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Fri, 15 Dec 2017 17:57:42 +0300 Subject: unit-0.2 beta release In-Reply-To: <66C363C0-1EB1-40FA-8034-4B3EA116CB10@sysoev.ru> References: <14ac255a-671e-99d3-088d-9cbe3a760231@bestmx.net> <66C363C0-1EB1-40FA-8034-4B3EA116CB10@sysoev.ru> Message-ID: <3558225.tfEROiBb7k@cybernote> Здравствуйте! В письме от пятница, 20 октября 2017 г. 22:58:00 MSK пользователь Igor Sysoev написал: > > С точки зрения юнита, языки делятся на две категории: > 1) встраивание языка в юнит: PHP, Python, Ruby, Perl - эти языки имеют > некий стандартный интерфейс для встраивания в веб-сервер; > 2) встраивание модуля юнита в приложение: Go, Node.js, Java. > > Первое сделать, как правило, проще. Но перл не в ближних планах, поскольку > его популярность падает. > А интеграция ruby в ближних планах есть? С уважением, Иван. From vbart на nginx.com Fri Dec 15 17:37:37 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 15 Dec 2017 20:37:37 +0300 Subject: unit-0.2 beta release In-Reply-To: <3558225.tfEROiBb7k@cybernote> References: <66C363C0-1EB1-40FA-8034-4B3EA116CB10@sysoev.ru> <3558225.tfEROiBb7k@cybernote> Message-ID: <2108226.dkjV3HtrdS@vbart-workstation> On Friday 15 December 2017 17:57:42 Иван wrote: [..] > > А интеграция ruby в ближних планах есть? > В первом квартале 2018 планируем сделать Ruby и Perl. -- Валентин Бартенев From nginx на kinetiksoft.com Fri Dec 15 18:53:57 2017 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Fri, 15 Dec 2017 21:53:57 +0300 Subject: unit-0.2 beta release In-Reply-To: <2108226.dkjV3HtrdS@vbart-workstation> References: <3558225.tfEROiBb7k@cybernote> <2108226.dkjV3HtrdS@vbart-workstation> Message-ID: <1963541.sZcXvGPr6j@cybernote> Прекрасная новость! А пакеты для debian9? А когда планируется релиз? В письме от пятница, 15 декабря 2017 г. 20:37:37 MSK пользователь Валентин Бартенев написал: > On Friday 15 December 2017 17:57:42 Иван wrote: > [..] > > > А интеграция ruby в ближних планах есть? > > В первом квартале 2018 планируем сделать Ruby и Perl. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vladget на gmail.com Fri Dec 15 20:15:47 2017 From: vladget на gmail.com (Vladimir Getmanshchuk) Date: Fri, 15 Dec 2017 22:15:47 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0YHRgtCw0LLQuNGC0YwgTmdpbngg0L7RgtC00LDQstCw?= =?UTF-8?B?0YLRjCBlcnJvciA1MjE/?= In-Reply-To: References: Message-ID: так 523 или 521? я бы сделал location @return52x { return 521; } а потом как то туда передавать управления.. не знаю как.. 2017-12-15 16:47 GMT+02:00 Ilya Evseev : > Есть Nginx-frontend, он может вернуть Error 502 "Bad Gateway", если backend > недоступен. > Есть Nginx-backend, он тоже может вернуть Error 502. > > Как научить Nginx-frontend возвращать в случае недоступности backend'a не > 502, а 523 "Origin is unreachable"? > > Posted at Nginx Forum: https://forum.nginx.org/read. > php?21,277785,277785#msg-277785 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Yours sincerely, Vladimir Getmanshchuk ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-ru на sadok.spb.ru Fri Dec 15 20:33:05 2017 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Fri, 15 Dec 2017 23:33:05 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0YHRgtCw0LLQuNGC0YwgTmdpbngg0L7RgtC00LDQstCw?= =?UTF-8?B?0YLRjCBlcnJvciA1MjE/?= In-Reply-To: References: Message-ID: <17710133467.20171215233305@sadok.spb.ru> Здравствуйте, Ilya. Вы писали 15 декабря 2017 г., 17:47:28: > Как научить Nginx-frontend возвращать в случае недоступности backend'a не > 502, а 523 "Origin is unreachable"? Договориться и занести его в правильный RFC? Пусть Cloudflare потренируется -- С уважением, Dmitry nginx-ru на sadok.spb.ru From igor.bliss на gmail.com Fri Dec 15 21:10:41 2017 From: igor.bliss на gmail.com (Igor Savenko) Date: Fri, 15 Dec 2017 23:10:41 +0200 Subject: =?UTF-8?B?0JrQsNC6INCy0YvQt9Cy0LDRgtGMINGE0YPQvdC60YbQuNGOINC80L7QtNGD0Ls=?= =?UTF-8?B?0Y8g0LjQtyDQtNGA0YPQs9C+0LPQviDQvNC+0LTRg9C70Y8/?= Message-ID: Допустим, есть самописный модуль X, который может писать в юникс-сокет. Есть другой модуль Y, которому нужно помочь в лог-фазе сбрасывать информацию в наш сокет. Как из лог-хендлера второго модуля вызвать условную функцию send_to_our_socket первого модуля? Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From fe на hamilton.rinet.ru Sat Dec 16 09:50:15 2017 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Sat, 16 Dec 2017 12:50:15 +0300 Subject: =?UTF-8?B?aHR0cHMgdXBzdHJlYW0gc2VydmVyINC4INC70L7QutCw0LvRjNC90YvQuSBiYWNr?= =?UTF-8?B?dXAgaHR0cCB1cHN0cmVhbQ==?= Message-ID: Привет! Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока совсем беда :-( Формулировка, правда, изначально довольно извращенная: есть Nginx, по-умолчанию проксирует запрос в локально работающую node. Но если в запросе есть заголовок X-Some-Header, то запрос нужно спроксировать на другой сервер по https. Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то сделать fallback опять на локальную node. первая мысль была: map $http_x_some_header $use_backend { "" http://localhost:7070; default https://remote_upstream; } upstream remote_upstream { server remote:443; server localhost:7070 backup; } но локальный сервер не https, и все не очень красиво :-( думал тут еще поднять на этом же nginx локальный https на порту 7073, проксировать в него как backup, но тут начинаются сложности с сертификатами. Опять же думал о другом варианте: proxy_pass $use_backend; error_page 500 502 504 = @fallback_local_node; location @fallback_local_node { internal; proxy_pass http://localhost:7070; } но тут получается что если заголовка не было, node ответил 502, то мы пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво получается... Может кто подскажет тут красивое решение? Ну и как feature request: может можно добавить к опции backup для директивы server в upstream еще какой-нибудь параметр backup_proto=http или другую опцию backup_http, чтобы при переключении на backup сервер менялся и протокол обращения. -- Fedor Dikarev From arozyev на nginx.com Sat Dec 16 12:21:43 2017 From: arozyev на nginx.com (Aziz Rozyev) Date: Sat, 16 Dec 2017 15:21:43 +0300 Subject: =?UTF-8?B?UmU6IGh0dHBzIHVwc3RyZWFtIHNlcnZlciDQuCDQu9C+0LrQsNC70YzQvdGL0Lkg?= =?UTF-8?B?YmFja3VwIGh0dHAgdXBzdHJlYW0=?= In-Reply-To: References: Message-ID: <6722BA8B-F586-43B7-973B-BE5907574B02@nginx.com> а вариант с 2 апстримами не подходит? upstream remote_up { remote_upstream:443; } upstream local_up { localhost:7070; } map $http_x_some_header $remote { “” 0; “default” 1; } if ($remote) { proxy_pass https://remote; } proxy_pass http://local; br, Aziz. > On 16 Dec 2017, at 12:50, Fedor Dikarev wrote: > > Привет! > > Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока > совсем беда :-( > > Формулировка, правда, изначально довольно извращенная: > есть Nginx, по-умолчанию проксирует запрос в локально работающую node. > Но если в запросе есть заголовок X-Some-Header, то запрос > нужно спроксировать на другой сервер по https. > Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то > сделать fallback опять на локальную node. > > первая мысль была: > map $http_x_some_header $use_backend { > "" http://localhost:7070; > default https://remote_upstream; > } > upstream remote_upstream { > server remote:443; > server localhost:7070 backup; > } > > но локальный сервер не https, и все не очень красиво :-( > думал тут еще поднять на этом же nginx локальный https на порту 7073, > проксировать в него как backup, но тут начинаются сложности с > сертификатами. > > Опять же думал о другом варианте: > proxy_pass $use_backend; > error_page 500 502 504 = @fallback_local_node; > > location @fallback_local_node { > internal; > proxy_pass http://localhost:7070; > } > > но тут получается что если заголовка не было, node ответил 502, то мы > пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво > получается... > > Может кто подскажет тут красивое решение? > > Ну и как feature request: может можно добавить к опции backup для > директивы server в upstream еще какой-нибудь параметр backup_proto=http > или другую опцию backup_http, чтобы при переключении на backup сервер > менялся и протокол обращения. > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From vbart на nginx.com Sat Dec 16 13:05:22 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 16 Dec 2017 16:05:22 +0300 Subject: unit-0.2 beta release In-Reply-To: <1963541.sZcXvGPr6j@cybernote> References: <2108226.dkjV3HtrdS@vbart-workstation> <1963541.sZcXvGPr6j@cybernote> Message-ID: <3168245.Kz2peocWcp@vbart-laptop> On Friday, 15 December 2017 21:53:57 MSK Иван wrote: > Прекрасная новость! > > А пакеты для debian9? А когда планируется релиз? > [..] Пакеты для Debian надеюсь сделаем до конца года. Релиз запланирован на второй квартал 2018. -- Валентин Бартенев From fe на hamilton.rinet.ru Sat Dec 16 16:28:10 2017 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Sat, 16 Dec 2017 19:28:10 +0300 Subject: =?UTF-8?B?UmU6IGh0dHBzIHVwc3RyZWFtIHNlcnZlciDQuCDQu9C+0LrQsNC70YzQvdGL0Lkg?= =?UTF-8?B?YmFja3VwIGh0dHAgdXBzdHJlYW0=?= In-Reply-To: <6722BA8B-F586-43B7-973B-BE5907574B02@nginx.com> References: <6722BA8B-F586-43B7-973B-BE5907574B02@nginx.com> Message-ID: Попробовал этот вариант, и без error_page он не переключается на local. Но если вписать error_page внутрь if-а, то вроде как работает как нужно. Осталось убедить самого себя, что без if-а тут не обойтись. Хотя и очень хочется. 16.12.17 15:21, Aziz Rozyev пишет: > а вариант с 2 апстримами не подходит? > > upstream remote_up { > remote_upstream:443; > } > > upstream local_up { > localhost:7070; > } > > map $http_x_some_header $remote { > “” 0; > “default” 1; > } > > if ($remote) { > proxy_pass https://remote; > } > proxy_pass http://local; > > > br, > Aziz. > > > > > >> On 16 Dec 2017, at 12:50, Fedor Dikarev wrote: >> >> Привет! >> >> Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока >> совсем беда :-( >> >> Формулировка, правда, изначально довольно извращенная: >> есть Nginx, по-умолчанию проксирует запрос в локально работающую node. >> Но если в запросе есть заголовок X-Some-Header, то запрос >> нужно спроксировать на другой сервер по https. >> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то >> сделать fallback опять на локальную node. >> >> первая мысль была: >> map $http_x_some_header $use_backend { >> "" http://localhost:7070; >> default https://remote_upstream; >> } >> upstream remote_upstream { >> server remote:443; >> server localhost:7070 backup; >> } >> >> но локальный сервер не https, и все не очень красиво :-( >> думал тут еще поднять на этом же nginx локальный https на порту 7073, >> проксировать в него как backup, но тут начинаются сложности с >> сертификатами. >> >> Опять же думал о другом варианте: >> proxy_pass $use_backend; >> error_page 500 502 504 = @fallback_local_node; >> >> location @fallback_local_node { >> internal; >> proxy_pass http://localhost:7070; >> } >> >> но тут получается что если заголовка не было, node ответил 502, то мы >> пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво >> получается... >> >> Может кто подскажет тут красивое решение? >> >> Ну и как feature request: может можно добавить к опции backup для >> директивы server в upstream еще какой-нибудь параметр backup_proto=http >> или другую опцию backup_http, чтобы при переключении на backup сервер >> менялся и протокол обращения. >> -- >> Fedor Dikarev >> _______________________________________________ >> 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 > -- Fedor Dikarev From arozyev на nginx.com Sat Dec 16 19:52:04 2017 From: arozyev на nginx.com (Aziz Rozyev) Date: Sat, 16 Dec 2017 22:52:04 +0300 Subject: =?UTF-8?B?UmU6IGh0dHBzIHVwc3RyZWFtIHNlcnZlciDQuCDQu9C+0LrQsNC70YzQvdGL0Lkg?= =?UTF-8?B?YmFja3VwIGh0dHAgdXBzdHJlYW0=?= In-Reply-To: References: <6722BA8B-F586-43B7-973B-BE5907574B02@nginx.com> Message-ID: <2193CF18-D057-4605-ADC6-B2654F33591D@nginx.com> может я, конечно, не уловил сути задачи, но и без error_page переключается: 39 map $http_x_myheader $remote { 40 "" 0; 41 "test" 1; 42 } 43 44 upstream remote_up { 45 server nginx.org:443; 46 } 47 48 upstream local_up { 49 server localhost:7070; 50 } 58 server { 59 listen 8085; 60 location / { 62 proxy_set_header Host $host; 63 proxy_set_header Connection ""; 64 proxy_http_version 1.1; 65 66 if ($remote) { 67 proxy_pass https://remote_up; 68 } 69 proxy_pass http://local_up; 70 } 71 } 73 server { 74 listen 7070; 75 return 200 "OK"; 76 } [root на tc ~]# curl http://localhost:8085/ OK [root на tc ~]# curl -H 'X-Myheader: test' http://localhost:8085/ nginx news [ … ] без if-a что-то не придумал, как обойтись. br, Aziz. > On 16 Dec 2017, at 19:28, Fedor Dikarev wrote: > > Попробовал этот вариант, и без error_page он не переключается на local. > Но если вписать error_page внутрь if-а, то вроде как работает как нужно. > Осталось убедить самого себя, что без if-а тут не обойтись. Хотя и очень > хочется. > > 16.12.17 15:21, Aziz Rozyev пишет: >> а вариант с 2 апстримами не подходит? >> >> upstream remote_up { >> remote_upstream:443; >> } >> >> upstream local_up { >> localhost:7070; >> } >> >> map $http_x_some_header $remote { >> “” 0; >> “default” 1; >> } >> >> if ($remote) { >> proxy_pass https://remote; >> } >> proxy_pass http://local; >> >> >> br, >> Aziz. >> >> >> >> >> >>> On 16 Dec 2017, at 12:50, Fedor Dikarev wrote: >>> >>> Привет! >>> >>> Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока >>> совсем беда :-( >>> >>> Формулировка, правда, изначально довольно извращенная: >>> есть Nginx, по-умолчанию проксирует запрос в локально работающую node. >>> Но если в запросе есть заголовок X-Some-Header, то запрос >>> нужно спроксировать на другой сервер по https. >>> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то >>> сделать fallback опять на локальную node. >>> >>> первая мысль была: >>> map $http_x_some_header $use_backend { >>> "" http://localhost:7070; >>> default https://remote_upstream; >>> } >>> upstream remote_upstream { >>> server remote:443; >>> server localhost:7070 backup; >>> } >>> >>> но локальный сервер не https, и все не очень красиво :-( >>> думал тут еще поднять на этом же nginx локальный https на порту 7073, >>> проксировать в него как backup, но тут начинаются сложности с >>> сертификатами. >>> >>> Опять же думал о другом варианте: >>> proxy_pass $use_backend; >>> error_page 500 502 504 = @fallback_local_node; >>> >>> location @fallback_local_node { >>> internal; >>> proxy_pass http://localhost:7070; >>> } >>> >>> но тут получается что если заголовка не было, node ответил 502, то мы >>> пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво >>> получается... >>> >>> Может кто подскажет тут красивое решение? >>> >>> Ну и как feature request: может можно добавить к опции backup для >>> директивы server в upstream еще какой-нибудь параметр backup_proto=http >>> или другую опцию backup_http, чтобы при переключении на backup сервер >>> менялся и протокол обращения. >>> -- >>> Fedor Dikarev >>> _______________________________________________ >>> 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 >> > > -- > Fedor Dikarev > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From fe на hamilton.rinet.ru Sat Dec 16 20:20:37 2017 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Sat, 16 Dec 2017 23:20:37 +0300 Subject: =?UTF-8?B?UmU6IGh0dHBzIHVwc3RyZWFtIHNlcnZlciDQuCDQu9C+0LrQsNC70YzQvdGL0Lkg?= =?UTF-8?B?YmFja3VwIGh0dHAgdXBzdHJlYW0=?= In-Reply-To: <2193CF18-D057-4605-ADC6-B2654F33591D@nginx.com> References: <6722BA8B-F586-43B7-973B-BE5907574B02@nginx.com> <2193CF18-D057-4605-ADC6-B2654F33591D@nginx.com> Message-ID: <4bfbca26-f12a-e6a4-85c5-4712f27d03e9@hamilton.rinet.ru> Суть задачи в том числе и во втором "но": > Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то > сделать fallback опять на локальную node. то есть если у меня есть: > upstream remote { server 127.0.0.1:8081; } > upstream local { server 127.0.0.1:7070; } > server { listen 8081; return 200 remote\n; } > server { listen 7070; return 200 local\n; } то по заголовку я хожу в remote сервер: > curl -fs -H "X-Some-Header: yes" hamilton.rinet.ru/some_header > remote Если же remote 500-тит, или вообще закоментировать его, то чтобы ходил в local: > curl -fs -H "X-Some-Header: yes" hamilton.rinet.ru/some_header > local и да, эта конструкция ведет себя как надо: > location =/some_header { > proxy_intercept_errors on; > if ($remote) { > proxy_pass http://remote; > error_page 500 502 504 = @local; > } > proxy_pass http://local; > } > location @local { > internal; > proxy_pass http://local; > } Но в большой оригинальной задаче и так уже много if-ов, поэтому и хочется получить решение без использования if-а. В идеале: собственно в виде backup_proto=http :) поскольку эта же задача максимально элегантно решалась через > upstream remote { > server remote; > server local backup; > } пока не появилось требование к https у upstream-а 16.12.17 22:52, Aziz Rozyev пишет: > может я, конечно, не уловил сути задачи, но и без error_page переключается: > > 39 map $http_x_myheader $remote { > 40 "" 0; > 41 "test" 1; > 42 } > 43 > 44 upstream remote_up { > 45 server nginx.org:443; > 46 } > 47 > 48 upstream local_up { > 49 server localhost:7070; > 50 } > > 58 server { > 59 listen 8085; > 60 location / { > 62 proxy_set_header Host $host; > 63 proxy_set_header Connection ""; > 64 proxy_http_version 1.1; > 65 > 66 if ($remote) { > 67 proxy_pass https://remote_up; > 68 } > 69 proxy_pass http://local_up; > 70 } > 71 } > > 73 server { > 74 listen 7070; > 75 return 200 "OK"; > 76 } > > > [root на tc ~]# curl http://localhost:8085/ > OK > > [root на tc ~]# curl -H 'X-Myheader: test' http://localhost:8085/ > > > type="application/rss+xml" title="nginx news" href="http://nginx.org/index.rss">nginx news > [ … ] > > > без if-a что-то не придумал, как обойтись. > > br, > Aziz. > > > > > >> On 16 Dec 2017, at 19:28, Fedor Dikarev wrote: >> >> Попробовал этот вариант, и без error_page он не переключается на local. >> Но если вписать error_page внутрь if-а, то вроде как работает как нужно. >> Осталось убедить самого себя, что без if-а тут не обойтись. Хотя и очень >> хочется. >> >> 16.12.17 15:21, Aziz Rozyev пишет: >>> а вариант с 2 апстримами не подходит? >>> >>> upstream remote_up { >>> remote_upstream:443; >>> } >>> >>> upstream local_up { >>> localhost:7070; >>> } >>> >>> map $http_x_some_header $remote { >>> “” 0; >>> “default” 1; >>> } >>> >>> if ($remote) { >>> proxy_pass https://remote; >>> } >>> proxy_pass http://local; >>> >>> >>> br, >>> Aziz. >>> >>> >>> >>> >>> >>>> On 16 Dec 2017, at 12:50, Fedor Dikarev wrote: >>>> >>>> Привет! >>>> >>>> Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока >>>> совсем беда :-( >>>> >>>> Формулировка, правда, изначально довольно извращенная: >>>> есть Nginx, по-умолчанию проксирует запрос в локально работающую node. >>>> Но если в запросе есть заголовок X-Some-Header, то запрос >>>> нужно спроксировать на другой сервер по https. >>>> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то >>>> сделать fallback опять на локальную node. >>>> >>>> первая мысль была: >>>> map $http_x_some_header $use_backend { >>>> "" http://localhost:7070; >>>> default https://remote_upstream; >>>> } >>>> upstream remote_upstream { >>>> server remote:443; >>>> server localhost:7070 backup; >>>> } >>>> >>>> но локальный сервер не https, и все не очень красиво :-( >>>> думал тут еще поднять на этом же nginx локальный https на порту 7073, >>>> проксировать в него как backup, но тут начинаются сложности с >>>> сертификатами. >>>> >>>> Опять же думал о другом варианте: >>>> proxy_pass $use_backend; >>>> error_page 500 502 504 = @fallback_local_node; >>>> >>>> location @fallback_local_node { >>>> internal; >>>> proxy_pass http://localhost:7070; >>>> } >>>> >>>> но тут получается что если заголовка не было, node ответил 502, то мы >>>> пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво >>>> получается... >>>> >>>> Может кто подскажет тут красивое решение? >>>> >>>> Ну и как feature request: может можно добавить к опции backup для >>>> директивы server в upstream еще какой-нибудь параметр backup_proto=http >>>> или другую опцию backup_http, чтобы при переключении на backup сервер >>>> менялся и протокол обращения. > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > From arozyev на nginx.com Sat Dec 16 22:00:49 2017 From: arozyev на nginx.com (Aziz Rozyev) Date: Sun, 17 Dec 2017 01:00:49 +0300 Subject: =?UTF-8?B?UmU6IGh0dHBzIHVwc3RyZWFtIHNlcnZlciDQuCDQu9C+0LrQsNC70YzQvdGL0Lkg?= =?UTF-8?B?YmFja3VwIGh0dHAgdXBzdHJlYW0=?= In-Reply-To: <4bfbca26-f12a-e6a4-85c5-4712f27d03e9@hamilton.rinet.ru> References: <6722BA8B-F586-43B7-973B-BE5907574B02@nginx.com> <2193CF18-D057-4605-ADC6-B2654F33591D@nginx.com> <4bfbca26-f12a-e6a4-85c5-4712f27d03e9@hamilton.rinet.ru> Message-ID: <8A4AD763-E669-4429-8D56-0702995112E9@nginx.com> если вопрос в “горячем” резерве remote-a, то не очень ясно зачем эти усложнения, просто сделайте location @fallback { internal; proxy_pass http://local_up; }, а в остальных случаях на remote, с error_page @fallback. Собственно, Вы это уже давно сделали. br, Aziz. > On 16 Dec 2017, at 23:20, Fedor Dikarev wrote: > > Суть задачи в том числе и во втором "но": >> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то >> сделать fallback опять на локальную node. > > то есть если у меня есть: >> upstream remote { server 127.0.0.1:8081; } >> upstream local { server 127.0.0.1:7070; } > >> server { listen 8081; return 200 remote\n; } >> server { listen 7070; return 200 local\n; } > > то по заголовку я хожу в remote сервер: >> curl -fs -H "X-Some-Header: yes" hamilton.rinet.ru/some_header >> remote > > Если же remote 500-тит, или вообще закоментировать его, то чтобы ходил в > local: >> curl -fs -H "X-Some-Header: yes" hamilton.rinet.ru/some_header >> local > > и да, эта конструкция ведет себя как надо: >> location =/some_header { >> proxy_intercept_errors on; >> if ($remote) { >> proxy_pass http://remote; >> error_page 500 502 504 = @local; >> } >> proxy_pass http://local; >> } >> location @local { >> internal; >> proxy_pass http://local; >> } > > Но в большой оригинальной задаче и так уже много if-ов, поэтому и > хочется получить решение без использования if-а. > > В идеале: собственно в виде backup_proto=http :) поскольку эта же задача > максимально элегантно решалась через >> upstream remote { >> server remote; >> server local backup; >> } > пока не появилось требование к https у upstream-а > > 16.12.17 22:52, Aziz Rozyev пишет: >> может я, конечно, не уловил сути задачи, но и без error_page переключается: >> >> 39 map $http_x_myheader $remote { >> 40 "" 0; >> 41 "test" 1; >> 42 } >> 43 >> 44 upstream remote_up { >> 45 server nginx.org:443; >> 46 } >> 47 >> 48 upstream local_up { >> 49 server localhost:7070; >> 50 } >> >> 58 server { >> 59 listen 8085; >> 60 location / { >> 62 proxy_set_header Host $host; >> 63 proxy_set_header Connection ""; >> 64 proxy_http_version 1.1; >> 65 >> 66 if ($remote) { >> 67 proxy_pass https://remote_up; >> 68 } >> 69 proxy_pass http://local_up; >> 70 } >> 71 } >> >> 73 server { >> 74 listen 7070; >> 75 return 200 "OK"; >> 76 } >> >> >> [root на tc ~]# curl http://localhost:8085/ >> OK >> >> [root на tc ~]# curl -H 'X-Myheader: test' http://localhost:8085/ >> >> >> > type="application/rss+xml" title="nginx news" href="http://nginx.org/index.rss">nginx news >> [ … ] >> >> >> без if-a что-то не придумал, как обойтись. >> >> br, >> Aziz. >> >> >> >> >> >>> On 16 Dec 2017, at 19:28, Fedor Dikarev wrote: >>> >>> Попробовал этот вариант, и без error_page он не переключается на local. >>> Но если вписать error_page внутрь if-а, то вроде как работает как нужно. >>> Осталось убедить самого себя, что без if-а тут не обойтись. Хотя и очень >>> хочется. >>> >>> 16.12.17 15:21, Aziz Rozyev пишет: >>>> а вариант с 2 апстримами не подходит? >>>> >>>> upstream remote_up { >>>> remote_upstream:443; >>>> } >>>> >>>> upstream local_up { >>>> localhost:7070; >>>> } >>>> >>>> map $http_x_some_header $remote { >>>> “” 0; >>>> “default” 1; >>>> } >>>> >>>> if ($remote) { >>>> proxy_pass https://remote; >>>> } >>>> proxy_pass http://local; >>>> >>>> >>>> br, >>>> Aziz. >>>> >>>> >>>> >>>> >>>> >>>>> On 16 Dec 2017, at 12:50, Fedor Dikarev wrote: >>>>> >>>>> Привет! >>>>> >>>>> Я тут пытаюсь навести красоту в одном конфиге Nginx-а и что-то пока >>>>> совсем беда :-( >>>>> >>>>> Формулировка, правда, изначально довольно извращенная: >>>>> есть Nginx, по-умолчанию проксирует запрос в локально работающую node. >>>>> Но если в запросе есть заголовок X-Some-Header, то запрос >>>>> нужно спроксировать на другой сервер по https. >>>>> Второе но: если этот прокси недоступен/не ответил/просто 500-тит, то >>>>> сделать fallback опять на локальную node. >>>>> >>>>> первая мысль была: >>>>> map $http_x_some_header $use_backend { >>>>> "" http://localhost:7070; >>>>> default https://remote_upstream; >>>>> } >>>>> upstream remote_upstream { >>>>> server remote:443; >>>>> server localhost:7070 backup; >>>>> } >>>>> >>>>> но локальный сервер не https, и все не очень красиво :-( >>>>> думал тут еще поднять на этом же nginx локальный https на порту 7073, >>>>> проксировать в него как backup, но тут начинаются сложности с >>>>> сертификатами. >>>>> >>>>> Опять же думал о другом варианте: >>>>> proxy_pass $use_backend; >>>>> error_page 500 502 504 = @fallback_local_node; >>>>> >>>>> location @fallback_local_node { >>>>> internal; >>>>> proxy_pass http://localhost:7070; >>>>> } >>>>> >>>>> но тут получается что если заголовка не было, node ответил 502, то мы >>>>> пойдем в node еще раз. Не то, чтобы прям ужас, но некрасиво >>>>> получается... >>>>> >>>>> Может кто подскажет тут красивое решение? >>>>> >>>>> Ну и как feature request: может можно добавить к опции backup для >>>>> директивы server в upstream еще какой-нибудь параметр backup_proto=http >>>>> или другую опцию backup_http, чтобы при переключении на backup сервер >>>>> менялся и протокол обращения. >> >> _______________________________________________ >> 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 From mdounin на mdounin.ru Sun Dec 17 02:10:49 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sun, 17 Dec 2017 05:10:49 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstGL0LfQstCw0YLRjCDRhNGD0L3QutGG0LjRjiDQvNC+0LQ=?= =?UTF-8?B?0YPQu9GPINC40Lcg0LTRgNGD0LPQvtCz0L4g0LzQvtC00YPQu9GPPw==?= In-Reply-To: References: Message-ID: <20171217021049.GK78325@mdounin.ru> Hello! On Fri, Dec 15, 2017 at 11:10:41PM +0200, Igor Savenko wrote: > Допустим, есть самописный модуль X, который может писать в юникс-сокет. > Есть другой модуль Y, которому нужно помочь в лог-фазе сбрасывать > информацию в наш сокет. Как из лог-хендлера второго модуля вызвать условную > функцию send_to_our_socket первого модуля? Спасибо! А в чём проблема, что мешает просто вот так вот, грубо, по пролетарски - взять и вызвать? Естественно, у первого модуля при этом хорошо бы завести заголовочный файл, в котором и описать соответствующую функцию, и вписать путь к соответствующему заголовочному файлу в ngx_module_incs и сам заголовочный файл в ngx_module_deps перед вызовом auto/module в config-файле первого модуля. И если оба модуля компилируются динамически - будет важен порядок загрузки. Но в целом каких-то специальных проблем тут быть не должно. -- Maxim Dounin http://mdounin.ru/ From igor.bliss на gmail.com Sun Dec 17 10:54:37 2017 From: igor.bliss на gmail.com (Igor Savenko) Date: Sun, 17 Dec 2017 12:54:37 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstGL0LfQstCw0YLRjCDRhNGD0L3QutGG0LjRjiDQvNC+0LQ=?= =?UTF-8?B?0YPQu9GPINC40Lcg0LTRgNGD0LPQvtCz0L4g0LzQvtC00YPQu9GPPw==?= In-Reply-To: <20171217021049.GK78325@mdounin.ru> References: <20171217021049.GK78325@mdounin.ru> Message-ID: Большое человеческое спасибо за ответ, Максим! Вы правы, ничего не мешает. Просто хотелось это сделать красиво, правильно, основываясь на существующих примерах (к сожалению, я пока не нашел в коде nginx, его модулей 3rd party модулей, где это бы делалось -- то ли плохо искал, то ли мало). Буду пробовать. 17 декабря 2017 г., 4:10 пользователь Maxim Dounin написал: > Hello! > > On Fri, Dec 15, 2017 at 11:10:41PM +0200, Igor Savenko wrote: > > > Допустим, есть самописный модуль X, который может писать в юникс-сокет. > > Есть другой модуль Y, которому нужно помочь в лог-фазе сбрасывать > > информацию в наш сокет. Как из лог-хендлера второго модуля вызвать > условную > > функцию send_to_our_socket первого модуля? Спасибо! > > А в чём проблема, что мешает просто вот так вот, грубо, по > пролетарски - взять и вызвать? > > Естественно, у первого модуля при этом хорошо бы завести > заголовочный файл, в котором и описать соответствующую функцию, и > вписать путь к соответствующему заголовочному файлу в > ngx_module_incs и сам заголовочный файл в ngx_module_deps перед > вызовом auto/module в config-файле первого модуля. И если оба > модуля компилируются динамически - будет важен порядок загрузки. > Но в целом каких-то специальных проблем тут быть не должно. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Sun Dec 17 18:28:07 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 17 Dec 2017 21:28:07 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstGL0LfQstCw0YLRjCDRhNGD0L3QutGG0LjRjiDQvNC+0LQ=?= =?UTF-8?B?0YPQu9GPINC40Lcg0LTRgNGD0LPQvtCz0L4g0LzQvtC00YPQu9GPPw==?= In-Reply-To: References: <20171217021049.GK78325@mdounin.ru> Message-ID: <1910694.zApBrERWYO@vbart-laptop> On Sunday, 17 December 2017 13:54:37 MSK Igor Savenko wrote: > Большое человеческое спасибо за ответ, Максим! Вы правы, ничего не мешает. > Просто хотелось это сделать красиво, правильно, основываясь на существующих > примерах (к сожалению, я пока не нашел в коде nginx, его модулей 3rd party > модулей, где это бы делалось -- то ли плохо искал, то ли мало). Буду > пробовать. > [..] Есть такой 3rd-party модуль: https://github.com/simpl/ngx_devel_kit и по меньшей мере 6 других модулей его используют. -- Валентин Бартенев From igor.bliss на gmail.com Sun Dec 17 19:13:57 2017 From: igor.bliss на gmail.com (Igor Savenko) Date: Sun, 17 Dec 2017 21:13:57 +0200 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstGL0LfQstCw0YLRjCDRhNGD0L3QutGG0LjRjiDQvNC+0LQ=?= =?UTF-8?B?0YPQu9GPINC40Lcg0LTRgNGD0LPQvtCz0L4g0LzQvtC00YPQu9GPPw==?= In-Reply-To: <1910694.zApBrERWYO@vbart-laptop> References: <20171217021049.GK78325@mdounin.ru> <1910694.zApBrERWYO@vbart-laptop> Message-ID: Большое спасибо за ответ, Валентин. Вариант. о котором говорил Максим, заработал и, по крайней мере, делает то, что от него ожидалось. Гляну на указанный Вами модуль, может, получится сделать лучше/правильнее. 17 декабря 2017 г., 20:28 пользователь Валентин Бартенев написал: > On Sunday, 17 December 2017 13:54:37 MSK Igor Savenko wrote: > > Большое человеческое спасибо за ответ, Максим! Вы правы, ничего не > мешает. > > Просто хотелось это сделать красиво, правильно, основываясь на > существующих > > примерах (к сожалению, я пока не нашел в коде nginx, его модулей 3rd > party > > модулей, где это бы делалось -- то ли плохо искал, то ли мало). Буду > > пробовать. > > > [..] > > Есть такой 3rd-party модуль: https://github.com/simpl/ngx_devel_kit > и по меньшей мере 6 других модулей его используют. > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx на mva.name Mon Dec 18 13:43:12 2017 From: nginx на mva.name (Vadim A. Misbakh-Soloviov) Date: Mon, 18 Dec 2017 20:43:12 +0700 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQstGL0LfQstCw0YLRjCDRhNGD0L3QutGG0LjRjiDQvNC+0LQ=?= =?UTF-8?B?0YPQu9GPINC40Lcg0LTRgNGD0LPQvtCz0L4g0LzQvtC00YPQu9GPPw==?= In-Reply-To: <1910694.zApBrERWYO@vbart-laptop> References: <1910694.zApBrERWYO@vbart-laptop> Message-ID: <1538219.dHsLA9xC6e@note> > Есть такой 3rd-party модуль: https://github.com/simpl/ngx_devel_kit > и по меньшей мере 6 других модулей его используют. Вот только когда я попробовал сделать его динамическим и даже грузить до других модулей - всё равно была толпа ошибок об отсутствующих символах :'( From gmm на csdoc.com Tue Dec 19 08:13:23 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 19 Dec 2017 10:13:23 +0200 Subject: https://www.nginx.com/blog/performance-tuning-tips-tricks/ Message-ID: <675aacb9-b2e3-1e66-0d5c-6c8f44b276da@csdoc.com> Здравствуйте, All! В статье https://www.nginx.com/blog/performance-tuning-tips-tricks/ есть ошибки: error_log off; - это не выключит error_log, а сделает лог-файл с именем off в текущем каталоге. И вообще, выключать error_log - это плохая идея, странно что такое рекомендуют на сайте www.nginx.com. sendfile_max_chunk 512; - размер в 512 байт отрицательно скажется на производительности, лучше будет поставить sendfile_max_chunk 1M; sendfile_max_chunk sets the size of the chunks pushed to the upstream servers. - насколько мне известно, директива sendfile_max_chunk не имеет никакого отношения к upstream servers. P.S. Возможно в этой статье есть и другие ошибки, которые я не заметил. -- Best regards, Gena From vbart на nginx.com Tue Dec 19 21:51:27 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Wed, 20 Dec 2017 00:51:27 +0300 Subject: https://www.nginx.com/blog/performance-tuning-tips-tricks/ In-Reply-To: <675aacb9-b2e3-1e66-0d5c-6c8f44b276da@csdoc.com> References: <675aacb9-b2e3-1e66-0d5c-6c8f44b276da@csdoc.com> Message-ID: <1780105.dB2ezUBPzd@vbart-workstation> On Tuesday 19 December 2017 10:13:23 Gena Makhomed wrote: > Здравствуйте, All! > > В статье https://www.nginx.com/blog/performance-tuning-tips-tricks/ > есть ошибки: > > error_log off; > > - это не выключит error_log, > а сделает лог-файл с именем off в текущем каталоге. > > И вообще, выключать error_log - это плохая идея, > странно что такое рекомендуют на сайте www.nginx.com. > > sendfile_max_chunk 512; > > - размер в 512 байт отрицательно скажется на производительности, > лучше будет поставить sendfile_max_chunk 1M; > > sendfile_max_chunk sets the size of the chunks pushed to the upstream > servers. > > - насколько мне известно, директива sendfile_max_chunk не имеет никакого > отношения к upstream servers. > > P.S. > > Возможно в этой статье есть и другие ошибки, которые я не заметил. > Спасибо за замечания. По какой-то ошибке эта статья, собранная из разных, не всегда понятных источников и вырванных из контекста рекомендаций, миновала какое-либо техническое ревью. Эти и многие другие замечания направлены ответственным лицам. Будут приняты меры чтобы этого больше не повторялось. -- Валентин Бартенев From nginx-forum на forum.nginx.org Thu Dec 21 04:17:19 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:17:19 -0500 Subject: ODM Acrylic Wine Rack Message-ID: <35de3d6ab6a18ef3b7bf47853e48fa8d.NginxMailingListRussian@forum.nginx.org> Single Tier Wall Mounted Acrylic Wine Rack Material: acrylic Color: Transparent acrylic Use: perfect showcase your cake and bread. Applications: Bakery, shops, supermarkets and so on Packaging: cartons, foam and PE bags are individually packaged Shipping: courier, shipping and air transport. Uses: can hold 8 red wine bottle. Applications: home, office, salon, school and store storage. Installation: ① wine rack can be mounted on the vertical or horizontal position. ② the design of this product lets the rack sit 2cm from the wall and when the wine rack are place in the cabin the fixings are hidden. ③ Easy assembly - 2 screws supplied, Very strong and sturdy. About us: 1.How about your After-sale service We have professional technical support team.Yes, they can speak English.You can contact us by email, Whatsapp, Skype or other way to inform about your problem. 2.Are you a manufacturer? * Yes 3.How to order * You send us drawing or sample * We carry through project assessment * We give you a design * You think the design is ok * We make the sample and send it to you * You think the sample is good then place an order and pay us 30 ~ 50% deposit * We start to make the product * When the goods is done, you pay us the balance you, we deliver it to you * The whole order is done, thank you !! Our aim to meet your needs, quality is our culture, do not miss a chance of cooperation!ODM Acrylic Wine Rack website:http://www.ysdisplays.com/wine-rack/acrylic-wine-rack/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277853,277853#msg-277853 From nginx-forum на forum.nginx.org Thu Dec 21 04:17:29 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:17:29 -0500 Subject: USB Sharing Switch factory Message-ID: <065dc0753893bbfa82fde15673fd5676.NginxMailingListRussian@forum.nginx.org> 2 Port USB 2.0 Selector Switch 2 PC share 1 USB Device Like Printer Flash Driver Mouse Keyboard with USB-A interface  2 Port USB 2.0 Sharing Switch Box, Allow 2 PC to share one USB device, for example, printer scanner, camera, keyboard and any other devices with USB port. Type A Male to Type B Male. USB 2-channel switch (2 TYPE-B connectors, 1 USB TYPE-A connector). All PC / MAC, Printers External Hard Drives and other USB Devices button switch, simple and convenient, No external power supply needed It allows 2 computers access to one single USB compliant device Compliant with USB 2.0 specification. Works with either USB 1.1 or 2.0 peripherals. Supports DOS, Windows 7, 8 Win3.X, Win95/98/98SE/2000/ME/XP , WinNT . Weight: 200g . Crust:Metal . Dimensions: 68*45*20mm Warranty and Guarantee: Guarantee for all products is 6 months from the selling day (except original items) and change new for all quality defective items. Payment Methods: Payment Terms: 30% deposit and 70% balance before shipping. T/T or Paypal. Shipping Methods: Can be shipped by international express like DHL/ TNT/ FedEx /UPS / China POST/Hong Kong POST, or by sea, etc. Delivery Time: -Sample orders will be shipped within 1-3days after your order confirmation and got your payment. -Normal orders will be shipped in 3-7days after got payment. Our service: 1. All of inquiry will be replied within 24 hours. 2. To ensure the quality of products, all of them will be tested before delivery. 3. Our products have 1Year Guarantee.USB Sharing Switch factory website:http://www.ysinton.com/usb-sharing-switch/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277854,277854#msg-277854 From nginx-forum на forum.nginx.org Thu Dec 21 04:17:39 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:17:39 -0500 Subject: Stretch Workout Bustier Crop Top Message-ID: <5fb85e1a38d77eb30d2dcb3f497ebb8f.NginxMailingListRussian@forum.nginx.org> 1. Our History Yomsong Leggings Co.,Ltd (Briefly named "Yomsong" hereinafter) was established in 2005, and headquarter is located in China international business Yiwu City, Zhejiang Province. In 2005, Yomsong was a small operation doing jewelry. With the excellent quality, and reasonable price, Yomsong won acknowledgment and support quickly. In 2012, we decided to do leggings business. Although time has past, Yomsong’s values have not changed— our company remains committed to offering high-quality products at everyday low prices, while delivering superior customer service. Today, Yomsong has been the top 5 producers of quality leggings parts. We devote to meet customer’s needs on every aspect and offer top quality so as to keep clients safe as well as the market stable. We are focused on long-term business. Hope we can establish a strong and successful trading relationship in the near future. We are looking forward to your cooperation soon. 2. Our Company&Factory Yomsong is the industry's leading company who is engaged in researching&developing, manufacturing and sales of new leggings. Our company is comprised of six departments---- Development Department, Market Research Department, Sales Department, Production Department, Warehouse Department, and Packaging Department. The division of labor is clear-cut , everyone is charged with specific responsibilities . Our factory is equipped with a full set of modern clothing manufacturing equipment, such as high-speed sewing machine, double-needle sewing machine, computer-automatic sleeve machine, etc. The exquisite craftsmanship with full equipment makes our products be the best. 3. Our Products Our Leggings are famous for exquisite craftsmanship, excellent quality, attractive designs, latest technology,and reasonable price. We supply leggings products all over the globe to a wide range of companies worldwide, ranging from large multinational organizations to small individual companies. Yomsong Products includes the following: 1. Leggings 2. Capri leggings 3. Pants 4. Tops 5. Skirts & Dress ... Besides, the products can be custom-made according to your requirement. 4. Product Application Leggings for clothes wearing are widely popular in the following group, such as young ladies, fitness enthusiasts: ---Usually capri leggings are the best choice if you have a bent leg ministry line. ---If you are a little chubby, dark capri leggings can cover the thick line of your legs. Meanwhile, you can match a A-line skirt. It can make the visual perception of long legs through the contrast between wide skirt and thin legs. ---Our fitness leggings are fit for everyone who loves shape and fitness. Floral capri leggings, which from our main production line, are widely popular in European and American. 5. Product Market 6. Our Activities 7. Our Service Pre-sale service (1) Your inquiry of our products will be reply in 24 hours. (2) We will provide you with newest quotation and the specific product specifications. (3) Good quality product, quick delivery time, competitive price, strong packing (4) Well equipped facilities, outstanding workmanship and excellence quality control through out (5) We have good translations, enthusiastic sales and service who can speak fluently in English After Sale Service (1)Updated the shipping information as soon as possible. (2)Ensure the products delivery on time. (3)Documents will be send correctly and promptly 8. FAQ' s v Q: How does your factory do regarding quality control? A: Quality is priority. Yomsong people always attach great importance to quality controlling from the very beginning to the very end: 1.The all material we used are ECO-friendly. 2.Proficient workers care every detail during the process. 3.Quality Control Department specially responsible for quality checking in each process. v Q: May I order small order quantity? A: Yes, small order as first-time trial order is OK for us. v Q: Can you provide sample? A:Yes, please just feel free to contact us for sample asking. v Q: What is the lead time? A: If the styles we get ready stock , we can ship you a sample in 24 hours; If the styles you choose we do not have ready stock, we have to make one sample, normally it takes 10--14 days. v What are your terms of payment? A: For large orders, we can accept both payment T/T and L/C; For small orders and trial order, we only accept payment by T/T. 30% deposit in advance the balance should be paid before shipment. v Packaging&Shipping Packaging (As buyer's requirement / With buyer's logo and label) Shipping For medium and urgent orders, we adopt bulk air shipment, there are many international couriers for your option, such as DHL, FedEx, UPS and China EMS. If you already have account with DHL, UPS or other couriers, you can advise us in advance and we can send the goods under your account. For larger orders, we adopt sea shipping. In general, the ocean shipment will spend more days than by air, so the shipping way is subject to your demand in advance. Customs clearance paperwork and procedures are handled by the forwarder. They may need to contact you in certain cases to confirm details of a shipment. In any cases where additional paperwork is required for customs clearance, Yomsong will assist you as much as possible.Stretch Workout Bustier Crop Top website:http://www.ysleggings.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277855,277855#msg-277855 From nginx-forum на forum.nginx.org Thu Dec 21 04:17:49 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:17:49 -0500 Subject: Woodworking CNC Router Message-ID: <30f6952c85586e2842e4bd7d00e73e19.NginxMailingListRussian@forum.nginx.org> YS-2030 Wood CNC Router Functional Characteristics 1. Vacuum table with 6 vacuum zones, which can absorb different size materials, no oil vacuum pump, high suction, more convenient, stable capability. 2. HIWIN square orbit, double slippers, bearing heavy, working steadily, high precision, and long life time, import ball screw, high precision for cutting. 3. High speed stepper motor and drivers, and tow motors for Y axis. Max speed is 25M/MIN. With water cooling spindle highly upgrade the processing speed. 4. The optional equipment for spindle is Japan imported high power water cooling motor (Japan NSK bearing) high speed spindle, stable capability. 5. Unique intelligent budget principle, fully develops the potential of the motor and lead to high processing speed, the synchronization of curves and straight lines, smoother curves. 6. Well compatibility: CAD/CAM designing software e.g. Type3/Artcam/Castmate/Ucancam etc. Apply to industry and materials Furniture industry: the cabinet door, wooden door, solid wood, plate, doors and Windows, tables and chairs. Decoration industry: screen, wave plates, large wall hanging, advertising board, logo production. Performance index Model NOYS-2030B Wood CNC Router Table Size2140×3500mm X Y Z Traveling Area2000x3000*200mm Table StructureVacuum Table X Y Transmisson Rack Gear Z Transmission Germany Neef Ball Screws X Y Z guide rail TAIWAN HIWIN Square Rail Spindle power 4.5 kw Water Cooling Spindle Max Spindle speed24000r/ min Max Traveling speed45m/s Max Working speed38m/s Processiong Accuracy±0.025mm Reposition Accuracy≤0.025mm Working Voltage380V /50Hz Work-holdingT-slot Clamping ProcessorWindows /100MHz InterfacePCI CommandG*.u00*.mmg*.plt Operation systemDSP Power（not include the spindle）500W Net weight /Gross Weight1400KGS /1600KGS Package dimension3900*2900*1540mm Available Options for YS CNC Router YS CNC router optional accessories: Working tableSpindle (0-9.0KW)SystemZ axis sizeDriver and motorRotary axis diameter TslotvacuumHQDHSDNc-studio March 3 DSP0-23.6inch 0-600mmStepper or servo0-19.6inch 0-500mm YS cnc router model Process areaWorking area (inch/mm)Max working speedTravel speed X(inch/mm)Y(inch/mm)Z(inch/mm) YS 404015.715.75.915.7*15.7787inch/s 20m/min984inch/s 25m/min 400400150400*400 YS 606023.623.65.923.6*23.6 600600150600*600 YS 609023.635.45.923.6*35.4 600900150600*900mm YS 121247.247.27.847.2*47.2 120012002001200*1200 YS 122447.294.47.847.2*94.4 120024002001200*2400 YS 132551987.851*98 130025002001300*2500 YS 1530591187.859*118 150030002001500*3000 YS 203078.71187.878.7*118 200030002002000*300 YS 204078.7157.47.878.7*157.4 200040002002000*4000mm Situated in the prosperous city, Jinan, China, Yishun CNC Machinery is a professional manufacturer of 2030 carpenter carpentry crafts wood cnc router carving engraving machine kitchen cabinet cnc router with 3 axis wood door making. Our factory has a strict quality control system and advanced equipment. With the highest quality 2030 carpenter carpentry crafts wood cnc router carving engraving machine kitchen cabinet cnc router with 3 axis wood door making for sale, you can rest assured to buy our equipment at competitive price now. Don't hesitate any more.Woodworking CNC Router website:http://www.yswoodcncrouter.com/cnc-router/wood-cnc-router/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277856,277856#msg-277856 From nginx-forum на forum.nginx.org Thu Dec 21 04:17:58 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:17:58 -0500 Subject: CARGOES-PACKING OR UNPACKING Message-ID: <09b7df0f709d7f0b3a55511ea285c57d.NginxMailingListRussian@forum.nginx.org> When the owner delivers the goods to our warehouse, we will take pictures of your goods, make sure that your goods have been safely stored and stored well, The loading container and confirm the money intact, no deformation, no crack, no water, no oil, no smell, supervision of loading the workers the right to place the goods, reasonable arrangement of the space in the cabinet, to ensure the goods neatly ordered (with maximum use of space, the arrangement of goods firm collapsed in principle),Taking pictures of goods in storage to provide evidence for the safe placement of the goods to ensure that the goods are in a reasonable position in our warehouse .CARGOES-PACKING OR UNPACKING website:http://www.ytdlogisticsgroup.com/warehousing/cargoes-packing-or-unpacking/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277857,277857#msg-277857 From nginx-forum на forum.nginx.org Thu Dec 21 04:18:07 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:18:07 -0500 Subject: Motorcycle With Sidecar quotation Message-ID: <565105c4c02de787bd6ed3384ef54ff8.NginxMailingListRussian@forum.nginx.org> Our Factory Chongqing Guangben Wanqiang Motorcycle manufacturing Co.Ltd is located in Chongqing.“The quality is the life, the service is the soul” is our motto, we have strict quality control system and excellent after-service. We never stop researching development and promotion of our new products. We are always ready to accept new ideas and advice from our customers in order to create innovative design and upgrade quality. Our effort has been well acknowledged by our customers from all over the world and we have built stable and highly trusted cooperation relationship with them. Our Product We have specialized in producing Motorcycle, motorcycle Engine and Motorcycle spares since 2003. Product Application Motorcycle, cub motorcycle, dirt-bike, street bike. Our Certificate 3C,EEC,SGS,SONCAP. Production Equipment 4 assembly line,3 detection line, 2 package line. Production Market Africa, South America, Russia, Turkey and etc. Our Service Our company has advanced production equipment, mature technology, complete detection means, stringent and effective quality assurance system and good management experience, which make our company's products with not only characteristics of high efficiency and low noise, but also advantages of simplicity, superior performance, long life. We also make different designs according to the customers' requirements.Motorcycle With Sidecar quotation website:http://www.yuandamotor.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277858,277858#msg-277858 From nginx-forum на forum.nginx.org Thu Dec 21 04:18:16 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:18:16 -0500 Subject: best butyl tubes Message-ID: <84a22d6e43741fda7fc132e32d993fe3.NginxMailingListRussian@forum.nginx.org> Brief Introduction of YLT Group Co. Ltd. Located by the Yellow Sea, on the beautiful Qingdao West Coast Development Zone, YLT Group is a comprehensive company that produce and sell tires, auto parts, machinery. Rely on tremendous products of tires, machinery, and auto parts , with stable and high-quality supply, the Group Company has taken possession of many customers’ favor. Through efforts of tens of years, YLT Group has established solid business relationship with many clients from Asia, Africa, Europe and America. Under global information and knowledge economy, the company speeds up the projecting of tires, auto parts, and machinery marketing for her international and diversified strategic target. Guided by creating value for customers, adhering to 100% integrity in good faith, YLT Group has a united and ambitious marketing team, that has made remarkable achievements. YLT Group would like to step froward hand in hand with all customers to create a glorious future!best butyl tubes website:http://www.yuanlaitai.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277859,277859#msg-277859 From nginx-forum на forum.nginx.org Thu Dec 21 04:18:25 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:18:25 -0500 Subject: 16gb wooden crystal usb drive price list Message-ID: <7b4a4d9f0eabd4a474e254f8923de9b5.NginxMailingListRussian@forum.nginx.org> Our History Yuan Xin has focused on top quality USB DRIVE and POWER BANK products for about 10 years in China. We started as a small operation, but now have become one of the leading suppliers in the USB Flash Drive & Power Bank industry in China. Today, Yuan Xin has been one of the top producers, such as: USB Flash Drive, Power Bank, Bluetooth Speaker, Wall Charger, Car Charger, USB Cable. Our Factory Yuan Xin is located in the beautiful scenery’s Longhua New District Shenzhen. As a global supplier in the USB flash drive; Power Bank; car charger, wall charger, SSD, Bluetooth Speaker, personalized custom PVC Cable and other burgeoning electronic product, Yuan Xin is to create added value for customers around the world. Our Product Yuan Xin Products includes the following: 1, USB Flash Drive 2, Power Bank 3, Car Charger 4, Bluetooth Speaker 5, Wall Charger 6, SSD 7, USB Cable We supply our products all over the globe to a wide range of companies worldwide, ranging from large multinational organizations to small individual companies. Product Application Our products are widely used in the following industry, ---promotion ---gift ---marketing and advertising ---consumer electronics ---media production ---computer hardware Our Certificate We always feel that all success of our company is directly related to the quality of the products we offer. They meet the highest quality requirements as stipulated in ISO 9001-2008, CE, ROHS, FCC, C-TICK, PSE, UL guidelines and our stringent quality control system. Production Equipment We have the advanced CNC machine, injection machine, metal stamping machine, PVC machine, laser machine, digital printing machine, SMT, packing machine, etc. With a strong production capacity, we provide thousands of USBs and Power Banks every day to the world Our service pre-sale service: according to our clients' needs, Yuan xin can provide free drawings and samples; on-sale service,we control the products quality for every step during the manufacturing process, and also take pictures for our clients to know their order process.after sale service,all of our products have 1 year warranty,we also offer technical support for free Production Market We have customers from both domestic market and oversea market. Every Yuan Xin Sales managers can speak fluent English for good communication. Our main sales market: North America 30.00% Southern Europe 20.00% Asia 20.00% South America 10.00% The Other 20.00% 16gb wooden crystal usb drive price list website:http://www.yuanxintek.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277860,277860#msg-277860 From nginx-forum на forum.nginx.org Thu Dec 21 04:18:33 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:18:33 -0500 Subject: wholesale Frosted Glass Adhesive Message-ID: <07667541b60eb82a72b2dce7df48d70b.NginxMailingListRussian@forum.nginx.org> Guangzhou Yuanyi Packing Material Co.,Ltd was established in 2006,It has over 11 years produced experience. Our factory is located in Guangzhou, close to the highway, the traffic is very convenient. Our existing factory covers an area of over 5000 square meters, more than 100 employees. We focus on producing pvc wallpaper,window film,golden rods sticker for many years. Window Film, PVC self-adhesive wallpaper, Golden rods sticker, rods pipe sticker Home and commercial decoration, Wall and Window, Bathroom, living room, bedroom, kitchen 1.79 M wide full automatic high speed 7 color computer printing line High speed and extra wide hot melt coating machine 5 automatic embossed lines 3 high-speed cutting line Middle East 1-3million dollars for one year Southeast Asia 1 million dollars for one yearwholesale Frosted Glass Adhesive website:http://www.yuanyi-windowfilm.com/ website2:http://www.decoration-windowfilm.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277861,277861#msg-277861 From nginx-forum на forum.nginx.org Thu Dec 21 04:18:43 2017 From: nginx-forum на forum.nginx.org (jiajia) Date: Wed, 20 Dec 2017 23:18:43 -0500 Subject: best cooling coolers manufacturers Message-ID: <06f49e414722960cbcbd4ac29b85a563.NginxMailingListRussian@forum.nginx.org> Founded in 2005, Yuda is a manufacturer of high quality aluminum plate and bar heat exchangers that are commonly known in the industry as radiators, oil coolers and aftercoolers. Our products can be found in a multitude of applications such as wind turbine, air compressor, oil&gas exploration, construction machinery, agricultural, forestry, earthmoving, hydraulic, diesel engine application. Our company is committed to promote technological ability, and continuously expand the product applications and market both at home and abroad Our exports increased year by year, and now we have been a leader of heat exchanger for wind power generators. And received high praise from our clients. We originate quality, innovation and honesty as our development source. Our factory is ISO9001 certified to assure our customer of consistent high quality products, and some of them are CE certified base on our customers’ requirements. We will offer the best cooling solution for you.best cooling coolers manufacturers website:http://www.yudaheatexchanger.com/ website2:http://www.yudaradiator.com/ Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277862,277862#msg-277862 From nginx-forum на forum.nginx.org Thu Dec 21 08:00:58 2017 From: nginx-forum на forum.nginx.org (softshape) Date: Thu, 21 Dec 2017 03:00:58 -0500 Subject: =?UTF-8?B?0KPRgdC70L7QstC40LUg0L/QviDQstGA0LXQvNC10L3QuCAtINGC0LDQuiDQvNC+?= =?UTF-8?B?0LbQvdC+Pw==?= Message-ID: Всем привет, задача - закрыть ботам доступ на сайт днем и открыть ночью. Сейчас условие отсечки ботов простое - if ($http_user_agent ~ Linguee|statdom|SemrushBot|AhrefsBot|Reefeedbot|bingbot|SputnikBot|Crowsnest|MegaIndex|......... return 403; } Что нужно в него добавить, чтобы возвращать 403ю только, допустим, с 6:00 до 23:00 ? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277867,277867#msg-277867 From fe на hamilton.rinet.ru Thu Dec 21 08:07:41 2017 From: fe на hamilton.rinet.ru (Fedor Dikarev) Date: Thu, 21 Dec 2017 11:07:41 +0300 Subject: =?UTF-8?B?UmU6INCj0YHQu9C+0LLQuNC1INC/0L4g0LLRgNC10LzQtdC90LggLSDRgtCw0Log?= =?UTF-8?B?0LzQvtC20L3Qvj8=?= In-Reply-To: References: Message-ID: В cron что-то подобное: > cp -f /etc/nginx/includes/condition.conf.day /etc/nginx/includes/condition.conf > nginx -t && pkill -HUP nginx И симметричную строчку на вечер. 21.12.17 11:00, softshape пишет: > Всем привет, > > задача - закрыть ботам доступ на сайт днем и открыть ночью. Сейчас условие > отсечки ботов простое - > > if ($http_user_agent ~ > Linguee|statdom|SemrushBot|AhrefsBot|Reefeedbot|bingbot|SputnikBot|Crowsnest|MegaIndex|......... > return 403; > } > > Что нужно в него добавить, чтобы возвращать 403ю только, допустим, с 6:00 до > 23:00 ? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277867,277867#msg-277867 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru > -- Fedor Dikarev From nginx-forum на forum.nginx.org Sun Dec 24 09:51:44 2017 From: nginx-forum на forum.nginx.org (ShivaS) Date: Sun, 24 Dec 2017 04:51:44 -0500 Subject: =?UTF-8?B?JHNlcnZlciBwb3J0INCy0YHQtdCz0LTQsCDQv9C10YDQstCw0Y8g0LTQuNGA0LU=?= =?UTF-8?B?0LrRgtC40LLQsCBsaXN0ZW4=?= Message-ID: <7ffce3c04502dbab753c4d6ddfcbcdc1.NginxMailingListRussian@forum.nginx.org> Добрый день, Имеется блок server {} с двумя директивами listen: listen:80; listen:81; на 81й порт прилетает траффик SSL, который оффлоаднулся на сервере выше. переменная $server_port упрямо видит только 80. Это by design? И если да, то есть ли какое-то решение узнать, что реквест прилетел на другой порт (без разделения конфигов или добавления переменных/хедеров на SSL offload сервере)? Спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277879,277879#msg-277879 From nginx-forum на forum.nginx.org Sun Dec 24 10:49:52 2017 From: nginx-forum на forum.nginx.org (ShivaS) Date: Sun, 24 Dec 2017 05:49:52 -0500 Subject: =?UTF-8?B?UmU6ICRzZXJ2ZXIgcG9ydCDQstGB0LXQs9C00LAg0L/QtdGA0LLQsNGPINC00Lg=?= =?UTF-8?B?0YDQtdC60YLQuNCy0LAgbGlzdGVu?= In-Reply-To: <7ffce3c04502dbab753c4d6ddfcbcdc1.NginxMailingListRussian@forum.nginx.org> References: <7ffce3c04502dbab753c4d6ddfcbcdc1.NginxMailingListRussian@forum.nginx.org> Message-ID: false alarm, 81й порт был перехвачен завалявшимся конфигом, который не удалился все отлично работает, спасибо! ;-) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277879,277880#msg-277880 From gmm на csdoc.com Mon Dec 25 18:51:14 2017 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 25 Dec 2017 20:51:14 +0200 Subject: contrib/vim In-Reply-To: <20171011134247.GV75166@mdounin.ru> References: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com> <79712f9d-af6a-bfe9-a7a0-bffe9b7dbac4@nginx.com> <7e29fa3a-1787-c31d-09c9-9473fb508481@csdoc.com> <20171011134247.GV75166@mdounin.ru> Message-ID: <2d167819-f789-3387-8cf6-680210c1f25c@csdoc.com> On 11.10.2017 16:42, Maxim Dounin wrote: >> В tar.gz дистрибутиве есть каталог contrib/vim - можно ли сделать так, >> чтобы содержимое этого каталога при установке пакета ложилось в каталог >> /usr/share/vim/vimfiles ? Это было бы очень удобно для пользователей vim >> - тогда vim будет автоматически похватывать эти конфигурационные файлы. > Содержимое contrib/ ни коим образом не поддерживается > разработчиками, и ставить это в рамках пакетов, IMHO, было бы странно. Странно, что не поддерживается, ведь файл contrib/vim/syntax/nginx.vim можно автоматически проверять на актуальность небольшим скриптом, который сканирует исходники nginx и показывает, какие директивы отсутствуют в файле nginx.vim, такой скрипт пишется за 15 минут. Если ставить содержимое contrib/vim в /usr/share/vim/vimfiles/ с помощью официального пакета из репозитория nginx нельзя, то каким тогда способом нам актуализировать конфиги vim? Актуализировать contrib/vim на всех серверах вручную - это monkey job, мне пока что приходит в голову идея автоматизировать это через cron: /etc/cron.daily/nginx-vim #!/bin/bash /usr/bin/curl --silent http://hg.nginx.org/nginx/archive/tip.tar.gz --output /tmp/nginx.tar.gz /usr/bin/tar -C /tmp -xf /tmp/nginx.tar.gz for top in /tmp/nginx-* ; do /usr/bin/cp -r $top/contrib/vim/* /usr/share/vim/vimfiles/ ; done /usr/bin/rm -rf /tmp/nginx-* /usr/bin/rm -f /tmp/nginx.tar.gz Так нормально будет? Сайт http://hg.nginx.org/ выдержит нагрузку, если этот скрипт я пропишу в cron на примерно 50 своих серверах? -- Best regards, Gena From mdounin на mdounin.ru Tue Dec 26 16:10:55 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 26 Dec 2017 19:10:55 +0300 Subject: nginx-1.13.8 Message-ID: <20171226161055.GF34136@mdounin.ru> Изменения в nginx 1.13.8 26.12.2017 *) Добавление: теперь при использовании параметра transparent директив proxy_bind, fastcgi_bind, memcached_bind, scgi_bind и uwsgi_bind nginx автоматически сохраняет capability CAP_NET_RAW в рабочих процессах. *) Добавление: улучшения в определении размера строки кэша процессора. Спасибо Debayan Ghosh. *) Добавление: новые директивы в скриптах подсветки синтаксиса для vim. Спасибо Геннадию Махомеду. *) Исправление: процедура обновления исполняемого файла не работала, если после завершения родительского процесса новым родительским процессом nginx'а становился процесс с PID, отличным от 1. *) Исправление: модуль ngx_http_autoindex_module неправильно обрабатывал запросы с телом. *) Исправление: в директиве proxy_limit_rate при использовании с директивой keepalive. *) Исправление: при использовании "proxy_buffering off" часть ответа могла буферизироваться, если клиентское соединение использовало SSL. Спасибо Patryk Lesiewicz. *) Исправление: в директиве proxy_cache_background_update. *) Исправление: переменную вида "${name}" с именем в фигурных скобках нельзя было использовать в начале параметра не заключив весь параметр в кавычки. -- Maxim Dounin http://nginx.org/ From mdounin на mdounin.ru Tue Dec 26 18:27:25 2017 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 26 Dec 2017 21:27:25 +0300 Subject: contrib/vim In-Reply-To: <2d167819-f789-3387-8cf6-680210c1f25c@csdoc.com> References: <5d43d2bd-8a0f-3025-8431-a8b718ca44f8@csdoc.com> <79712f9d-af6a-bfe9-a7a0-bffe9b7dbac4@nginx.com> <7e29fa3a-1787-c31d-09c9-9473fb508481@csdoc.com> <20171011134247.GV75166@mdounin.ru> <2d167819-f789-3387-8cf6-680210c1f25c@csdoc.com> Message-ID: <20171226182725.GH34136@mdounin.ru> Hello! On Mon, Dec 25, 2017 at 08:51:14PM +0200, Gena Makhomed wrote: > On 11.10.2017 16:42, Maxim Dounin wrote: > > >> В tar.gz дистрибутиве есть каталог contrib/vim - можно ли сделать так, > >> чтобы содержимое этого каталога при установке пакета ложилось в каталог > >> /usr/share/vim/vimfiles ? Это было бы очень удобно для пользователей vim > >> - тогда vim будет автоматически похватывать эти конфигурационные файлы. > > > Содержимое contrib/ ни коим образом не поддерживается > > разработчиками, и ставить это в рамках пакетов, IMHO, было бы странно. > > Странно, что не поддерживается, ведь файл contrib/vim/syntax/nginx.vim > можно автоматически проверять на актуальность небольшим скриптом, > который сканирует исходники nginx и показывает, какие директивы > отсутствуют в файле nginx.vim, такой скрипт пишется за 15 минут. Это, скажем так, не совсем соответствует действительности. Потому что директивы стандартных модулей - не единственное содержимое contrib/vim/, и уж тем более contrib/. Но даже если бы это было так - это не отменяет того факта, что содержимое contrib/ не поддерживается разработчиками. Никто, впрочем, не мешает присылать нам патчи, мы их без проблем принимаем. > Если ставить содержимое contrib/vim в /usr/share/vim/vimfiles/ > с помощью официального пакета из репозитория nginx нельзя, > то каким тогда способом нам актуализировать конфиги vim? Как по мне, наиболее правильным решением было бы добавить соответствующий syntax-файл в дистрибутив собственно vim'а, и там его периодически обновлять. > Актуализировать contrib/vim на всех серверах вручную - это monkey job, > мне пока что приходит в голову идея автоматизировать это через cron: > > /etc/cron.daily/nginx-vim > > #!/bin/bash > > /usr/bin/curl --silent http://hg.nginx.org/nginx/archive/tip.tar.gz > --output /tmp/nginx.tar.gz > /usr/bin/tar -C /tmp -xf /tmp/nginx.tar.gz > for top in /tmp/nginx-* ; do /usr/bin/cp -r $top/contrib/vim/* > /usr/share/vim/vimfiles/ ; done > /usr/bin/rm -rf /tmp/nginx-* > /usr/bin/rm -f /tmp/nginx.tar.gz > > Так нормально будет? Сайт http://hg.nginx.org/ выдержит нагрузку, > если этот скрипт я пропишу в cron на примерно 50 своих серверах? Качать ежедневно динамически генерируемый полный tar всех исходников для обновления четырёх файлов, которые меняются хорошо если пару раз в год - довольно странное решение. Но если очень хочется делать именно так, а системы централизованного управления конфигурацией серверов за столько лет не построили - то тут мы, вероятно, в любом случае ничем помочь не сможем. -- Maxim Dounin http://mdounin.ru/ From root на dl.sm.ua Wed Dec 27 07:05:21 2017 From: root на dl.sm.ua (Dmytro Lavryk) Date: Wed, 27 Dec 2017 09:05:21 +0200 Subject: =?UTF-8?B?TkdJTlgg0L/RgNC+0YHRgtC+INC90LUg0L/RgNC40L3QuNC80LDQtdGCINC60LA=?= =?UTF-8?B?0LrQvtC5LdGC0L4g0L/RgNC+0YbQtdC90YIg0LrQvtC90L3QtdC60YLQvtCy?= Message-ID: <16096ca315a.10f388d21114637.3629651249017032466@dl.sm.ua> nginx -V nginx version: nginx/1.12.2 built with OpenSSL 1.0.2n 7 Dec 2017 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-file-aio --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_addition_module --with-http_auth_request_module --with-http_gzip_static_module --with-http_realip_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_v2_module --with-threads --with-http_ssl_module Собран из портов на FreeBSD 10.3-RELEASE-p21 /var/tmp (используемая как временная) есть tmpfs в памяти, но ею практически не пользуются. В основном раздается статика (пару десятков мелких сайтов на WordPress - настроено файловое кеширование страниц) + php-fpm. Нагрузки совсем небольшие. Конфиги применяемые на добром десятке серверов практически без изменений. NGINX, такое ощущение, что просто игнорит какое-то количество коннектов. Для снятия статистики применяется collectd, у него в логах:[2017-12-27 09:52:55] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10002 milliseconds with 0 bytes received [2017-12-27 09:52:55] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. [2017-12-27 09:53:25] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10005 milliseconds with 0 bytes received [2017-12-27 09:53:25] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. [2017-12-27 09:54:15] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10001 milliseconds with 0 bytes received [2017-12-27 09:54:15] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. [2017-12-27 09:54:45] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10002 milliseconds with 0 bytes received [2017-12-27 09:54:45] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. [2017-12-27 09:55:05] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10013 milliseconds with 0 bytes received [2017-12-27 09:55:05] [notice] read-function of plugin `nginx' failed. Will suspend it for 40.000 seconds. Снаружи тоже периодически просто нет никакого ответа. При этом если он и есть - то как-то медленно вроде. При этом система показывает какую-то повышенную нагрузку на файловую систему, и создает ее якобы именно NGINX. Порт пересобирал, с sendfile и aio экспериментировал, error_log в debug ставил - ничего интересного не нашел, в бубен стучал. Подскажите может как точнее продиагностировать проблему. Спасибо! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Wed Dec 27 07:23:09 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 27 Dec 2017 10:23:09 +0300 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <16096ca315a.10f388d21114637.3629651249017032466@dl.sm.ua> References: <16096ca315a.10f388d21114637.3629651249017032466@dl.sm.ua> Message-ID: <20171227072309.GK29615@protva.ru> On Wed, Dec 27, 2017 at 09:05:21AM +0200, Dmytro Lavryk wrote: > NGINX, такое ощущение, что просто игнорит какое-то количество коннектов. Для снятия статистики применяется collectd, у него в логах:[2017-12-27 09:52:55] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10002 milliseconds with 0 bytes received Здесь написано, что в коннекции не приходило никаких данных. > Порт пересобирал, с sendfile и aio экспериментировал, error_log в debug ставил - ничего интересного не нашел, в бубен стучал. В debug-логе видно, что данные присылались? > Подскажите может как точнее продиагностировать проблему. Спасибо! Можно записать дамп трафика и посмотреть, что в действительности передавалось по сети. Если данные приходили, то дальше debug и/или трассировка. -- Eugene Berdnikov From root на dl.sm.ua Wed Dec 27 07:33:29 2017 From: root на dl.sm.ua (Dmytro Lavryk) Date: Wed, 27 Dec 2017 09:33:29 +0200 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <20171227072309.GK29615@protva.ru> References: <16096ca315a.10f388d21114637.3629651249017032466@dl.sm.ua> <20171227072309.GK29615@protva.ru> Message-ID: <16096e3f32c.1027b091f115025.4994852232435775406@dl.sm.ua> ---- On ср, 27 груд. 2017 09:23:09 +0200 Evgeniy Berdnikov <bgx на protva.ru> wrote ---- On Wed, Dec 27, 2017 at 09:05:21AM +0200, Dmytro Lavryk wrote: > NGINX, такое ощущение, что просто игнорит какое-то количество коннектов. Для снятия статистики применяется collectd, у него в логах:[2017-12-27 09:52:55] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10002 milliseconds with 0 bytes received Здесь написано, что в коннекции не приходило никаких данных. > Порт пересобирал, с sendfile и aio экспериментировал, error_log в debug ставил - ничего интересного не нашел, в бубен стучал. В debug-логе видно, что данные присылались? Не совсем понял что должно быть видно. Картина примерно такая: collectd.log [2017-12-27 10:30:15] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10002 milliseconds with 0 bytes received [2017-12-27 10:30:15] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. [2017-12-27 10:30:45] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10008 milliseconds with 0 bytes received [2017-12-27 10:30:45] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. [2017-12-27 10:31:05] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10018 milliseconds with 0 bytes received [2017-12-27 10:31:05] [notice] read-function of plugin `nginx' failed. Will suspend it for 40.000 seconds. [2017-12-27 10:31:55] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10002 milliseconds with 0 bytes received [2017-12-27 10:31:55] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. nginx-error.log 2017/12/27 10:30:47 [info] 9116#101634: *84097 kevent() reported that client 127.0.0.1 closed keepalive connection 2017/12/27 10:31:08 [info] 9114#100581: *88352 kevent() reported that client 127.0.0.1 closed keepalive connection 2017/12/27 10:31:08 [info] 9117#100460: *88694 kevent() reported that client 127.0.0.1 closed keepalive connection 2017/12/27 10:32:04 [info] 9118#100630: *89473 kevent() reported that client 127.0.0.1 closed keepalive connection ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bgx на protva.ru Wed Dec 27 08:24:39 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 27 Dec 2017 11:24:39 +0300 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <16096e3f32c.1027b091f115025.4994852232435775406@dl.sm.ua> References: <16096ca315a.10f388d21114637.3629651249017032466@dl.sm.ua> <20171227072309.GK29615@protva.ru> <16096e3f32c.1027b091f115025.4994852232435775406@dl.sm.ua> Message-ID: <20171227082438.mqj5zcoqi3g4jabf@cio.protva.ru> On Wed, Dec 27, 2017 at 09:33:29AM +0200, Dmytro Lavryk wrote: > Не совсем понял что должно быть видно. Картина примерно такая: В этой картине отметки времени в одном логе не соответствуют отметкам в другом. Дампа трафика нет, привязки его к логам соответственно тоже нет. -- Eugene Berdnikov From nginx-forum на forum.nginx.org Wed Dec 27 08:50:08 2017 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 27 Dec 2017 03:50:08 -0500 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <20171227082438.mqj5zcoqi3g4jabf@cio.protva.ru> References: <20171227082438.mqj5zcoqi3g4jabf@cio.protva.ru> Message-ID: <1613f0aa9391bd5c7e0fbcff7f3e9723.NginxMailingListRussian@forum.nginx.org> Evgeniy Berdnikov Wrote: ------------------------------------------------------- > On Wed, Dec 27, 2017 at 09:33:29AM +0200, Dmytro Lavryk wrote: > > Не совсем понял что должно быть видно. Картина примерно такая: > > В этой картине отметки времени в одном логе не соответствуют > отметкам в другом. Дампа трафика нет, привязки его к логам > соответственно тоже нет. Ну логи как пишет... я же просто выдаю что есть. Дамп трафика (приблизительно за период, снимался - tcpdump -n -i lo0 host 127.0.0.1 and port 80): 11:46:06.582317 IP 127.0.0.1.62479 > 127.0.0.1.80: Flags [.], ack 2332, win 1275, options [nop,nop,TS val 29894005 ecr 1676731409], length 0 11:46:14.812376 IP 127.0.0.1.62479 > 127.0.0.1.80: Flags [P.], seq 810:900, ack 2332, win 1275, options [nop,nop,TS val 29902235 ecr 1676731409], length 90 11:46:14.912304 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [.], ack 900, win 1274, options [nop,nop,TS val 1676739839 ecr 29902235], length 0 11:46:24.830023 IP 127.0.0.1.62479 > 127.0.0.1.80: Flags [F.], seq 900, ack 2332, win 1275, options [nop,nop,TS val 29912252 ecr 1676739839], length 0 11:46:24.830045 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [.], ack 901, win 1274, options [nop,nop,TS val 1676749756 ecr 29912252], length 0 11:46:32.550980 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676757477 ecr 29912252], length 0 11:46:32.850305 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676757777 ecr 29912252], length 0 11:46:33.250304 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676758177 ecr 29912252], length 0 11:46:33.850299 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676758777 ecr 29912252], length 0 11:46:34.816651 IP 127.0.0.1.12192 > 127.0.0.1.80: Flags [S], seq 1646775981, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 29922239 ecr 0], length 0 11:46:34.816662 IP 127.0.0.1.80 > 127.0.0.1.12192: Flags [S.], seq 2348920186, ack 1646775982, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 1134878249 ecr 29922239], length 0 11:46:34.816670 IP 127.0.0.1.12192 > 127.0.0.1.80: Flags [.], ack 1, win 1275, options [nop,nop,TS val 29922239 ecr 1134878249], length 0 11:46:34.816691 IP 127.0.0.1.12192 > 127.0.0.1.80: Flags [P.], seq 1:91, ack 1, win 1275, options [nop,nop,TS val 29922239 ecr 1134878249], length 90 11:46:34.816753 IP 127.0.0.1.80 > 127.0.0.1.12192: Flags [P.], seq 1:260, ack 91, win 1275, options [nop,nop,TS val 1134878249 ecr 29922239], length 259 11:46:34.850308 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676759777 ecr 29912252], length 0 11:46:34.916293 IP 127.0.0.1.12192 > 127.0.0.1.80: Flags [.], ack 260, win 1275, options [nop,nop,TS val 29922339 ecr 1134878249], length 0 11:46:36.650295 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676761577 ecr 29912252], length 0 11:46:37.810296 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676762737 ecr 29912252], length 0 11:46:39.930302 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [F.], seq 2332, ack 901, win 1275, options [nop,nop,TS val 1676764857 ecr 29912252], length 0 Лог collectd: [2017-12-27 11:46:25] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10017 milliseconds with 0 bytes received [2017-12-27 11:46:25] [notice] read-function of plugin `nginx' failed. Will suspend it for 20.000 seconds. Лог nginx: 2017/12/27 11:46:32 [info] 9112#101190: *167765 kevent() reported that client 127.0.0.1 closed keepalive connection Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277903,277907#msg-277907 From nginx-forum на forum.nginx.org Wed Dec 27 09:05:00 2017 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 27 Dec 2017 04:05:00 -0500 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <1613f0aa9391bd5c7e0fbcff7f3e9723.NginxMailingListRussian@forum.nginx.org> References: <20171227082438.mqj5zcoqi3g4jabf@cio.protva.ru> <1613f0aa9391bd5c7e0fbcff7f3e9723.NginxMailingListRussian@forum.nginx.org> Message-ID: <30389795ffce55414b351a3b6be35677.NginxMailingListRussian@forum.nginx.org> Вот еще такое встречается крайне редко в логе nginx ; 2017/12/27 12:02:55 [info] 9116#101634: *202092 setsockopt(TCP_NODELAY) failed (54: Connection reset by peer) while keepalive, client: 127.0.0.1, server: 0.0.0.0:80 При этом: collectd [2017-12-27 12:02:55] [warning] nginx plugin: curl_easy_perform failed: Operation timed out after 10001 milliseconds with 0 bytes received [2017-12-27 12:02:55] [notice] read-function of plugin `nginx' failed. Will suspend it for 80.000 seconds. tcpdump: 12:02:54.813317 IP 127.0.0.1.19117 > 127.0.0.1.80: Flags [F.], seq 91, ack 1, win 1275, options [nop,nop,TS val 30902236 ecr 737003093], length 0 12:02:54.813324 IP 127.0.0.1.80 > 127.0.0.1.19117: Flags [.], ack 92, win 1274, options [nop,nop,TS val 737012990 ecr 30902236], length 0 12:02:55.486115 IP 127.0.0.1.80 > 127.0.0.1.18902: Flags [P.], seq 1:261, ack 92, win 1275, options [nop,nop,TS val 2230401244 ecr 30862237], length 260 12:02:55.757720 IP 127.0.0.1.80 > 127.0.0.1.18902: Flags [F.], seq 261, ack 92, win 1275, options [nop,nop,TS val 2230401516 ecr 30862237], length 0 12:02:55.810233 IP 127.0.0.1.80 > 127.0.0.1.18902: Flags [FP.], seq 1:261, ack 92, win 1275, options [nop,nop,TS val 2230401569 ecr 30862237], length 260 12:02:55.844458 IP 127.0.0.1.80 > 127.0.0.1.19117: Flags [P.], seq 1:260, ack 92, win 1275, options [nop,nop,TS val 737014021 ecr 30902236], length 259 12:02:55.844471 IP 127.0.0.1.19117 > 127.0.0.1.80: Flags [R], seq 1783156127, win 0, length 0 12:02:56.258235 IP 127.0.0.1.80 > 127.0.0.1.18902: Flags [FP.], seq 1:261, ack 92, win 1275, options [nop,nop,TS val 2230402017 ecr 30862237], length 260 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277903,277908#msg-277908 From bgx на protva.ru Wed Dec 27 10:39:42 2017 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 27 Dec 2017 13:39:42 +0300 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <1613f0aa9391bd5c7e0fbcff7f3e9723.NginxMailingListRussian@forum.nginx.org> References: <20171227082438.mqj5zcoqi3g4jabf@cio.protva.ru> <1613f0aa9391bd5c7e0fbcff7f3e9723.NginxMailingListRussian@forum.nginx.org> Message-ID: <20171227103942.xvpftccalftukycx@cio.protva.ru> Здесь написано, что в 11:46:14 от клиента серверу на порту 80 было передано 90 байт: On Wed, Dec 27, 2017 at 03:50:08AM -0500, Dmytro Lavryk wrote: > 11:46:14.812376 IP 127.0.0.1.62479 > 127.0.0.1.80: Flags [P.], seq 810:900, > ack 2332, win 1275, options [nop,nop,TS val 29902235 ecr 1676731409], length > 90 > 11:46:14.912304 IP 127.0.0.1.80 > 127.0.0.1.62479: Flags [.], ack 900, win > 1274, options [nop,nop,TS val 1676739839 ecr 29902235], length 0 В ответ ничего. А через 10 сек, в 11:46:24 клиент закрывает соединение: > 11:46:24.830023 IP 127.0.0.1.62479 > 127.0.0.1.80: Flags [F.], seq 900, ack > 2332, win 1275, options [nop,nop,TS val 29912252 ecr 1676739839], length 0 Вам должно быть известно, с какой стороны какой процесс и кто кому должен был ответить. Подозреваю, на сервере сидит тот самый плагин, который получил данные, но не увидел их. Трассировка покажет почему. Может быть, там ошибочный файловый дескриптор в poll отдан, или вообще никакие дескрипторы не мониторятся... -- Eugene Berdnikov From nginx-forum на forum.nginx.org Wed Dec 27 11:43:43 2017 From: nginx-forum на forum.nginx.org (Dmytro Lavryk) Date: Wed, 27 Dec 2017 06:43:43 -0500 Subject: =?UTF-8?B?UmU6IE5HSU5YINC/0YDQvtGB0YLQviDQvdC1INC/0YDQuNC90LjQvNCw0LXRgiA=?= =?UTF-8?B?0LrQsNC60L7QuS3RgtC+INC/0YDQvtGG0LXQvdGCINC60L7QvdC90LXQutGC?= =?UTF-8?B?0L7Qsg==?= In-Reply-To: <20171227103942.xvpftccalftukycx@cio.protva.ru> References: <20171227103942.xvpftccalftukycx@cio.protva.ru> Message-ID: > Вам должно быть известно, с какой стороны какой процесс и кто кому > должен был ответить. Подозреваю, на сервере сидит тот самый плагин, > который получил данные, но не увидел их. Трассировка покажет почему. > Может быть, там ошибочный файловый дескриптор в poll отдан, или > вообще никакие дескрипторы не мониторятся... Ну вот и получается, что NGINX ничего не ответил, встречает там простейший конфиг отдающий статистику: server { server_name localhost; listen 80; if ($host !~ ^(localhost)$ ) { return 444; } location /nginx_stat { allow 127.0.0.1; deny all; stub_status on; access_log /var/log/nginx/localhost-access.log; error_log /var/log/nginx/localhost-error.log debug; } } Но такая ситуация не только с этим вирт. хостом, а и с остальными - время от времени они ничего не отдают. На счет трассировки не понял :( Подскажите как сделать или ткните ссылкой где почитать, пожалуйста. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277903,277911#msg-277911 From postmaster на softsearch.ru Wed Dec 27 17:56:44 2017 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Wed, 27 Dec 2017 20:56:44 +0300 Subject: https://www.nginx.com/blog/performance-tuning-tips-tricks/ In-Reply-To: <1780105.dB2ezUBPzd@vbart-workstation> References: <675aacb9-b2e3-1e66-0d5c-6c8f44b276da@csdoc.com> <1780105.dB2ezUBPzd@vbart-workstation> Message-ID: <1615855595.20171227205644@softsearch.ru> Здравствуйте, Валентин. > Будут приняты меры чтобы этого больше не повторялось. Хорошо бы ещё спам в листе победить. С уважением, Михаил mailto:postmaster на softsearch.ru From vbart на nginx.com Fri Dec 29 17:55:28 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 29 Dec 2017 20:55:28 +0300 Subject: unit-0.3 beta Message-ID: <52228638.usRhnYsIYr@vbart-laptop> Привет, Рад сообщить о выпуске новой бета-версии NGINX Unit. Изменения в Unit 0.3 28 Dec 2017 *) Изменение: пакет Go переименован в "nginx/unit". *) Изменение: параметр "limits.timeout" теперь не учитывает времени старта приложения и ожидания в очереди. *) Добавление: параметр "limits.requests". *) Добавление: оптимизация задержек в обработке запросов приложениями. *) Добавление: поддержка HTTP keep-alive. *) Добавление: параметр "home" для поддержки виртуальных окружений в Python. *) Добавление: поддержка atexit в Python. *) Добавление: различные улучшения в пакете Go. *) Исправление: ряда ошибок, приводивших к segmentation fault. Начиная с данной версии мы собираем пакеты для бо́льшего числа Linux систем: - https://unit.nginx.org/installation/#precompiled-packages Также в блоге появилась статья о некоторых наших ближайших планах: - https://www.nginx.com/blog/nginx-unit-progress-and-next-steps/ Следите за обновлениями и, конечно же, всех с наступающим Новым Годом! -- Валентин Бартенев From vbart на nginx.com Fri Dec 29 18:13:08 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Fri, 29 Dec 2017 21:13:08 +0300 Subject: unit-0.2 beta release In-Reply-To: <3168245.Kz2peocWcp@vbart-laptop> References: <1963541.sZcXvGPr6j@cybernote> <3168245.Kz2peocWcp@vbart-laptop> Message-ID: <1946332.fvPcaAcxi6@vbart-laptop> On Saturday, 16 December 2017 16:05:22 MSK Валентин Бартенев wrote: > On Friday, 15 December 2017 21:53:57 MSK Иван wrote: > > Прекрасная новость! > > > > А пакеты для debian9? А когда планируется релиз? > > > [..] > > Пакеты для Debian надеюсь сделаем до конца года. > Релиз запланирован на второй квартал 2018. > Как и обещал, пакеты для Debian: https://unit.nginx.org/installation/#debian-packages -- Валентин Бартенев From nginx-forum на forum.nginx.org Fri Dec 29 22:52:52 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 29 Dec 2017 17:52:52 -0500 Subject: unit-0.3 beta In-Reply-To: <52228638.usRhnYsIYr@vbart-laptop> References: <52228638.usRhnYsIYr@vbart-laptop> Message-ID: <8bcbed5c797a65e04dccb4b0b3ffe710.NginxMailingListRussian@forum.nginx.org> Всех с наступающим НГ. Много раз себя ловил на мысли когда смотрел на JSON конфиг Unit, почему вы решили сервисы называть application? Я понимаю что NGINX Unit - это Application Server, но уже устоялись такие понятия как microservice, которые часто настраиваются как отдельные Unit для systemd.service + systemd.socket, там application называются service. Это конечно не критично, но согласитесь что будет всем удобно использовать одну терминологию. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277933,277942#msg-277942 From vbart на nginx.com Fri Dec 29 23:33:59 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 30 Dec 2017 02:33:59 +0300 Subject: unit-0.3 beta In-Reply-To: <8bcbed5c797a65e04dccb4b0b3ffe710.NginxMailingListRussian@forum.nginx.org> References: <52228638.usRhnYsIYr@vbart-laptop> <8bcbed5c797a65e04dccb4b0b3ffe710.NginxMailingListRussian@forum.nginx.org> Message-ID: <12118805.WT731teryX@vbart-laptop> On Saturday, 30 December 2017 01:52:52 MSK S.A.N wrote: > Всех с наступающим НГ. > > Много раз себя ловил на мысли когда смотрел на JSON конфиг Unit, почему вы > решили сервисы называть application? > > Я понимаю что NGINX Unit - это Application Server, но уже устоялись такие > понятия как microservice, которые часто настраиваются как отдельные Unit для > systemd.service + systemd.socket, там application называются service. > > Это конечно не критично, но согласитесь что будет всем удобно использовать > одну терминологию. > Как по вашему, firefox - это сервис или приложение? Можете обосновать почему? -- Валентин Бартенев From nginx-forum на forum.nginx.org Sat Dec 30 01:43:31 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Fri, 29 Dec 2017 20:43:31 -0500 Subject: unit-0.3 beta In-Reply-To: <12118805.WT731teryX@vbart-laptop> References: <12118805.WT731teryX@vbart-laptop> Message-ID: <7ff6216b2e4bb1ca91ca1356d4ef1724.NginxMailingListRussian@forum.nginx.org> > Как по вашему, firefox - это сервис или приложение? Можете обосновать > почему? Я же не ради холивара это писал :) Клиентские GUI приложения сервисами сложно назвать, но для меня: PHP-FPM - это сервис Node.js - это сервис Python WSGI - это сервис Go Server - это сервис Возможно у меня systemd головного мозга, но в вашем конфиге, раздел "listeners" я понимаю как директивы для systemd.socket и соответственно "applications" у меня ассоциируется с директивами для systemd.service, мне так проще унифицировать свои знание и ваше название Unit очень помогает сделать связь с unit от systemd. В идеале мне (думаю и многим тоже) будет удобно если все аналогичные директивы из unit.nginx и systemd будут иметь одинаковые название. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277933,277944#msg-277944 From vbart на nginx.com Sat Dec 30 02:55:17 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sat, 30 Dec 2017 05:55:17 +0300 Subject: unit-0.3 beta In-Reply-To: <7ff6216b2e4bb1ca91ca1356d4ef1724.NginxMailingListRussian@forum.nginx.org> References: <12118805.WT731teryX@vbart-laptop> <7ff6216b2e4bb1ca91ca1356d4ef1724.NginxMailingListRussian@forum.nginx.org> Message-ID: <5171373.SfDl833vtV@vbart-laptop> On Saturday, 30 December 2017 04:43:31 MSK S.A.N wrote: > > Как по вашему, firefox - это сервис или приложение? Можете обосновать > > почему? > > Я же не ради холивара это писал :) > Клиентские GUI приложения сервисами сложно назвать, но для меня: > PHP-FPM - это сервис > Node.js - это сервис > Python WSGI - это сервис > Go Server - это сервис И Unit может быть сервисом, а запускает он приложения. =) > > Возможно у меня systemd головного мозга, но в вашем конфиге, раздел > "listeners" я понимаю как директивы для systemd.socket и соответственно > "applications" у меня ассоциируется с директивами для systemd.service, мне > так проще унифицировать свои знание и ваше название Unit очень помогает > сделать связь с unit от systemd. Для меня wordpress.com - это сервис, а WordPress тот, что набор php скриптов - это приложение. И именно настройка интерпретации данного набора скриптов и производится в объекте "applications". Тот же GUI для Firefox отрисовывается с помощью других промежуточных служб, X-сервера, драйвера и т.д., и там даже может учавствовать некий протокол, а всё это может быть физически разнесено по разным машинам. А для WordPress интерфейс рисуется с помощью браузера, того же Firefox. Поэтому всё не так просто и однозначно. Под сервисами, как правило, понимают те приложения, которые выполняют некую служебную, то бишь сервисную функцию для других приложений. Поскольку именно такую функцию чаще всего выполняют системные службы, то и systemd, и многие другие init-системы пользуются данной терминологией. В любом случае сервисное приложение - это тоже приложение. Как утверждает словарь: application - a program or piece of software designed to fulfil a particular purpose. "a database application". Так, например в зависимости от архитектуры, приложение может быть монолитным или микросервисным, с ним может непосредственно взаимодействовать пользователь, а могут другие приложения. Иными словами сервис - это более узкий термин, определяющий выполняемую приложением роль. Возможно он идеально подходит для systemd, но я бы не стал называть большинство веб-приложений сервисами. В Unit-е используется нейтральный термин, не навязывающий определенной роли или архитектуры для приложения. > > В идеале мне (думаю и многим тоже) будет удобно если все аналогичные > директивы из unit.nginx и systemd будут иметь одинаковые название. > О нет, не хотелось бы переизобретать systemd. Пусть systemd и дальше запускает сервисы, а Unit будет заниматься запуском веб-приложений. В любом случае, спасибо вам за идею, я её принял к сведению. Безусловно, конфигурация должна быть интуитивно понятной для пользователей и правильный выбор терминологии крайне важен. Например, в ранних версиях Unit объект "listeners" назывался "sockets", но это вызвало всеобщее неприятие и в итоге он был переименован. В случае же "applications" -> "services" - это первый подобный запрос, а текущая терминология устраивает в том числе американскую часть компании, для которой это родной язык, поэтому вероятность одобрения не велика. -- Валентин Бартенев From nginx-forum на forum.nginx.org Sat Dec 30 10:03:01 2017 From: nginx-forum на forum.nginx.org (S.A.N) Date: Sat, 30 Dec 2017 05:03:01 -0500 Subject: unit-0.3 beta In-Reply-To: <5171373.SfDl833vtV@vbart-laptop> References: <5171373.SfDl833vtV@vbart-laptop> Message-ID: <9251955ce3db739f938e11238187639c.NginxMailingListRussian@forum.nginx.org> > Иными словами сервис - это более узкий термин, определяющий выполняемую приложением роль. > Возможно он идеально подходит для systemd, но я бы не стал называть большинство веб-приложений сервисами. Я абсолютно согласен с этим определением. Но хочу обратить внимание что основная цель Systemd в том чтобы сделать из любого Линукс приложения, работающий Линукс сервис. Возможно я ошибаюсь, но основная цель Nginx.Unit - сделать из любого бекенд приложения, работающий веб-сервис, или нет? Давайте посмотрим что предпологаеться указывать в разделе "applications" "applications": { "blogs": {блог это же веб-сервис}, "wiki": {тоже больше похоже на веб-сервис}, "shopping_cart": {это важный веб-сервис, который можно разбить на микросервисы}, "chat": {100% веб-сервис} } Я как бекенд разработчик мыслю так, я разрабатываю бекенд приложения и мне нужен Nginx.Unit чтобы сделать из моего бекенд приложения, работающий веб сервис. > текущая терминология устраивает в том числе американскую часть компании, для которой это родной язык, поэтому вероятность одобрения не велика. Просто им нужно предложить более короткое название Services, которое более точно отражает основную миссию Nginx.Unit - создавать веб-сервисы из бекенд-приложений. В любом случаи, с наступающим НГ! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,277933,277947#msg-277947 From nginx на kinetiksoft.com Sat Dec 30 11:55:33 2017 From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=) Date: Sat, 30 Dec 2017 14:55:33 +0300 Subject: unit-0.3 beta In-Reply-To: <7ff6216b2e4bb1ca91ca1356d4ef1724.NginxMailingListRussian@forum.nginx.org> References: <12118805.WT731teryX@vbart-laptop> <7ff6216b2e4bb1ca91ca1356d4ef1724.NginxMailingListRussian@forum.nginx.org> Message-ID: <3972512.Vc6omNcFN6@cybernote> Здравствуйте! Я не использую systemd и для меня перечисленное - приложения. Если unit - сервер приложений, то, очевидно, он запускает приложения. С уважением, Иван Прокудин. В письме от суббота, 30 декабря 2017 г. 4:43:31 MSK пользователь S.A.N написал: > > Как по вашему, firefox - это сервис или приложение? Можете обосновать > > почему? > > Я же не ради холивара это писал :) > Клиентские GUI приложения сервисами сложно назвать, но для меня: > PHP-FPM - это сервис > Node.js - это сервис > Python WSGI - это сервис > Go Server - это сервис > > Возможно у меня systemd головного мозга, но в вашем конфиге, раздел > "listeners" я понимаю как директивы для systemd.socket и соответственно > "applications" у меня ассоциируется с директивами для systemd.service, мне > так проще унифицировать свои знание и ваше название Unit очень помогает > сделать связь с unit от systemd. From eugene.toropov на gmail.com Sat Dec 30 19:46:51 2017 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Sat, 30 Dec 2017 22:46:51 +0300 Subject: =?UTF-8?B?UmU6INCw0L/RgdGC0YDQuNC8INGA0LXQttC10YIg0LfQsNC/0YDQvtGB0Ys/?= In-Reply-To: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> References: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> Message-ID: <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> Добрый вечер, Всех с наступающим! Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне? Евгений > On 7 Dec 2017, at 16:25, Eugene Toropov wrote: > > Добрый день, > > Ситуация следующая: > > 1) В error логе куча ошибок вида: > > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx", host: “xxx:8080" > > 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда около 4 секунд? > > Это похоже на то, что апстрим режет запросы rps фильтром? > > Евгений > > From chipitsine на gmail.com Sun Dec 31 06:14:44 2017 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sun, 31 Dec 2017 11:14:44 +0500 Subject: =?UTF-8?B?UmU6INCw0L/RgdGC0YDQuNC8INGA0LXQttC10YIg0LfQsNC/0YDQvtGB0Ys/?= In-Reply-To: <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> References: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> Message-ID: SNI ? Покажите снифер? On Dec 31, 2017 12:47 AM, "Eugene Toropov" wrote: > Добрый вечер, > > Всех с наступающим! > > Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и > вижу > > 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream > prematurely closed connection while reading response header from upstream, > client: 192.168.42.32, server: gta, request: \"POST /wbsapi/ > RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529f > cc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe > 83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \" > https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha= > 42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e > 39c7dadaafaceefd2e59dc4"..., 577 > > то это по-любому проблема апстрима или все-таки есть шанс бага на моей > стороне? > > Евгений > > > On 7 Dec 2017, at 16:25, Eugene Toropov > wrote: > > > > Добрый день, > > > > Ситуация следующая: > > > > 1) В error логе куча ошибок вида: > > > > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely > closed connection while reading response header from upstream, client: > 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx", > host: “xxx:8080" > > > > 2) В access логе соотв запросы имеют код ответа 502 и $request_time > всегда около 4 секунд? > > > > Это похоже на то, что апстрим режет запросы rps фильтром? > > > > Евгений > > > > > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Sun Dec 31 08:11:34 2017 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Sun, 31 Dec 2017 11:11:34 +0300 Subject: =?UTF-8?B?UmU6INCw0L/RgdGC0YDQuNC8INGA0LXQttC10YIg0LfQsNC/0YDQvtGB0Ys/?= In-Reply-To: References: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> Message-ID: <94AB6982-5BF0-4891-BE9D-1A5E5AC2D10B@gmail.com> А можно здесь поподробнее? Я не настолько крут в strace. Евгений > 31 дек. 2017 г., в 9:14, Илья Шипицин написал(а): > > SNI ? Покажите снифер? > >> On Dec 31, 2017 12:47 AM, "Eugene Toropov" wrote: >> Добрый вечер, >> >> Всех с наступающим! >> >> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу >> >> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 >> >> то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне? >> >> Евгений >> >> > On 7 Dec 2017, at 16:25, Eugene Toropov wrote: >> > >> > Добрый день, >> > >> > Ситуация следующая: >> > >> > 1) В error логе куча ошибок вида: >> > >> > 2017/12/07 13:19:32 [error] 44862#0: *11393098096 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: xxx, request: "POST xxx HTTP/1.1", upstream: “xxxx", host: “xxx:8080" >> > >> > 2) В access логе соотв запросы имеют код ответа 502 и $request_time всегда около 4 секунд? >> > >> > Это похоже на то, что апстрим режет запросы rps фильтром? >> > >> > Евгений >> > >> > >> >> _______________________________________________ >> 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 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vbart на nginx.com Sun Dec 31 10:24:34 2017 From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=) Date: Sun, 31 Dec 2017 13:24:34 +0300 Subject: =?UTF-8?B?UmU6INCw0L/RgdGC0YDQuNC8INGA0LXQttC10YIg0LfQsNC/0YDQvtGB0Ys/?= In-Reply-To: <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> References: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> Message-ID: <1851551.RbkFS3eKdI@vbart-laptop> On Saturday, 30 December 2017 22:46:51 MSK Eugene Toropov wrote: > Добрый вечер, > > Всех с наступающим! > > Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу > > 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 > > то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне? > Сообщение в логе указывает на проблему в апстриме. Откуда сомнения? -- Валентин Бартенев From eugene.toropov на gmail.com Sun Dec 31 12:14:03 2017 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Sun, 31 Dec 2017 15:14:03 +0300 Subject: =?UTF-8?B?UmU6INCw0L/RgdGC0YDQuNC8INGA0LXQttC10YIg0LfQsNC/0YDQvtGB0Ys/?= In-Reply-To: <1851551.RbkFS3eKdI@vbart-laptop> References: <3DA19B1F-CDE8-4414-9FBA-EB96879E217E@gmail.com> <0452E7A6-CA00-4B72-A5E9-4F8D041F1A55@gmail.com> <1851551.RbkFS3eKdI@vbart-laptop> Message-ID: <966A8C7F-CB97-4325-A9F1-8140FBE5DAC2@gmail.com> > On 31 Dec 2017, at 13:24, Валентин Бартенев wrote: > > On Saturday, 30 December 2017 22:46:51 MSK Eugene Toropov wrote: >> Добрый вечер, >> >> Всех с наступающим! >> >> Подскажите, пожалуйста, если я strace-ом смотрю что делает nginx воркер и вижу >> >> 38935 write(150, "2017/12/30 19:15:54 [error] 38935#0: *487552235 upstream prematurely closed connection while reading response header from upstream, client: 192.168.42.32, server: gta, request: \"POST /wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc478a8bbe83a4b03488002a19cac4ac78dab2ac86637d4b HTTP/1.1\", upstream: \"https://213.212.78.37:443/wbsapi/RequestListenerServlet?sha=42649b8ba9fed41c1ce788ee35529fcc8ffbf92be440ae2148dcec1e487e39c7dadaafaceefd2e59dc4"..., 577 > Вы видите, что nginx пишет в лог файл. > Никакой ценности это наблюдение не представляет. > > >> >> >> то это по-любому проблема апстрима или все-таки есть шанс бага на моей стороне? >> > > Сообщение в логе указывает на проблему в апстриме. Откуда сомнения? > > -- > Валентин Бартенев > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Понятно, спасибо. Сомнения оттуда, что поддержка апстрима пишет ничего такого не видит на своей стороне. Видимо просто не заглядывают глубоко. Будем с ними разбираться. Еще раз с наступающим и спасибо! Евгений