Re: nginx.service start operation timed out. Terminating.

2019-08-14 Пенетрантность Илья Шипицин
ср, 14 авг. 2019 г. в 23:22, Evgeniy Berdnikov :

> On Wed, Aug 14, 2019 at 08:02:53PM +0300, Gena Makhomed wrote:
> > Разве есть возможность системный резолвер научить понимать что нет
> > интернета, если IP адрес сконфигурирован статически на CentOS 7.6?
> > Как это можно сделать? (Подозреваю что такой возможности нет и не будет)
>
>  Не надо так делать. Типичный шаблон для построения HA-кластера:
>  у каждого узла свой собственный ip-адрес, по которому узел всегда
>  доступен из сети, и есть переходящий ip-адрес, служащий для доступа
>  клиентов к сервису. Переходящий ip-шник поднимает у себя узел,
>  принимающий роль мастера, а слейв его освобождает.
>

необязательно мастер-слейв.

можно и мастер-мастер: https://github.com/Exa-Networks/exabgp

(похожую схему используем, просто у ExaBGP документация наглядная)



>
>  Это самый простой вариант, есть масса вариаций. Например, сеть можно
>  построить так, что все узлы кластера будут выходить в интернет через
>  один белый ip-адрес (с nat-ом, разумеется), поэтому перенаправление
>  входящих соединений на один из узлов кластера (мастер) никак не будет
>  ограничивать исходящие, в том числе для слейва.
> --
>  Eugene Berdnikov
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx.service start operation timed out. Terminating.

2019-08-14 Пенетрантность Evgeniy Berdnikov
On Wed, Aug 14, 2019 at 08:02:53PM +0300, Gena Makhomed wrote:
> Разве есть возможность системный резолвер научить понимать что нет
> интернета, если IP адрес сконфигурирован статически на CentOS 7.6?
> Как это можно сделать? (Подозреваю что такой возможности нет и не будет)

 Не надо так делать. Типичный шаблон для построения HA-кластера:
 у каждого узла свой собственный ip-адрес, по которому узел всегда
 доступен из сети, и есть переходящий ip-адрес, служащий для доступа
 клиентов к сервису. Переходящий ip-шник поднимает у себя узел,
 принимающий роль мастера, а слейв его освобождает.

 Это самый простой вариант, есть масса вариаций. Например, сеть можно
 построить так, что все узлы кластера будут выходить в интернет через
 один белый ip-адрес (с nat-ом, разумеется), поэтому перенаправление
 входящих соединений на один из узлов кластера (мастер) никак не будет
 ограничивать исходящие, в том числе для слейва.
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx error_page 200

2019-08-14 Пенетрантность Evgeniy Berdnikov
On Thu, Aug 15, 2019 at 12:48:56AM +0800, Alexander Titaev wrote:
> у  клиента  nginx  проксирует запросы на tomcat. tomcat должен возвращать 301 
> с хитрым url, но у него регулярно затекает
> мозг   и   он   периодически  начинает  возвращать 200. Помогает рестарт. 
> Клиент просит временно, пока они разбираются с
> явой, сделать  перехват  этих 200 с преобразованием в 301, подобного тому что 
> делает tomcat, но по упрощенной схеме. Вот
> никак не соображу как этот перехват сделать. Возможно-ли это в принципе?

 Приложение отдаёт 200 с правильным содержимым Location: в заголовке?
 Без nginx: пропустите его выдачу через netsed ... "s/200 /301 /".
-- 
 Eugene Berdnikov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx.service start operation timed out. Terminating.

2019-08-14 Пенетрантность Gena Makhomed

On 14.08.2019 18:01, Maxim Dounin wrote:


Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not
found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the
certificate "/etc/letsencrypt/live/example.com/fullchain.pem"
Aug 14 16:23:03 vm systemd: nginx.service start operation timed out.
Terminating.
Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web
server.
Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state.
Aug 14 16:23:03 vm systemd: nginx.service failed.

Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы
он нормально запускался и работал на втором узле кластера даже в том
случае, когда Failover IP указывает на первый физический сервер и
виртуальная машина, запускаемая на втором физическом сервере не имеет
доступа в интернет?



Нужно либо убрать из из конфигурации всё, что требует резолвинга
имён, и соответственно требует доступа в интернет, либо сделать
этот резолвинг возможным (добавив соответствующие имена в
/etc/hosts или обеспечив работу DNS).

Включённый OCSP stapling - пытается резолвить имена OCSP-серверов
из сертификатов на старте.  Он, при этом, умеет автоматически
выключаться, если разрезолвить имя не удаётся, но, судя по всему,
сертификатов больше одного, а системный резолвер про отсутствие
интернета не в курсе и тупо ждёт таймаутов, так что случается уже
таймаут на запуск nginx'а в systemd.


Да, Вы правы, сертификатов больше одного.
Выключил ssl_stapling - теперь все запускается и работает нормально.
Спасибо!

Разве есть возможность системный резолвер научить понимать что нет 
интернета, если IP адрес сконфигурирован статически на CentOS 7.6?

Как это можно сделать? (Подозреваю что такой возможности нет и не будет)

Может быть можно научить nginx не использовать системный резолвер
при старте для резолвинга имен хостов OCSP responder'ов
из загружаемых им SSL сертификатов?

Не понятно, зачем nginx это делает, если в конфиге указана директива
resolver и наличие ответа от OCSP responder не является необходимым
для нормального запуска и последующей нормальной работы веб-сервера.

Может лучше было бы резолвить имена OCSP-серверов из сертификатов
не при старте а в момент первого запроса к серверу, или делать
автоматический preload ответов OCSP-серверов уже после того,
как nginx будет полностью сконфигурирован и запущен?

Потому что сейчас без интернета или при сбоях в работе системного
резолвера при включенном в конфиге OCSP stapling - nginx вообще
не запускается и это самым катастрофическим образом сказывается
на надежности работы сервера - запуск nginx завершается ошибкой
и все сайты становятся нерабочими. Это хуже чем OCSP Must-Staple.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx error_page 200

2019-08-14 Пенетрантность Alexander Titaev
Здравствуйте, Nginx-ru.

у  клиента  nginx  проксирует запросы на tomcat. tomcat должен возвращать 301 с 
хитрым url, но у него регулярно затекает
мозг   и   он   периодически  начинает  возвращать 200. Помогает рестарт. 
Клиент просит временно, пока они разбираются с
явой, сделать  перехват  этих 200 с преобразованием в 301, подобного тому что 
делает tomcat, но по упрощенной схеме. Вот
никак не соображу как этот перехват сделать. Возможно-ли это в принципе?

-- 
С уважением,
 Alexander  mailto:t...@irk.ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx.service start operation timed out. Terminating.

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 05:17:25PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Столкнулся с проблемой
> 
> nginx.service start operation timed out. Terminating.

[...]

> Failover IP привязан к первому физическому серверу,
> поэтому если запустить эту же виртуальную машину на втором
> физическом сервере - у нее не будет доступа в интернет.
> 
> тем не менее, виртуальная машина нормально стартует и все работает.
> 
> кроме nginx.
> 
> который падает с такой ошибкой в логах:
> 
> Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not 
> found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the 
> certificate "/etc/letsencrypt/live/example.com/fullchain.pem"
> Aug 14 16:23:03 vm systemd: nginx.service start operation timed out. 
> Terminating.
> Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web 
> server.
> Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state.
> Aug 14 16:23:03 vm systemd: nginx.service failed.
> 
> Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы 
> он нормально запускался и работал на втором узле кластера даже в том
> случае, когда Failover IP указывает на первый физический сервер и 
> виртуальная машина, запускаемая на втором физическом сервере не имеет 
> доступа в интернет?

Нужно либо убрать из из конфигурации всё, что требует резолвинга 
имён, и соответственно требует доступа в интернет, либо сделать 
этот резолвинг возможным (добавив соответствующие имена в 
/etc/hosts или обеспечив работу DNS).

Включённый OCSP stapling - пытается резолвить имена OCSP-серверов 
из сертификатов на старте.  Он, при этом, умеет автоматически 
выключаться, если разрезолвить имя не удаётся, но, судя по всему, 
сертификатов больше одного, а системный резолвер про отсутствие 
интернета не в курсе и тупо ждёт таймаутов, так что случается уже 
таймаут на запуск nginx'а в systemd.


-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx.service start operation timed out. Terminating.

2019-08-14 Пенетрантность Gena Makhomed

Здравствуйте, All!

Столкнулся с проблемой

nginx.service start operation timed out. Terminating.

Конфигурация:

есть два физических сервера px62-nvme
https://www.hetzner.com/dedicated-rootserver/px62-nvme
на каждом из них установлена операционная система Linux,
KVM и ZFS.

Есть виртуальная машина vm, для которой получен Failover IP
https://wiki.hetzner.de/index.php/Failover/en

На первом физическом сервере создан виртуальный диск размером 1 терабайт
для этой виртуальной машины zfs create -s -b 4K -V 1T tank/kvm-vm

Внутри виртуальной машины установлена операционная система Linux,
весь необходимый софт, в том числе и nginx.

Failover IP привязан к первому физическому серверу и проброшен внутрь 
виртуальной машины, все нормально работает, как и ожидалось.


С помощью утилиты https://github.com/makhomed/autosnap
на первом физическом сервере периодически делаются snapshot`ы
zvol с образом диска виртуальной машины и с помощью утилиты
https://github.com/makhomed/autosync эти snapshot`ы
в постоянном режиме реплицируются на второй физический сервер.

на втором физическом сервере настроена идентичная конфигурация
виртуальной машины и с помощью zfs send и zfs receive из локального 
зеркала создана локальная копия виртуального диска tank/kvm-vm


Failover IP привязан к первому физическому серверу,
поэтому если запустить эту же виртуальную машину на втором
физическом сервере - у нее не будет доступа в интернет.

тем не менее, виртуальная машина нормально стартует и все работает.

кроме nginx.

который падает с такой ошибкой в логах:

Aug 14 16:22:35 vm nginx: nginx: [warn] "ssl_stapling" ignored, host not 
found in OCSP responder "ocsp.int-x3.letsencrypt .org" in the 
certificate "/etc/letsencrypt/live/example.com/fullchain.pem"
Aug 14 16:23:03 vm systemd: nginx.service start operation timed out. 
Terminating.
Aug 14 16:23:03 vm systemd: Failed to start nginx - high performance web 
server.

Aug 14 16:23:03 vm systemd: Unit nginx.service entered failed state.
Aug 14 16:23:03 vm systemd: nginx.service failed.

Подскажите пожалуйста, каким образом можно сконфигурировать nginx, чтобы 
он нормально запускался и работал на втором узле кластера даже в том
случае, когда Failover IP указывает на первый физический сервер и 
виртуальная машина, запускаемая на втором физическом сервере не имеет 
доступа в интернет?


Таким способом, как описано выше я пытаюсь сделать high availability
кластер из двух физических серверов, которые размещены в двух различных
датацентрах - один в Германии, второй в Финляндии. Кластер работает
по схеме active/passive, в случае выхода из строя первого физического
сервера - Failover IP переключается на второй физический сервер.

Порядок переключения на второй узел кластера такой:

1. На втором физическом сервере из локальной копии сделать виртуальный 
диск tank/kvm-vm

2. На втором физическом сервере запустить виртуальную машину
3. Переключить Failover IP таким образом, чтобы он указывал на второй 
физический сервер.


И второй вопрос, если он не является в этом списке рассылки оффтопиком:
Я все правильно делаю, когда таким способом строю high availability 
кластер, или я совершил какие-то ошибки и что-то можно сделать

еще проще, еще лучше и еще надежнее?

Про Proxmox и VMware я читал, но мне сейчас гораздо интереснее сделать
high availability кластер самому, используя только CentOS, KVM, ZFS
и немного скриптов на Python.

--
Best regards,
 Gena

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 08:43:39AM -0400, Vladislavik wrote:

> Ничего не генерится, файлы лежат на диске, созданы один раз и записаны на
> диск. Nginx должен сжать его на лету и отдать, вот, что от него требуется,
> он это выполняет, но иногда в кэше браузера/клаудфлера лежит обрезанный

Что лежит в кэшах браузера и клаудфлера - вопрос к браузеру и 
клаудфлеру соответственно.  Исходный вопрос был про proxy cache - 
что лежит в нём, когда наблюдается проблема?

> файл, например половина его (уже разжатый, тупо не весь, не хватает куска
> кода в конце файла) возникает ли ошибка при разжатии я не знаю, видно
> только, что файл читаемый, но код не полный, чаще только половина его) я так
> понял, что в процессе передачи или упаковки возникает какая-то проблема и
> nginx принимает файл от другого nginx/браузера без проверки его на
> целостность...Размеры файлов не более 20кб.
> Вопрос такой: возможно ли распаковать архив, если он получен не полностью?
> (Тк тест в js файла читаемый, но файл состоит только из половины того, что
> должно быть)

Распаковать - возможно.  При распаковке будет известно, полностью 
получен ответ или нет - по наличию/отсутствию gzip trailer'а (8 
байт с CRC32 и размером несжатого ответа).  Что делает с этой 
информацией конкретный распаковщик - тайна сия великая есть, да и 
не важно.  Смотреть надо строго на то, что лежит в кэше nginx'а, 
см. выше.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Vladislavik
Ничего не генерится, файлы лежат на диске, созданы один раз и записаны на
диск. Nginx должен сжать его на лету и отдать, вот, что от него требуется,
он это выполняет, но иногда в кэше браузера/клаудфлера лежит обрезанный
файл, например половина его (уже разжатый, тупо не весь, не хватает куска
кода в конце файла) возникает ли ошибка при разжатии я не знаю, видно
только, что файл читаемый, но код не полный, чаще только половина его) я так
понял, что в процессе передачи или упаковки возникает какая-то проблема и
nginx принимает файл от другого nginx/браузера без проверки его на
целостность...Размеры файлов не более 20кб.
Вопрос такой: возможно ли распаковать архив, если он получен не полностью?
(Тк тест в js файла читаемый, но файл состоит только из половины того, что
должно быть)

Если gzip архив можно распаковать, получив только половину файла, то может
быть проблема в передаче и не удостоверении, что файл передан полностью.

Если архив невозможно распаковать, не получив полностью, значит проблема в
упаковщике.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285250,285271#msg-285271

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 07:53:54AM -0400, Vladislavik wrote:

> Бэкэенд это nginx который шлет обычные файлы js сжатые с помощью встроенного
> gzip

Так, а "обычные файлы js", случайно, не перегенерятся (и/или 
редактируюстся) регулярно?

Ну и отступая на пару шагов назад: битые файлы - это что?  
Обрезанный gzip-контейнер, при распаковке возникает ошибка? Или 
структура gzip-контейнера не нарушена, всё штатно распаковывается 
без ошибок, но по результатом распаковки получается только часть 
того, что ожидалось в файле?

Если второе - то это выглядит как проблема с генерацией файлов.  
Такое бывает, если генерить файлы "по месту" - если к файлу 
обрататься, пока пишется новая версия, то из него прочитается 
только часть, уже записанная, но никто не обещал, что это будет 
ожидаемый файл полностью.  Соответственно эта часть и будет 
отправлена клиенту и закэширована.

Чтобы такого не было - надо менять файлы атомарно: написать новый 
файл рядом с временным именем, потом сделать rename() / mv в 
нужное имя.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Vladislavik
Бэкэенд это nginx который шлет обычные файлы js сжатые с помощью встроенного
gzip

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285250,285269#msg-285269

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Wed, Aug 14, 2019 at 07:30:41AM -0400, Vladislavik wrote:

> Максим, прокси версии 1.1 итак установлен, битые файлы на нем и получаются.
> Клаудфлер тоже использует 1.1 у них так же битые файлы часто лежат в кеше,
> проверял лично.

Если так, то наиболее вероятная причина - бэкенд так прислал.  
Почему и как вылечить - уже, видимо, вопрос к бэкенду.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Vladislavik
Максим, прокси версии 1.1 итак установлен, битые файлы на нем и получаются.
Клаудфлер тоже использует 1.1 у них так же битые файлы часто лежат в кеше,
проверял лично.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,285250,285267#msg-285267

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Битые файлы в кеше при gzip ответах

2019-08-14 Пенетрантность Maxim Dounin
Hello!

On Tue, Aug 13, 2019 at 09:52:16PM +0300, Владислав Толмачев wrote:

> Добрый день, не пойму как исправить ситуацию, nginx иногда хранит в proxy
> кеше битые обрезанные файлы, при использовании на бэкенде gzip, тот же баг
> замечен на клаудфлер, иногда в его кеше лешит обрезанный файл, например
> половина js файла и помогает только сброс кеша и запрос файла еще раз, что
> бы файл стал полный. Что подкрутить, что бы не выключать gzip и http1.1? В
> клаудфлере даже замечено то, что половина кэш серверов сохраняет полный
> файл, половина хранит его обрезанную версию и выдает ее как правильную

Использование сжатия на бэкенде обычно означает, что заголовка 
Content-Length в ответах бэкенда не будет.  Соответственно в 
HTTP/1.0 окончание ответа будет определяться по закрытию соединения, и 
если бэкенд по каким-то причинам закрывает соединение, не дослав 
ответ полностью, то такой ответ имеет шансы быть сохранённым в кэш 
частично.

Лучше всего в подобной ситуации - разобраться, почему таки 
закрываются соединения, и полечить.  Но в качестве workaround'а 
скорее всего сработает "proxy_http_version 1.1;" в конфиге.

Подробнее тут:

http://nginx.org/r/proxy_http_version/ru

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru