Pull to refresh

Comments 68

Спасибо большое) Мучался с обновлением nginx на продакшене… Но теперь нормально, вы помогли)
А разве в версии 1.11.5 из mainline нет поддержки http2? Вроде с nginx 1.9.5. работает. Кстати, а зачем вообще его пилить? Скорость?
Chrome с определенного момента перестал поддерживать NPN, и потребовал APLN (Protocol Negotiation extension для TLS), который поддерживается в более свежем openssl.

Вопрос не в nginx, а в openssl, с которым он собирается.
Извиняюсь, неправильно понял вопрос. Судя по чейнджлогам, он там уже есть.
UFO just landed and posted this here
Вы правы, только я бы уточнил — nginx собирается на базе версии openssl, входящей в репозиторий.

Комментарием выше в общем то я также, как и Вы, указал на openssl.
UFO just landed and posted this here
Насколько я знаю, openssl нужен для nginx в момент сборки в виде исходных кодов (статическая линковка). Так что тут вопрос больше организационный для мэйнтейнеров дистрибутива, никто не мешает Вам взять уже собранный с нужной версией openssl пакет nginx и установить его у себя в системе.

Я так и сделал на Debian Jessie:)

Не стоит эти патчи от CloudFlare использовать. Почему не стоит я давал подробное разъяснение у нас в багтрекере: http://trac.nginx.org/nginx/ticket/1029#comment:2


Появление этих патчей было актом самопиара CloudFlare, а не попыткой сделать что-то полезное для общества.

Если посмотреть в код скрипта, можно увидеть, что используются переделанные патчи. Можно посмотреть, что делают они, возможно, эти патчи лучше.

Нет, они такие же. Правки там сделаны только для того, чтобы оно собиралось правильно с новыми версиями.

я не сильно понял зачем он вам:
checkinstall
Installing with make install...

========================= Installation results ===========================
make -f objs/Makefile install
make[1]: Entering directory '/opt/nginx-1.11.5'
test -d '/etc/nginx' || mkdir -p '/etc/nginx'
test -d '/usr/sbin' \
	|| mkdir -p '/usr/sbin'
test ! -f '/usr/sbin/nginx' \
	|| mv '/usr/sbin/nginx' \
		'/usr/sbin/nginx.old'
cp objs/nginx '/usr/sbin/nginx'
test -d '/etc/nginx' \
	|| mkdir -p '/etc/nginx'
cp conf/koi-win '/etc/nginx'
cp conf/koi-utf '/etc/nginx'
cp conf/win-utf '/etc/nginx'
test -f '/etc/nginx/mime.types' \
	|| cp conf/mime.types '/etc/nginx'
cp conf/mime.types '/etc/nginx/mime.types.default'
test -f '/etc/nginx/fastcgi_params' \
	|| cp conf/fastcgi_params '/etc/nginx'
cp conf/fastcgi_params \
	'/etc/nginx/fastcgi_params.default'
test -f '/etc/nginx/fastcgi.conf' \
	|| cp conf/fastcgi.conf '/etc/nginx'
cp conf/fastcgi.conf '/etc/nginx/fastcgi.conf.default'
test -f '/etc/nginx/uwsgi_params' \
	|| cp conf/uwsgi_params '/etc/nginx'
cp conf/uwsgi_params \
	'/etc/nginx/uwsgi_params.default'
test -f '/etc/nginx/scgi_params' \
	|| cp conf/scgi_params '/etc/nginx'
cp conf/scgi_params \
	'/etc/nginx/scgi_params.default'
test -f '/etc/nginx/nginx.conf' \
	|| cp conf/nginx.conf '/etc/nginx/nginx.conf'
cp conf/nginx.conf '/etc/nginx/nginx.conf.default'
test -d '/var/run' \
	|| mkdir -p '/var/run'
test -d '/var/log/nginx' \
	|| mkdir -p '/var/log/nginx'
test -d '/etc/nginx/html' \
	|| cp -R html '/etc/nginx'
test -d '/var/log/nginx' \
	|| mkdir -p '/var/log/nginx'
make[1]: Leaving directory '/opt/nginx-1.11.5'

======================== Installation successful ==========================

Copying files to the temporary directory...OK

Stripping ELF binaries and libraries...OK

Compressing man pages...OK

Building file list...OK

Building Debian package...OK

Installing Debian package...OK

Erasing temporary files...OK

Writing backup package...OK
OK

Deleting temp dir...OK


**********************************************************************

 Done. The new package has been installed and saved to

 /opt/nginx-1.11.5/nginx_1.11.5-1_amd64.deb

 You can remove it from your system anytime using: 

      dpkg -r nginx

**********************************************************************

Ну, спасибо, добавил альтернативный вариант в статью)
На Убунте как-то сразу завелось из пакетов. А вот подружить haproxy и nginx не получилось пока, так что откатились на 1.1
Это скорее всего по-этому:
OS and openssl versions
image
А что именно не работает с haproxy? С обработкой POST не связано?
Вообще в связке haproxy(http2+https-endpoint)+nginx(http2) не передаётся много информации о запросе на nginx. На стороне nginx не реально воссоздать GET запрос и реальный IP-адрес клиента (какие данные точно не передаются сейчас не скажу). С телом POST и т. п. запросов проблем как раз не заметил.

Всё должно работать без проблем, если правильно настроить. Реальный IP передается через proxy protocol.

Вот именно с proxy protocol и проблема. В первой версии инфы передаётся мало, на бэкенде не получается восстановить запрос полностью, а вторую nginx (ещё?) не поддерживает. Повторюсь, точно уже не помню, что именно не передаётся, но нам нужен был полный uri (со схемой и портом) и ip-адрес клиента. Что-то из этого по не смогли получить, убедились, что по спекам proxy protocol v1 и не должны, что v2 не поддерживается nginx и откатились.
Он не передаётся как единая сущность даже в HTTP1.0, но в рамках HTTP > 1.0 его (без хэш-части, конечно) можно восстановить на стороне сервера (в HTTP 1.0 нет HOST и восстановить нельзя). В случае proxy protocol v1 на проксируемый сервер проксирующий не передаёт информации о том SSL-соединение открыл клиент или нет, не говоря о деталях этого соединения типа CN клиента.

SSL или не SSL, а также детали соединения — не являются частью URI.


Типичный HTTP/1.1-запрос выглядит так:


GET /blog HTTP/1.1
Host: example.com
User-Agent: Mozilla...
Accept: text/html

и он так выглядит вне зависимости от того, по SSL/TLS он сделан или поверх голого TCP.


URI в данном случае /blog. POST-запросы с этой точки зрения выглядят точно также, только еще содержат тело. Так что ваша фраза:


На стороне nginx не реально воссоздать GET запрос и реальный IP-адрес клиента (какие данные точно не передаются сейчас не скажу). С телом POST и т. п. запросов проблем как раз не заметил

вообще лишена смысла.

Если вам обязательно знать, используется ли SSL/TLS или нет на соединении с клиентом с haproxy, так разнесите также эти соединения по разным портам. Пусть haproxy проксирует либо на один порт, либо на другой. В чем проблема?

Либо можно выкинуть haproxy, поставить nginx на его место — и тогда будет счастье. Всю информацию можно будет передавать в заголовках.
Я говорю про URI по которому идёт запрос, а не который содержится в нём. В общем случае URI выглядит так: scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]. Так вот, в связке haproxy+nginx при использовании proxy protocol v1 (а v2 nginx не поддерживает) теряется информация минимум о схеме (кроме очевидного о фрагменте).

Проблема в том, это сильно усложнит настройку, нужно будет в конфиги haproxy передавать не просто пару хост: порт, и даже не несколько таких пар, а тройку хост: порт: схема и прописывать в разные места конфига для разных схем. Ну и выкинуть haproxy нельзя — корпстандарт.

Docker в nginx:
docker run nginx


и никаких комплиляций

И не заработает.
root@b1263efe36ca:/# nginx -v
nginx version: nginx/1.11.5
root@b1263efe36ca:/# openssl 
OpenSSL> version
OpenSSL 1.0.1t  3 May 2016
OpenSSL> 

Забавно наблюдать старательно сконфигурированный A+ в ssllabs и дырку в безопасности в виде:


resolver 8.8.4.4 8.8.8.8;
UFO just landed and posted this here

Процитирую документацию:

Для предотвращения DNS-спуфинга рекомендуется использовать DNS-серверы в защищённой доверенной локальной сети.
Встроенный резолвер заточен на производительность, для чего пришлось несколько пожертвовать безопасностью. Он не рассчитан на применение в незащищенных сетях. Не говоря уж о том, что задержка при обращении к гугловому серверу может сказаться на скорости обработки запроса, а его недоступность или неправильная работа и вовсе привести к недоступности вашего сервиса.

И как это обходится? В смысле, как правильно?

Правильно использовать собственный DNS-сервер. Например, установленный на той же машине:

resolver 127.0.0.1;

благодарю! всегда считал, что dns в той или иной степени глобальны, теперь появился повод пересмотреть свои взгляды)
Как проверить его работоспособность?
Цитирую VBart:
nslookup example.org 127.0.0.1

или
dig example.org @127.0.0.1

Спасибо. Логично. А резолвить что именно нужно? У меня на 192.168.100.1 на Mikrotik висит DNS кэширующий.
попробуй
$ cat /etc/resolv.conf 
nameserver some.ip

а потом через тот ip любой реальный домен проверь.
Да, вроде нормально работает. Как раз Микротик отвечает. Второй ответ уже за 1 мс прилетает из-за кэширования.

P.S. Блин, обидно что второй раз в карму плюс бросить не могу) Видимо сделал это еще раньше) Спасибо еще раз.
Кстати, openssl 1.0.2 можно было тоже из debian-backports установить.
И еще вопрос. А certbot теперь делает service nginx reload, после обновления сертификата? А то через 3 месяца может ждать сюрприз. 100% раньше не делал и в кроне приходилось дописывать эту строчку.
Не подскажете, как их использовать конкретно в этом случае?
О, не знал, про хуки, спасибо.
Останавливать и стартовать слишком жестко. Достаточно будет reload.
сам крон нет, только что глянул
certbot
$ cat /etc/cron.d/certbot 
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Что дописывали, не подскажете?
мне кажется вам хватит дописать
&& /etc/init.d/nginx reload
Да, в конце добавить:
&& service nginx reload
или
&& systemctl reload nginx

Если есть еще какие-то сервисы, которые используют сертификат (я, например, помнится, забыл про вебсокеты на nodejs), то их тоже надо релоуднуть.
Странно, почему в статье даже не сочли нужным объяснить поведение Chrome — чтобы в нём работал HTTP/2, nginx должен быть собран с версией openssl, которая поддерживает ALPN. А произошло это по причине отказа Chrome от поддержки NPN.

Даже статья на Хабре уже была полгода назад конкретно про эту особенность… Если дублируете, то хотя бы пишите полностью причины.
В начале статьи указано, что беда в отказе Chrome от SPDY и NPN.
Спасибо за указание и мой первый минус:) Но я настойчив — стоило бы по подробнее описывать, прочитал всю статью, а это упустил.
Согласен, но у меня была немного другая цель) Но для вашего успокоения добавил пост от хромиум с обьяснениями.
з.ы. минус не от меня.
UFO just landed and posted this here
Для Ubuntu по хорошему стоило бы делать что-то такое:

apt-get source nginx
dpkg build-package -b
dpkg -i our-built-package.deb
apt-mark hold our-built-package


Сам развлекался тем что собирал nginx + ngx_pagespeed + ngx_brotli :)
Чем закончились эксперименты с ngx_pagespeed?
Завелось, работает, используем:)
пример можно посмотреть на https://escapeteams.ru — позаходить под разными браузерами и посмотреть что он подставляет вместо картинок и стилей.
в целом довольно прикольно, единственное — есть некоторые сложности с кэшем, иногда проблемы с его инвалидацией при деплое новой версии. Но впринципе решается rm -rf /tmp/ngx_pagespeed && /etc/init.d/nginx restart :).
Вот да, проблему с кешем тоже обнаружил.
Но когда я сравнил нагрузку на проц (через apache benchmark) с включенным pagespeed и выключенным, то прям как-то призадумался.
Я еще тогда экспериментировал с Google PageSpeed Insights и пытался понять, на сколько вообще возможно получить там 100 в скорости для мобил. Самое интересное, что даже на выделенном сервере, с одним сайтом, который в разработке, Google PageSpeed Insights часто ругался на то, что время ответа больше 0.2с. Кстати, у вас такая же проблема иногда появляется.

100 баллов легкой кровью так и не получилось получить из-за ошибки:
Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы
+ ошибок на малое время кеширование сторонних скриптов (яндекс метрика, фейсбук и т.д.)

Не то, что бы я считал Google PageSpeed Insights эталонным измерителем производительности.
У нас вообще адская схема — этот nginx проксирует всё на другой хост(хорошо хотя бы в том же регионе.), где крутится IIS+ASP.NET приложение, а это еще и сетевой лаг.

Но в целом с точки зрения открытия сайта — на мой взгляд стало лучше. Всё-таки ngx_pagespeed делает всякие полезные вещи типа минификации/конвертации картинок под конкретные браузеры и прочее, это точно не то, о чем хотелось бы постоянно думать :).

Меня тоже долго останавливало перенос js в днище сайта, но оказалась проблема больше психологическая чем технологическая — большая часть завелась практически без проблем.
UFO just landed and posted this here
Согласен на все 100%
Никогда не делайте make install на debian подобных дистрибутивах, вы потом заколебетесь вычищать систему от разного рода говна.

Все гораздо проще:

mkdir /opt/nginx && cd /opt/nginx
wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz && tar -vzxf openssl-1.0.2j.tar.gz && rm openssl-1.0.2j.tar.gz
apt-get source nginx && apt-get build-dep nginx
cd nginx-1.11.5

Открываем файл debian/rules
в секцию config.status.nginx: config.env.nginx в параметр CFLAGS=
после --with-stream_ssl_preread_module
добавляем --with-openssl=/opt/nginx/openssl-1.0.2j
в секцию config.status.nginx_debug: config.env.nginx_debug в параметр CFLAGS=
после --with-stream_ssl_preread_module
добавляем --with-openssl=/opt/nginx/openssl-1.0.2j

Собираем nginx и модули:
dpkg-buildpackage -b

Устанавливаем nginx:
dpkg -i nginx_1.11.5-1~jessie_amd64.deb

Profit.
В принципе, информация не нова, но автору спасибо. Нужно периодически напоминать сообществу о том, что в вебе уже вовсю шагает HTTP/2. На всех своих проектах включил его больше года назад, с выходом нового Chrome пришлось перекомпилировать новый nginx.
Спасибо за статью, добавил поддержку http2 к своим сайтам. Правда не стал собирать nginx из исходников, ограничился установкой пакета из репозитория nginx (версия 1.11.5 для ubuntu)
Кто-нибудь знает, openresty (NGINX + lua + modules) решает проблему?
В конфиге правильной сборки много мусорных ключей "--with-http_dav_module --with-http_flv_module -with-mail --with-mail_ssl_module". Зачем они нужны, если в Вашей текущей конфигурации не используются?
я брал ключи из debian/rule, кому и что нужно — я не знаю, да и это ведь просто пример. Думаю, при целевом применении данной статьи, люди выбросят все ненужное)
Debian jessie: подключаем debian-backports, ставим оттуда nginx-full и openssl (вместо ветки из main либо собственного репозитория nginx).

Получаем:
nginx version: nginx/1.9.10
built with OpenSSL 1.0.2j 26 Sep 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads --add-module=/build/nginx-1.9.10/debian/modules/nginx-auth-pam --add-module=/build/nginx-1.9.10/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-1.9.10/debian/modules/nginx-echo --add-module=/build/nginx-1.9.10/debian/modules/nginx-upstream-fair --add-module=/build/nginx-1.9.10/debian/modules/ngx_http_substitutions_filter_module

SPDY индикатор в google chrome после этих процедур становится вполне себе синеньким, и рассказывает нам про HTTP/2 enabled.

Как использовать backports (если кто не знает) — написано в Debian wiki
Sign up to leave a comment.

Articles