From schors на gmail.com Mon Feb 3 11:21:59 2020 From: schors на gmail.com (Phil Kulin) Date: Mon, 3 Feb 2020 14:21:59 +0300 Subject: Custom error page Message-ID: 1. Я задумался сделать всем клиентам страницу с HTTP кодом 451 и у меня возникла проблема - получается, я должен в каждый server прописать location с обработкой? Выглядит громоздко. Может я не прав, пока не решил для себя 2. Nginx не знает об HTTP CODE 451 2.1 Может быть он узнает? Там дела на полстроки в простом случае 2.2 Как самому добавить описание ошибки в заголовок ответа? -- Non nobis Domine non nobis sed Nomini Tuo da gloriam Phil Kulin From pluknet на nginx.com Mon Feb 3 14:37:55 2020 From: pluknet на nginx.com (Sergey Kandaurov) Date: Mon, 3 Feb 2020 17:37:55 +0300 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: <20200129120629.GO12894@mdounin.ru> References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> <20200129120629.GO12894@mdounin.ru> Message-ID: <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> > On 29 Jan 2020, at 15:06, Maxim Dounin wrote: > > Hello! > > On Wed, Jan 29, 2020 at 01:40:44PM +0300, Sergey Kandaurov wrote: > >> >>> On 29 Jan 2020, at 06:20, Ilya Evseev wrote: >>> >>> Есть Nginx 1.17.8, собран со свежей BoringSSL stable. >>> Запущен на Linux kernel 5.4.10: >>> >>> [..] >>> SSL в Nginx'e настроен так: >>> >>> ssl_dhparam /etc/pki/tls/private/dhparam2048.pem; >>> ssl_session_timeout 1h; >>> ssl_session_cache shared:SSL:10m; >>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; >>> ssl_ciphers >>> kEECDH+ECDSA+AESGCM:kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; >>> ssl_prefer_server_ciphers on; >>> ssl_early_data on; >>> >>> Проверяю, поддерживает ли он SSL early data: >>> >>> docker run --rm -it nablac0d3/sslyze --early_data 1.2.3.4 >>> >>> Результат: >>> >>> - Если в nginx'e настроен "worker_processes 1;", sslyze всегда возвращает >>> "Suppported - Server accepted early data" >>> - Если воркеров больше одного, "Supported" начинает возвращаться не всегда. >>> Чем больше воркеров - тем чаще возвращается "Not supported". >>> >>> Т.е. выглядит так, будто SSL Early Data поддерживает только первый воркер. >>> >>> Этому есть какое-то объяснение? >> >> Тут дело не в early data, а в том что BoringSSL по какой-то причине не >> разрешает сохранять тикеты в session cache. В итоге сессия восстанавливается >> только по тикету из того же рабочего процесса, который его породил. >> Это означает, что восстановление сессий из кеша (в т.ч. shared) не будет >> работать и для TLSv1.2 со включёнными по умолчанию тикетами. > > Э. Тикеты - восстанавливаются по ключу, который задаётся в > master-процессе и соответственно одинаковый во всех рабочих > процессах. То есть восстановление тикетов должно работать вне > зависимости от session cache, и работать всегда. И действительно. В BoringSSL ключи создаются не во время вызова SSL_CTX_new() в master-процессе, а по необходимости при работе с тикетами, где таким образом каждый рабочий процесс получает уникальное значение в соответствующих структурах SSL_CTX. Это препятствует восстановлению сессии по тикету в другом процессе. Помимо этого, применяется механизм автовращания ключей через SSL_DEFAULT_TICKET_KEY_ROTATION_INTERVAL секунд после создания, но здесь это не столь важно. Использование коллбека SSL_CTX_set_tlsext_ticket_key_cb отменяет это. > В BoringSSL раньше всей этой фигни не было, и там всё работало из > коробки, без дополнительных приседаний. Закоммитили какую-то > аналогичную ерунду? https://boringssl.googlesource.com/boringssl/+/72912d2 -- Sergey Kandaurov From alnkapa на gmail.com Mon Feb 3 15:15:31 2020 From: alnkapa на gmail.com (Aln Kapa) Date: Mon, 3 Feb 2020 18:15:31 +0300 Subject: =?UTF-8?B?Z1JQQyDRgNCy0LXRgtGB0Y8g0YDQsNC3INCyINC80LjQvdGD0YLRgw==?= Message-ID: Добрый день. На nginx настроено gRPC так server { location / { grpc_pass 127.0.0.1:xxxx; } } Схема такая: message SomeMessage { string test = 1; } service ZoneService { rpc Event (google.protobuf.Empty) returns (stream SomeMessage) { } } Если я запускаю клиента через nginx то получаю такие сообщения: date;./bin/mock/test;date Пн фев 3 17:58:53 MSK 2020 MockZone:2020/02/03 17:58:54 ======= TEST OK ========= MockZone:2020/02/03 17:59:53 rpc error: code = Internal desc = stream terminated by RST_STREAM with error code: INTERNAL_ERROR Пн фев 3 17:59:53 MSK 2020 Если пустить напрямую соединение не рвется. nginx ругается так 2020/02/03 17:59:53 [error] 4285#4285: *13 upstream timed out (110: Connection timed out) while reading upstream Подскажите что подкрутить на nginx, grpc_read_timeout или grpc_send_timeout оба сразу? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Mon Feb 3 15:40:12 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Feb 2020 18:40:12 +0300 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> <20200129120629.GO12894@mdounin.ru> <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> Message-ID: <20200203154012.GT12894@mdounin.ru> Hello! On Mon, Feb 03, 2020 at 05:37:55PM +0300, Sergey Kandaurov wrote: > > > On 29 Jan 2020, at 15:06, Maxim Dounin wrote: > > > > Hello! > > > > On Wed, Jan 29, 2020 at 01:40:44PM +0300, Sergey Kandaurov wrote: > > > >> > >>> On 29 Jan 2020, at 06:20, Ilya Evseev wrote: > >>> > >>> Есть Nginx 1.17.8, собран со свежей BoringSSL stable. > >>> Запущен на Linux kernel 5.4.10: > >>> > >>> [..] > >>> SSL в Nginx'e настроен так: > >>> > >>> ssl_dhparam /etc/pki/tls/private/dhparam2048.pem; > >>> ssl_session_timeout 1h; > >>> ssl_session_cache shared:SSL:10m; > >>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; > >>> ssl_ciphers > >>> kEECDH+ECDSA+AESGCM:kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; > >>> ssl_prefer_server_ciphers on; > >>> ssl_early_data on; > >>> > >>> Проверяю, поддерживает ли он SSL early data: > >>> > >>> docker run --rm -it nablac0d3/sslyze --early_data 1.2.3.4 > >>> > >>> Результат: > >>> > >>> - Если в nginx'e настроен "worker_processes 1;", sslyze всегда возвращает > >>> "Suppported - Server accepted early data" > >>> - Если воркеров больше одного, "Supported" начинает возвращаться не всегда. > >>> Чем больше воркеров - тем чаще возвращается "Not supported". > >>> > >>> Т.е. выглядит так, будто SSL Early Data поддерживает только первый воркер. > >>> > >>> Этому есть какое-то объяснение? > >> > >> Тут дело не в early data, а в том что BoringSSL по какой-то причине не > >> разрешает сохранять тикеты в session cache. В итоге сессия восстанавливается > >> только по тикету из того же рабочего процесса, который его породил. > >> Это означает, что восстановление сессий из кеша (в т.ч. shared) не будет > >> работать и для TLSv1.2 со включёнными по умолчанию тикетами. > > > > Э. Тикеты - восстанавливаются по ключу, который задаётся в > > master-процессе и соответственно одинаковый во всех рабочих > > процессах. То есть восстановление тикетов должно работать вне > > зависимости от session cache, и работать всегда. > > И действительно. В BoringSSL ключи создаются не во время вызова > SSL_CTX_new() в master-процессе, а по необходимости при работе > с тикетами, где таким образом каждый рабочий процесс получает > уникальное значение в соответствующих структурах SSL_CTX. Это > препятствует восстановлению сессии по тикету в другом процессе. > Помимо этого, применяется механизм автовращания ключей через > SSL_DEFAULT_TICKET_KEY_ROTATION_INTERVAL секунд после создания, > но здесь это не столь важно. > > Использование коллбека SSL_CTX_set_tlsext_ticket_key_cb отменяет это. [...] > https://boringssl.googlesource.com/boringssl/+/72912d2 Ну э, молодцы. То есть доступный прямо сейчас workaround для BoringSSL - задать ssl_session_ticket_key явно. Что, конечно, делает прямо противоположное тому, что было целью авторов данного изменения - вместо вращения ключей при каждом чтении конфигурации, которое было раньше, и в пару к которому хотелось сделать автовращение, мы получаем вечно лежащий на диске ключ. Возможно, стоит подумать о том, чтобы явно отключить всю эту красоту для BoringSSL, явно задав случайные ключи при чтении конфигурации, скажем, с помощью SSL_CTX_set_tlsext_ticket_keys(). Ну или сделать, наконец, автовращение ключей на уровне nginx'а, с синхронизацией ключей между рабочими процессами через разделяемую память. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Mon Feb 3 15:44:58 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Feb 2020 18:44:58 +0300 Subject: =?UTF-8?B?UmU6IGdSUEMg0YDQstC10YLRgdGPINGA0LDQtyDQsiDQvNC40L3Rg9GC0YM=?= In-Reply-To: References: Message-ID: <20200203154458.GU12894@mdounin.ru> Hello! On Mon, Feb 03, 2020 at 06:15:31PM +0300, Aln Kapa wrote: > Добрый день. > > На nginx настроено gRPC так > server { > location / { > grpc_pass 127.0.0.1:xxxx; > } > } > Схема такая: > message SomeMessage { > string test = 1; > } > service ZoneService { > rpc Event (google.protobuf.Empty) returns (stream SomeMessage) { > } > } > > Если я запускаю клиента через nginx то получаю такие сообщения: > date;./bin/mock/test;date > Пн фев 3 17:58:53 MSK 2020 > MockZone:2020/02/03 17:58:54 ======= TEST OK ========= > MockZone:2020/02/03 17:59:53 rpc error: code = Internal desc = stream > terminated by RST_STREAM with error code: INTERNAL_ERROR > Пн фев 3 17:59:53 MSK 2020 > Если пустить напрямую соединение не рвется. > nginx ругается так > 2020/02/03 17:59:53 [error] 4285#4285: *13 upstream timed out (110: > Connection timed out) while reading upstream > > Подскажите что подкрутить на nginx, grpc_read_timeout или grpc_send_timeout > оба сразу? Проблема в том, что бекенд ничего не возвращает в течении долгого времени. Соответственно если это ожидаемое поведение - то крутить grpc_read_timeout. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Feb 3 15:44:58 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 3 Feb 2020 20:44:58 +0500 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: <20200203154012.GT12894@mdounin.ru> References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> <20200129120629.GO12894@mdounin.ru> <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> <20200203154012.GT12894@mdounin.ru> Message-ID: правка от 2017 года, просто не замечали ? (или я что-то не понимаю, и проявилось только спустя 2.5 года) пн, 3 февр. 2020 г. в 20:40, Maxim Dounin : > Hello! > > On Mon, Feb 03, 2020 at 05:37:55PM +0300, Sergey Kandaurov wrote: > > > > > > On 29 Jan 2020, at 15:06, Maxim Dounin wrote: > > > > > > Hello! > > > > > > On Wed, Jan 29, 2020 at 01:40:44PM +0300, Sergey Kandaurov wrote: > > > > > >> > > >>> On 29 Jan 2020, at 06:20, Ilya Evseev > wrote: > > >>> > > >>> Есть Nginx 1.17.8, собран со свежей BoringSSL stable. > > >>> Запущен на Linux kernel 5.4.10: > > >>> > > >>> [..] > > >>> SSL в Nginx'e настроен так: > > >>> > > >>> ssl_dhparam /etc/pki/tls/private/dhparam2048.pem; > > >>> ssl_session_timeout 1h; > > >>> ssl_session_cache shared:SSL:10m; > > >>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; > > >>> ssl_ciphers > > >>> > kEECDH+ECDSA+AESGCM:kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2; > > >>> ssl_prefer_server_ciphers on; > > >>> ssl_early_data on; > > >>> > > >>> Проверяю, поддерживает ли он SSL early data: > > >>> > > >>> docker run --rm -it nablac0d3/sslyze --early_data 1.2.3.4 > > >>> > > >>> Результат: > > >>> > > >>> - Если в nginx'e настроен "worker_processes 1;", sslyze всегда > возвращает > > >>> "Suppported - Server accepted early data" > > >>> - Если воркеров больше одного, "Supported" начинает возвращаться не > всегда. > > >>> Чем больше воркеров - тем чаще возвращается "Not supported". > > >>> > > >>> Т.е. выглядит так, будто SSL Early Data поддерживает только первый > воркер. > > >>> > > >>> Этому есть какое-то объяснение? > > >> > > >> Тут дело не в early data, а в том что BoringSSL по какой-то причине не > > >> разрешает сохранять тикеты в session cache. В итоге сессия > восстанавливается > > >> только по тикету из того же рабочего процесса, который его породил. > > >> Это означает, что восстановление сессий из кеша (в т.ч. shared) не > будет > > >> работать и для TLSv1.2 со включёнными по умолчанию тикетами. > > > > > > Э. Тикеты - восстанавливаются по ключу, который задаётся в > > > master-процессе и соответственно одинаковый во всех рабочих > > > процессах. То есть восстановление тикетов должно работать вне > > > зависимости от session cache, и работать всегда. > > > > И действительно. В BoringSSL ключи создаются не во время вызова > > SSL_CTX_new() в master-процессе, а по необходимости при работе > > с тикетами, где таким образом каждый рабочий процесс получает > > уникальное значение в соответствующих структурах SSL_CTX. Это > > препятствует восстановлению сессии по тикету в другом процессе. > > Помимо этого, применяется механизм автовращания ключей через > > SSL_DEFAULT_TICKET_KEY_ROTATION_INTERVAL секунд после создания, > > но здесь это не столь важно. > > > > Использование коллбека SSL_CTX_set_tlsext_ticket_key_cb отменяет это. > > [...] > > > https://boringssl.googlesource.com/boringssl/+/72912d2 > > Ну э, молодцы. То есть доступный прямо сейчас workaround для > BoringSSL - задать ssl_session_ticket_key явно. Что, конечно, > делает прямо противоположное тому, что было целью авторов данного > изменения - вместо вращения ключей при каждом чтении конфигурации, > которое было раньше, и в пару к которому хотелось сделать > автовращение, мы получаем вечно лежащий на диске ключ. > > Возможно, стоит подумать о том, чтобы явно отключить всю эту > красоту для BoringSSL, явно задав случайные ключи при чтении > конфигурации, скажем, с помощью SSL_CTX_set_tlsext_ticket_keys(). > > Ну или сделать, наконец, автовращение ключей на уровне 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 Mon Feb 3 16:17:42 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Feb 2020 19:17:42 +0300 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> <20200129120629.GO12894@mdounin.ru> <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> <20200203154012.GT12894@mdounin.ru> Message-ID: <20200203161742.GV12894@mdounin.ru> Hello! On Mon, Feb 03, 2020 at 08:44:58PM +0500, Илья Шипицин wrote: > правка от 2017 года, просто не замечали ? Так BoringSSL же. Там обычно проблемы на уровне "не собирается" или "вообще не работает, ибо функционал выпилили" (как, например, с поддержкой нескольких сертификатов). Если оно работает и просто не восстанавливает сессии - это прямо таки "всё хорошо". Ну и по очевидным причинам заметить такую проблему в автоматизированных тестах - это надо специально тестировать гипотезу "восстановление сессий через тикеты сломается при нескольких рабочих процессах". Так что шансов приблизительно никаких. А реальные пользователи BoringSSL - скорее всего либо и так используют ssl_session_ticket_key, либо на восстановление сессий не смотрят. Так что и там шансов немного. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Mon Feb 3 16:32:29 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 3 Feb 2020 21:32:29 +0500 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: <20200203161742.GV12894@mdounin.ru> References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> <20200129120629.GO12894@mdounin.ru> <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> <20200203154012.GT12894@mdounin.ru> <20200203161742.GV12894@mdounin.ru> Message-ID: BoringSSL используется в CloudFlare часто они первыми умудряются заметить какие-то редкие баги. Ибо трафика у них много но забавно, да пн, 3 февр. 2020 г. в 21:17, Maxim Dounin : > Hello! > > On Mon, Feb 03, 2020 at 08:44:58PM +0500, Илья Шипицин wrote: > > > правка от 2017 года, просто не замечали ? > > Так BoringSSL же. Там обычно проблемы на уровне "не собирается" > или "вообще не работает, ибо функционал выпилили" (как, например, с > поддержкой нескольких сертификатов). Если оно работает и просто > не восстанавливает сессии - это прямо таки "всё хорошо". > > Ну и по очевидным причинам заметить такую проблему в > автоматизированных тестах - это надо специально тестировать > гипотезу "восстановление сессий через тикеты сломается при > нескольких рабочих процессах". Так что шансов приблизительно > никаких. > > А реальные пользователи BoringSSL - скорее всего либо и так > используют ssl_session_ticket_key, либо на восстановление сессий > не смотрят. Так что и там шансов немного. > > -- > 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 Mon Feb 3 16:50:46 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 3 Feb 2020 19:50:46 +0300 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> <20200129120629.GO12894@mdounin.ru> <38F96174-8C90-4881-97B3-7F047CAF55D5@nginx.com> <20200203154012.GT12894@mdounin.ru> <20200203161742.GV12894@mdounin.ru> Message-ID: <20200203165046.GX12894@mdounin.ru> Hello! On Mon, Feb 03, 2020 at 09:32:29PM +0500, Илья Шипицин wrote: > BoringSSL используется в CloudFlare > часто они первыми умудряются заметить какие-то редкие баги. Ибо трафика у > них много У них ssl_session_ticket_key используется с вероятностью 146%. -- Maxim Dounin http://mdounin.ru/ From alnkapa на gmail.com Tue Feb 4 06:20:53 2020 From: alnkapa на gmail.com (Aln Kapa) Date: Tue, 4 Feb 2020 09:20:53 +0300 Subject: =?UTF-8?B?UmU6IGdSUEMg0YDQstC10YLRgdGPINGA0LDQtyDQsiDQvNC40L3Rg9GC0YM=?= In-Reply-To: <20200203154458.GU12894@mdounin.ru> References: <20200203154458.GU12894@mdounin.ru> Message-ID: Спасибо. А если я настрою gRPC keepalive на сервере, на интервал немного меньше чем grpc_read_timeout. Это поможет nginx определить что соединение еще живо? пн, 3 февр. 2020 г. в 18:45, Maxim Dounin : > Hello! > > On Mon, Feb 03, 2020 at 06:15:31PM +0300, Aln Kapa wrote: > > > Добрый день. > > > > На nginx настроено gRPC так > > server { > > location / { > > grpc_pass 127.0.0.1:xxxx; > > } > > } > > Схема такая: > > message SomeMessage { > > string test = 1; > > } > > service ZoneService { > > rpc Event (google.protobuf.Empty) returns (stream SomeMessage) { > > } > > } > > > > Если я запускаю клиента через nginx то получаю такие сообщения: > > date;./bin/mock/test;date > > Пн фев 3 17:58:53 MSK 2020 > > MockZone:2020/02/03 17:58:54 ======= TEST OK ========= > > MockZone:2020/02/03 17:59:53 rpc error: code = Internal desc = stream > > terminated by RST_STREAM with error code: INTERNAL_ERROR > > Пн фев 3 17:59:53 MSK 2020 > > Если пустить напрямую соединение не рвется. > > nginx ругается так > > 2020/02/03 17:59:53 [error] 4285#4285: *13 upstream timed out (110: > > Connection timed out) while reading upstream > > > > Подскажите что подкрутить на nginx, grpc_read_timeout или > grpc_send_timeout > > оба сразу? > > Проблема в том, что бекенд ничего не возвращает в течении долгого > времени. Соответственно если это ожидаемое поведение - то крутить > grpc_read_timeout. > > -- > 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 Tue Feb 4 12:42:51 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 4 Feb 2020 15:42:51 +0300 Subject: =?UTF-8?B?UmU6IGdSUEMg0YDQstC10YLRgdGPINGA0LDQtyDQsiDQvNC40L3Rg9GC0YM=?= In-Reply-To: References: <20200203154458.GU12894@mdounin.ru> Message-ID: <20200204124251.GC12894@mdounin.ru> Hello! On Tue, Feb 04, 2020 at 09:20:53AM +0300, Aln Kapa wrote: > А если я настрою gRPC keepalive на сервере, на интервал немного меньше чем > grpc_read_timeout. Это поможет nginx определить что соединение еще живо? Да, если от бекенда будет хоть что-то приходить - это предотвратит срабатывание таймаута на чтение. Но вообще лучше в подобных ситуациях гонять что-то end-to-end, чтобы и живость соединения с клиентом сразу проверялась. gRPC'шные keepalive'ы для этого не годятся, так как они hop-by-hop и могут проверить исключительно живость соединения между nginx'ом и бекендом. -- Maxim Dounin http://mdounin.ru/ From alnkapa на gmail.com Tue Feb 4 13:21:53 2020 From: alnkapa на gmail.com (Aln Kapa) Date: Tue, 4 Feb 2020 16:21:53 +0300 Subject: =?UTF-8?B?UmU6IGdSUEMg0YDQstC10YLRgdGPINGA0LDQtyDQsiDQvNC40L3Rg9GC0YM=?= In-Reply-To: <20200204124251.GC12894@mdounin.ru> References: <20200203154458.GU12894@mdounin.ru> <20200204124251.GC12894@mdounin.ru> Message-ID: Правильно ли я понимаю, что nginx на gRPC'шные keepalive'ы отвечает сам, и не прокидывает их дальше по назначению ? вт, 4 февр. 2020 г. в 15:42, Maxim Dounin : > Hello! > > On Tue, Feb 04, 2020 at 09:20:53AM +0300, Aln Kapa wrote: > > > А если я настрою gRPC keepalive на сервере, на интервал немного меньше > чем > > grpc_read_timeout. Это поможет nginx определить что соединение еще живо? > > Да, если от бекенда будет хоть что-то приходить - это предотвратит > срабатывание таймаута на чтение. > > Но вообще лучше в подобных ситуациях гонять что-то end-to-end, > чтобы и живость соединения с клиентом сразу проверялась. > gRPC'шные keepalive'ы для этого не годятся, так как они hop-by-hop > и могут проверить исключительно живость соединения между 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 Tue Feb 4 14:35:56 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 4 Feb 2020 17:35:56 +0300 Subject: =?UTF-8?B?UmU6IGdSUEMg0YDQstC10YLRgdGPINGA0LDQtyDQsiDQvNC40L3Rg9GC0YM=?= In-Reply-To: References: <20200203154458.GU12894@mdounin.ru> <20200204124251.GC12894@mdounin.ru> Message-ID: <20200204143556.GD12894@mdounin.ru> Hello! On Tue, Feb 04, 2020 at 04:21:53PM +0300, Aln Kapa wrote: > Правильно ли я понимаю, что nginx на gRPC'шные keepalive'ы отвечает сам, и > не прокидывает их дальше по назначению ? gRPC'шные keepalive'ы - это PING-фреймы в рамках HTTP/2, если я правильно понимаю, о чём речь. Они hop-by-hop, то есть передаются между непосредственными участниками соединения, в данном случае - между nginx'ом и бекендом. Соответственно прокидывать "по назначению" их некуда, назначение у них - сам nginx. Тут, возможно, стоит пояснить, что исходная концепция gRPC не предполагает проксирования ("мы будем делать балансировку на клиентах", говорили они[1]). Практика, однако, показала, что так - не работает, проксировать - приходится. От этого многие элементы протокола в реальном мире работают немного не так, как задумывалось и/или документировано. [1] https://github.com/grpc/grpc/blob/master/doc/load-balancing.md -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Feb 5 07:37:43 2020 From: nginx-forum на forum.nginx.org (muxui) Date: Wed, 05 Feb 2020 02:37:43 -0500 Subject: =?UTF-8?B?0J/QvtGB0LvQtSDRgdCx0L7RgNC60Lggbmdpbngg0L/QsNC00LDQtdGCINCyIHNp?= =?UTF-8?B?Z25hbCAxMT8=?= Message-ID: Привет. Последние два раза собирал latest nginx, что в первый, что во второй - ошибка та же. Первый собирал месяца 4 назад, сейчас ошибка осталась, но уже версия nginx обновилась. Сама ошибка: 2020/02/04 23:13:07 [alert] 18028#18028: worker process 22877 exited on signal 11 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22875 exited on signal 11 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22876 exited on signal 11 2020/02/04 23:13:16 [alert] 18028#18028: worker process 22874 exited on signal 11 2020/02/04 23:13:18 [alert] 18028#18028: worker process 22878 exited on signal 11 Конфиг сборки: ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --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 --user=nginx --group=nginx --without-http_autoindex_module --without-http_ssi_module --without-http_scgi_module --without-http_uwsgi_module --without-http_split_clients_module --without-http_memcached_module --without-http_empty_gif_module --without-http_browser_module --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_mp4_module --with-http_auth_request_module --with-http_stub_status_module --with-http_random_index_module --with-http_ssl_module --with-http_gunzip_module --with-threads --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable --add-module=/usr/local/src/ngx_devel_kit-0.3.1 --add-module=/usr/local/src/lua-nginx-module-0.10.9 --with-openssl=/usr/local/src/openssl-1.0.2t Ошибка выдается только при HTTPS запросе из Lua, который я установил в nginx. Конфиг сайта: server { server_name api.muxui.cc; listen 443 ssl http2; root /var/www/html/api; location / { content_by_lua_file /var/www/html/api/vk/index.lua; lua_code_cache off; aio threads; } } Код index.lua: require("socket") local https = require("ssl.https") local body, code, headers, status = https.request('https://api.vk.com/method/messages.send?message=Привет&user_ids=111&random_id=' .. math.random() .. '&v=5.105&access_token=234234') print(status) nginx -V: root на muxui:~# nginx -V nginx version: nginx/1.17.8 built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) built with OpenSSL 1.0.2t 10 Sep 2019 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --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 --user=nginx --group=nginx --without-http_autoindex_module --without-http_ssi_module --without-http_scgi_module --without-http_uwsgi_module --without-http_split_clients_module --without-http_memcached_module --without-http_empty_gif_module --without-http_browser_module --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_mp4_module --with-http_auth_request_module --with-http_stub_status_module --with-http_random_index_module --with-http_ssl_module --with-http_gunzip_module --with-threads --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable --add-module=/usr/local/src/ngx_devel_kit-0.3.1 --add-module=/usr/local/src/lua-nginx-module-0.10.9 --with-openssl=/usr/local/src/openssl-1.0.2t Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286935,286935#msg-286935 From chipitsine на gmail.com Wed Feb 5 10:30:51 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Feb 2020 15:30:51 +0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC70LUg0YHQsdC+0YDQutC4IG5naW54INC/0LDQtNCw0LXRgiA=?= =?UTF-8?B?0LIgc2lnbmFsIDExPw==?= In-Reply-To: References: Message-ID: причину падения в 11-й сигнал можно установить примерно таким способом 1) добавляете "-ggdb" к опциям сборки ( --with-cc-opts="-g" --with-ld-opts="-g") 2) далее, надо после сборки аккуратно скопировать полученный objs/nginx в то место, откуда он запускается. если сделаете "make install", то отладочная информация удалится. проверьте "file `which nginx`" - должен показывать наличие отладочной инфы 3) на уровне вашей операционки настраиваете сбор core dump 4) в nginx.conf прописываете "worker_rlimit_core 16000M;" (ну или больше) запускаете, падает, получаете core dump. запускаете gdb: gdb --core core.file `which nginx` > bt full и присылаете сюда ср, 5 февр. 2020 г. в 12:38, muxui : > Привет. > Последние два раза собирал latest nginx, что в первый, что во второй - > ошибка та же. > Первый собирал месяца 4 назад, сейчас ошибка осталась, но уже версия nginx > обновилась. > Сама ошибка: > 2020/02/04 23:13:07 [alert] 18028#18028: worker process 22877 exited > on signal 11 > 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22875 exited on > signal 11 > 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22876 exited on > signal 11 > 2020/02/04 23:13:16 [alert] 18028#18028: worker process 22874 exited on > signal 11 > 2020/02/04 23:13:18 [alert] 18028#18028: worker process 22878 exited on > signal 11 > > Конфиг сборки: > ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --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 --user=nginx > --group=nginx --without-http_autoindex_module --without-http_ssi_module > --without-http_scgi_module --without-http_uwsgi_module > --without-http_split_clients_module --without-http_memcached_module > --without-http_empty_gif_module --without-http_browser_module > --with-http_ssl_module --with-http_v2_module --with-http_realip_module > --with-http_mp4_module --with-http_auth_request_module > --with-http_stub_status_module --with-http_random_index_module > --with-http_ssl_module --with-http_gunzip_module --with-threads > --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable > --add-module=/usr/local/src/ngx_devel_kit-0.3.1 > --add-module=/usr/local/src/lua-nginx-module-0.10.9 > --with-openssl=/usr/local/src/openssl-1.0.2t > Ошибка выдается только при HTTPS запросе из Lua, который я установил в > nginx. > Конфиг сайта: > > server { > server_name api.muxui.cc; > listen 443 ssl http2; > > root /var/www/html/api; > > location / { > content_by_lua_file /var/www/html/api/vk/index.lua; > lua_code_cache off; > aio threads; > } > } > > Код index.lua: > > require("socket") > local https = require("ssl.https") > local body, code, headers, status = > https.request(' > https://api.vk.com/method/messages.send?message=Привет&user_ids=111&random_id= > ' > .. math.random() .. '&v=5.105&access_token=234234') > print(status) > > nginx -V: > > > root на muxui:~# nginx -V > nginx version: nginx/1.17.8 > built by gcc 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) > built with OpenSSL 1.0.2t 10 Sep 2019 > TLS SNI support enabled > configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --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 --user=nginx > --group=nginx --without-http_autoindex_module --without-http_ssi_module > --without-http_scgi_module --without-http_uwsgi_module > --without-http_split_clients_module --without-http_memcached_module > --without-http_empty_gif_module --without-http_browser_module > --with-http_ssl_module --with-http_v2_module --with-http_realip_module > --with-http_mp4_module --with-http_auth_request_module > --with-http_stub_status_module --with-http_random_index_module > --with-http_ssl_module --with-http_gunzip_module --with-threads > --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable > --add-module=/usr/local/src/ngx_devel_kit-0.3.1 > --add-module=/usr/local/src/lua-nginx-module-0.10.9 > --with-openssl=/usr/local/src/openssl-1.0.2t > > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,286935,286935#msg-286935 > > _______________________________________________ > 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 Feb 5 11:41:31 2020 From: nginx-forum на forum.nginx.org (artesah) Date: Wed, 05 Feb 2020 06:41:31 -0500 Subject: =?UTF-8?B?bmdpbngg0L7RgtC60YDRi9Cy0LDQtdGCINC90LUg0YLRgyDQtNC40YDQtdC60YI=?= =?UTF-8?B?0L7RgNC40Y4=?= Message-ID: <838b8b9e7d1332c2a736cd59a1c262f2.NginxMailingListRussian@forum.nginx.org> Доброго времени суток, Господа. Ситуация следующая, после обновления сервера веб сервер начал направлять не в ту директорию. Лог: 2020/02/05 11:28:23 [error] 2329#2329: *7 open() "/usr/share/nginx/html/zabbix.php" failed (2: No such file or directory), client: мой ip1, server: localhost, request: "GET /zabbix.php HTTP/1.1", host: "хост" В то время как директория сайта находиться на /usr/share/zabbix В конфиге /etc/nginx/conf.d/zabbix.conf прописан set $webroot '/usr/share/zabbix'; А в основном /etc/nginx/nginx.conf записан include /etc/nginx/conf.d/zabbix.conf; В чем может быть проблема? Заранее спасибо Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286943,286943#msg-286943 From mdounin на mdounin.ru Wed Feb 5 12:12:00 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 5 Feb 2020 15:12:00 +0300 Subject: =?UTF-8?B?UmU6INCf0L7RgdC70LUg0YHQsdC+0YDQutC4IG5naW54INC/0LDQtNCw0LXRgiA=?= =?UTF-8?B?0LIgc2lnbmFsIDExPw==?= In-Reply-To: References: Message-ID: <20200205121200.GE12894@mdounin.ru> Hello! On Wed, Feb 05, 2020 at 02:37:43AM -0500, muxui wrote: > Привет. > Последние два раза собирал latest nginx, что в первый, что во второй - > ошибка та же. > Первый собирал месяца 4 назад, сейчас ошибка осталась, но уже версия nginx > обновилась. > Сама ошибка: > 2020/02/04 23:13:07 [alert] 18028#18028: worker process 22877 exited > on signal 11 > 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22875 exited on > signal 11 > 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22876 exited on > signal 11 > 2020/02/04 23:13:16 [alert] 18028#18028: worker process 22874 exited on > signal 11 > 2020/02/04 23:13:18 [alert] 18028#18028: worker process 22878 exited on > signal 11 > > Конфиг сборки: > ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > --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 --user=nginx > --group=nginx --without-http_autoindex_module --without-http_ssi_module > --without-http_scgi_module --without-http_uwsgi_module > --without-http_split_clients_module --without-http_memcached_module > --without-http_empty_gif_module --without-http_browser_module > --with-http_ssl_module --with-http_v2_module --with-http_realip_module > --with-http_mp4_module --with-http_auth_request_module > --with-http_stub_status_module --with-http_random_index_module > --with-http_ssl_module --with-http_gunzip_module --with-threads > --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable > --add-module=/usr/local/src/ngx_devel_kit-0.3.1 > --add-module=/usr/local/src/lua-nginx-module-0.10.9 > --with-openssl=/usr/local/src/openssl-1.0.2t Опции сборки как бы намекают, что проблема - в сторонних модулях. Попробуйте воспроизвести проблему без них. [...] -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Feb 5 12:50:11 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Feb 2020 17:50:11 +0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC70LUg0YHQsdC+0YDQutC4IG5naW54INC/0LDQtNCw0LXRgiA=?= =?UTF-8?B?0LIgc2lnbmFsIDExPw==?= In-Reply-To: <20200205121200.GE12894@mdounin.ru> References: <20200205121200.GE12894@mdounin.ru> Message-ID: Судя по content_by_lua воспроизвести без сторонних модулей затруднительно On Wed, Feb 5, 2020, 5:12 PM Maxim Dounin wrote: > Hello! > > On Wed, Feb 05, 2020 at 02:37:43AM -0500, muxui wrote: > > > Привет. > > Последние два раза собирал latest nginx, что в первый, что во второй - > > ошибка та же. > > Первый собирал месяца 4 назад, сейчас ошибка осталась, но уже версия > nginx > > обновилась. > > Сама ошибка: > > 2020/02/04 23:13:07 [alert] 18028#18028: worker process 22877 > exited > > on signal 11 > > 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22875 exited on > > signal 11 > > 2020/02/04 23:13:08 [alert] 18028#18028: worker process 22876 exited on > > signal 11 > > 2020/02/04 23:13:16 [alert] 18028#18028: worker process 22874 exited on > > signal 11 > > 2020/02/04 23:13:18 [alert] 18028#18028: worker process 22878 exited on > > signal 11 > > > > Конфиг сборки: > > ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx > > --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 --user=nginx > > --group=nginx --without-http_autoindex_module --without-http_ssi_module > > --without-http_scgi_module --without-http_uwsgi_module > > --without-http_split_clients_module --without-http_memcached_module > > --without-http_empty_gif_module --without-http_browser_module > > --with-http_ssl_module --with-http_v2_module --with-http_realip_module > > --with-http_mp4_module --with-http_auth_request_module > > --with-http_stub_status_module --with-http_random_index_module > > --with-http_ssl_module --with-http_gunzip_module --with-threads > > --add-module=/usr/local/src/incubator-pagespeed-ngx-1.13.35.2-stable > > --add-module=/usr/local/src/ngx_devel_kit-0.3.1 > > --add-module=/usr/local/src/lua-nginx-module-0.10.9 > > --with-openssl=/usr/local/src/openssl-1.0.2t > > Опции сборки как бы намекают, что проблема - в сторонних модулях. > Попробуйте воспроизвести проблему без них. > > [...] > > -- > 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 Wed Feb 5 12:58:16 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 5 Feb 2020 15:58:16 +0300 Subject: =?UTF-8?B?UmU6INCf0L7RgdC70LUg0YHQsdC+0YDQutC4IG5naW54INC/0LDQtNCw0LXRgiA=?= =?UTF-8?B?0LIgc2lnbmFsIDExPw==?= In-Reply-To: References: <20200205121200.GE12894@mdounin.ru> Message-ID: <20200205125816.GG12894@mdounin.ru> Hello! On Wed, Feb 05, 2020 at 05:50:11PM +0500, Илья Шипицин wrote: > Судя по content_by_lua воспроизвести без сторонних модулей затруднительно Безусловно. В том смысле, что без сторонних модулей - даже если код из Lua переписать на строенном перле или njs - проблема практически наверняка не воспроизведётся. Именно эту мысль я и пытаюсь донести. Там, впрочем, в опциях сборки есть и более простой кандидат на вылет - pagespeed. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Wed Feb 5 13:07:39 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 5 Feb 2020 18:07:39 +0500 Subject: =?UTF-8?B?UmU6INCf0L7RgdC70LUg0YHQsdC+0YDQutC4IG5naW54INC/0LDQtNCw0LXRgiA=?= =?UTF-8?B?0LIgc2lnbmFsIDExPw==?= In-Reply-To: <20200205125816.GG12894@mdounin.ru> References: <20200205121200.GE12894@mdounin.ru> <20200205125816.GG12894@mdounin.ru> Message-ID: Там и lua старенькая On Wed, Feb 5, 2020, 5:58 PM Maxim Dounin wrote: > Hello! > > On Wed, Feb 05, 2020 at 05:50:11PM +0500, Илья Шипицин wrote: > > > Судя по content_by_lua воспроизвести без сторонних модулей затруднительно > > Безусловно. В том смысле, что без сторонних модулей - даже если > код из Lua переписать на строенном перле или njs - проблема > практически наверняка не воспроизведётся. Именно эту мысль я и > пытаюсь донести. > > Там, впрочем, в опциях сборки есть и более простой кандидат на > вылет - pagespeed. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ek на nginx.com Fri Feb 7 11:18:00 2020 From: ek на nginx.com (Ekaterina Kukushkina) Date: Fri, 7 Feb 2020 11:18:00 +0000 Subject: =?UTF-8?B?UmU6IG5naW54INC+0YLQutGA0YvQstCw0LXRgiDQvdC1INGC0YMg0LTQuNGA0LU=?= =?UTF-8?B?0LrRgtC+0YDQuNGO?= In-Reply-To: <838b8b9e7d1332c2a736cd59a1c262f2.NginxMailingListRussian@forum.nginx.org> References: <838b8b9e7d1332c2a736cd59a1c262f2.NginxMailingListRussian@forum.nginx.org> Message-ID: Добрый день. > On 5 Feb 2020, at 11:41, artesah wrote: > > Доброго времени суток, Господа. > Ситуация следующая, после обновления сервера веб сервер начал направлять не > в ту директорию. > Лог: > 2020/02/05 11:28:23 [error] 2329#2329: *7 open() > "/usr/share/nginx/html/zabbix.php" failed (2: No such file or directory), > client: мой ip1, server: localhost, request: "GET /zabbix.php HTTP/1.1", > host: "хост" > > В то время как директория сайта находиться на /usr/share/zabbix > В конфиге /etc/nginx/conf.d/zabbix.conf прописан set $webroot > '/usr/share/zabbix'; > А в основном /etc/nginx/nginx.conf записан include > /etc/nginx/conf.d/zabbix.conf; > > В чем может быть проблема? Скорее всего при обновлении приехал /etc/nginx/conf.d/default.conf Лучше закомментировать его содержимое, а не удалять весь файл. Иначе он будет опять приезжать при каждом апдейте nginx. > Заранее спасибо > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286943,286943#msg-286943 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Ekaterina Kukushkina From nginx-forum на forum.nginx.org Mon Feb 10 02:31:09 2020 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Sun, 09 Feb 2020 21:31:09 -0500 Subject: =?UTF-8?B?YWRkIGhlYWRlciDQuCBsb2cgZm9ybWF0INC90LUg0LLQuNC00Y/RgiDRh9Cw0YE=?= =?UTF-8?B?0YLRjCDQv9C10YDQtdC80LXQvdC90YvRhSAkc3NsIHh4?= Message-ID: <38aa7946446d9e5a61b848099922afb1.NginxMailingListRussian@forum.nginx.org> Имеется Nginx: nginx version: nginx/1.17.8 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with BoringSSL) TLS SNI support enabled В настройках указано: add_header X-SSLEarly $ssl_early_data always; add_header X-SSLSerial $ssl_client_serial always; add_header X-SSLCipher $ssl_cipher always; add_header X-SSLVStart $ssl_client_v_start always; add_header X-SSLProto $ssl_protocol always; add_header X-SNIName $ssl_server_name always; add_header X-SSLSessID $ssl_session_id always; Однако заголовки ответа содержат не всё: x-sslcipher: TLS_CHACHA20_POLY1305_SHA256 x-sslproto: TLSv1.3 x-sniname: www.test.lan Во-вторых, формат логов настроен так: log_format test "$ssl_protocol" "$ssl_server_name" "$ssl_early_data" "$ssl_session_reused" "$ssl_cipher"'; В документации написано, что $ssl_early_data содержит либо 1, либо пустую строку, однако в логи пишется "-": "TLSv1.3" "www.test.lan" "-" "." "TLS_CHACHA20_POLY1305_SHA256" Хотя SSL Early Data включён и работает (проверено через sslyze, количество воркеров специально уменьшено до одного). Вопрос: почему add_header и log_format видят не все переменные, и что надо сделать, чтобы увидели? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286982,286982#msg-286982 From mdounin на mdounin.ru Mon Feb 10 14:24:06 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 10 Feb 2020 17:24:06 +0300 Subject: =?UTF-8?B?UmU6IGFkZCBoZWFkZXIg0LggbG9nIGZvcm1hdCDQvdC1INCy0LjQtNGP0YIg0Yc=?= =?UTF-8?B?0LDRgdGC0Ywg0L/QtdGA0LXQvNC10L3QvdGL0YUgJHNzbCB4eA==?= In-Reply-To: <38aa7946446d9e5a61b848099922afb1.NginxMailingListRussian@forum.nginx.org> References: <38aa7946446d9e5a61b848099922afb1.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200210142406.GK12894@mdounin.ru> Hello! On Sun, Feb 09, 2020 at 09:31:09PM -0500, Ilya Evseev wrote: > Имеется Nginx: > > nginx version: nginx/1.17.8 > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) > built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with > BoringSSL) > TLS SNI support enabled > > В настройках указано: > > add_header X-SSLEarly $ssl_early_data always; > add_header X-SSLSerial $ssl_client_serial always; > add_header X-SSLCipher $ssl_cipher always; > add_header X-SSLVStart $ssl_client_v_start always; > add_header X-SSLProto $ssl_protocol always; > add_header X-SNIName $ssl_server_name always; > add_header X-SSLSessID $ssl_session_id always; > > Однако заголовки ответа содержат не всё: > > x-sslcipher: TLS_CHACHA20_POLY1305_SHA256 > x-sslproto: TLSv1.3 > x-sniname: www.test.lan Директива add_header не добавляет заголовки с пустым содержимым. Соответственно, в приведённом примере переменные $ssl_early_data, $ssl_client_serial, $ssl_client_v_start и $ssl_session_id - пустые. > Во-вторых, формат логов настроен так: > > log_format test "$ssl_protocol" "$ssl_server_name" "$ssl_early_data" > "$ssl_session_reused" "$ssl_cipher"'; > > В документации написано, что $ssl_early_data содержит либо 1, либо пустую > строку, однако в логи пишется "-": > > "TLSv1.3" "www.test.lan" "-" "." "TLS_CHACHA20_POLY1305_SHA256" > > Хотя SSL Early Data включён и работает (проверено через sslyze, количество > воркеров специально уменьшено до одного). Переменная $ssl_early_data будет непустой тогда и только тогда, когда на момент обращения к этой переменной SSL handshake не завершён. В первую очередь она предназначена для использования при формировании заголовка Early-Data для бэкенда (см. http://nginx.org/r/ssl_early_data). В момент логгирования - SSL handshake с высокой вероятностью будет уже завершён, если только речь не идёт про совсем простые ответы от собственно nginx'а. Соответственно нет ничего удивительного в том, что в момент логгирования переменная пустая. Если хочется логгировать факт использования early data в запросе независимо от текущего статуса handshake'а - то наиболее близкое по смыслу значение можно получить, сохраняя значение переменной $ssl_early_data на этапе поиска конфигурации для запроса с помощью директивы set. Что до значения "-" вместо пустой строки при логгировании, то это историческая особенность логгирования: "-" используется вместо переменных, значения которых не найдены, что и происходит в случае пустого значения $ssl_early_data. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Feb 11 10:15:24 2020 From: nginx-forum на forum.nginx.org (yanda.a) Date: Tue, 11 Feb 2020 05:15:24 -0500 Subject: =?UTF-8?B?UmU6IGFkZCBoZWFkZXIg0LggbG9nIGZvcm1hdCDQvdC1INCy0LjQtNGP0YIg0Yc=?= =?UTF-8?B?0LDRgdGC0Ywg0L/QtdGA0LXQvNC10L3QvdGL0YUgJHNzbCB4eA==?= In-Reply-To: <20200210142406.GK12894@mdounin.ru> References: <20200210142406.GK12894@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Если хочется логгировать факт использования early data в запросе > независимо от текущего статуса handshake'а - то наиболее близкое > по смыслу значение можно получить, сохраняя значение переменной > $ssl_early_data на этапе поиска конфигурации для запроса с помощью > директивы set. Добрый день! Подскажите, а как это будет работать с внутренним редиректом? Если я все верно понимаю, то при внутреннем редиректе rewrite-phase отработает еще раз, после чего мы получим не совсем верное значение. Или это не совсем верно? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286985,286989#msg-286989 From mdounin на mdounin.ru Tue Feb 11 15:19:23 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 11 Feb 2020 18:19:23 +0300 Subject: =?UTF-8?B?UmU6IGFkZCBoZWFkZXIg0LggbG9nIGZvcm1hdCDQvdC1INCy0LjQtNGP0YIg0Yc=?= =?UTF-8?B?0LDRgdGC0Ywg0L/QtdGA0LXQvNC10L3QvdGL0YUgJHNzbCB4eA==?= In-Reply-To: References: <20200210142406.GK12894@mdounin.ru> Message-ID: <20200211151923.GP12894@mdounin.ru> Hello! On Tue, Feb 11, 2020 at 05:15:24AM -0500, yanda.a wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Если хочется логгировать факт использования early data в запросе > > независимо от текущего статуса handshake'а - то наиболее близкое > > по смыслу значение можно получить, сохраняя значение переменной > > $ssl_early_data на этапе поиска конфигурации для запроса с помощью > > директивы set. > > Добрый день! Подскажите, а как это будет работать с внутренним редиректом? > Если я все верно понимаю, то при внутреннем редиректе rewrite-phase > отработает еще раз, после чего мы получим не совсем верное значение. Или это > не совсем верно? Если речь идёт о внутренних перенаправлениях в рамках исходной обработки запроса, без ожидания внешних событий (e.g., в рамках директивы index) - то разницы нет, так как значение $ssl_early_data будет тем же самым. Если речь про перенаправления после общения с бэкендом (e.g., с помощью X-Accel-Redirect), то может потребоваться чуть более сложная логика, чем просто set. Скажем, какая-то такая конструкция будет сохранять значение 1, если оно единожды встретилось: uninitialized_variable_warn off; if ($early = "") { set $early $ssl_early_data; } Либо можно использовать map, воспользовавшись тем, что он кэширует результат при первом обращении: map $ssl_early_data $early { default 0; 1 1; } server { ... set $dummy $early; ... } -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Feb 19 11:46:21 2020 From: nginx-forum на forum.nginx.org (sergius_anp) Date: Wed, 19 Feb 2020 06:46:21 -0500 Subject: =?UTF-8?B?0JrQsNC6INC30LDRgdGC0LDQstC40YLRjCBuZ2lueCDRgNC10LTQuNGA0LXQutGC?= =?UTF-8?B?0LjRgtGMIGh0dHBzINC90LAgaHR0cCwg0LjQu9C4INC90LUg0YDQsNCx0L4=?= =?UTF-8?B?0YLQsNC10YIgaWZyYW1l?= Message-ID: <7ebc8c0787580cc38c3ae42a8d67234a.NginxMailingListRussian@forum.nginx.org> Доброго времени суток всем! Я новичок! Недавно столкнулся с проблемой, которая уже 3 день не дает мне покоя. Вводные: centos 7 + nginx + php72 + wordpress, сайт работает все редиректы (www - /; http - https) выполняются, но стоит задача через iframe добавить на сайт веб-приложение, работающее с этого же сервера по адресу http://127.0.0.1:8085 Но т.к. веб-приложение ходит по http сайт работающий по https страницу не открывает, ругаясь на отсутствие SSL сертификата. То есть https://mydomain.ru/stranica на странице и он не показывает. Пробовал запускать на другом сайте, который работал по http - все нормально запустилось и работало. мой nginx.conf server { listen 80; server_name mydomain.ru; root /var/www/mydomain.ru/www/; index index.php index.html index.htm; access_log /var/www/mydomain.ru/www/log/access.log main; error_log /var/www/mydomain.ru/www/log/error.log; location / { return 301 https://mydomain.ru$request_uri; } location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { return 301 https://mydomain.ru$request_uri; } location ~ \.php$ { return 301 https://mydomain.ru$request_uri; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { rewrite ^ /robots.txt break; allow all; log_not_found off; access_log off; } location ~ /\.ht { deny all; } } server { listen 80; server_name www.mydomain.ru; rewrite ^ https://mydomainru$request_uri? permanent; } server { listen 443 ssl http2; server_name mydomain.ru; root /var/wwwmydomain.ru/www/; index index.php index.html index.htm; access_log /var/www/mydomain.ru/www/log/ssl-access.log main; error_log /var/www/mydomain.ru/www/log/ssl-error.log; keepalive_timeout 60; ssl_certificate /etc/letsencrypt/live/mydomain.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/mydomain.ru/privkey.pem; 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:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; add_header Strict-Transport-Security 'max-age=604800'; location / { try_files $uri $uri/ /index.php?$args; } location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { access_log off; expires max; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php72-fpm.sock; #fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /var/www/mydomain.ru/www/; fastcgi_param SCRIPT_FILENAME /var/www/mydomain.ru/www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /var/www/mydomain.ru/www$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param HTTPS on; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ /\.ht { deny all; } } server { listen 443 ssl http2; server_name www.mydomain.ru; rewrite ^ https://mydomain.ru$request_uri? permanent; Помогите, укажите перстом куда и чего написать чтобы все работало нормально? Почитав интернеты понял что дело точно в https to http, вот только как его правильно сделать применимо к моему конфигу не пойму. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287055,287055#msg-287055 From shadow.tehb на gmail.com Wed Feb 19 11:53:40 2020 From: shadow.tehb на gmail.com (=?utf-8?B?0KHQtdGA0LPQtdC5INCi0YPRgNCz0YPQt9C+0LI=?=) Date: Wed, 19 Feb 2020 14:53:40 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0YHRgtCw0LLQuNGC0Ywgbmdpbngg0YDQtdC00LjRgNC1?= =?UTF-8?B?0LrRgtC40YLRjCBodHRwcyDQvdCwIGh0dHAsINC40LvQuCDQvdC1INGA0LA=?= =?UTF-8?B?0LHQvtGC0LDQtdGCIGlmcmFtZQ==?= In-Reply-To: <7ebc8c0787580cc38c3ae42a8d67234a.NginxMailingListRussian@forum.nginx.org> References: <7ebc8c0787580cc38c3ae42a8d67234a.NginxMailingListRussian@forum.nginx.org> Message-ID: <2B73456E-3B9F-4003-95E2-712F3BD90387@gmail.com> Идея такая: Вместо http://127.0.0.1:8085 напиши https://mydomain.ru/stranica-src . И location /stranica-src { proxy-pass http://127.0.0.1:8085 ; } > 19 февр. 2020 г., в 14:46, sergius_anp написал(а): > > Доброго времени суток всем! Я новичок! Недавно столкнулся с проблемой, > которая уже 3 день не дает мне покоя. > Вводные: centos 7 + nginx + php72 + wordpress, сайт работает все редиректы > (www - /; http - https) выполняются, но стоит задача через iframe добавить > на сайт веб-приложение, работающее с этого же сервера по адресу > http://127.0.0.1:8085 > Но т.к. веб-приложение ходит по http сайт работающий по https страницу не > открывает, ругаясь на отсутствие SSL сертификата. > То есть https://mydomain.ru/stranica на странице и он не показывает. Пробовал > запускать на другом сайте, который работал по http - все нормально > запустилось и работало. > мой nginx.conf > > server { > listen 80; > server_name mydomain.ru; > root /var/www/mydomain.ru/www/; > index index.php index.html index.htm; > access_log /var/www/mydomain.ru/www/log/access.log main; > error_log /var/www/mydomain.ru/www/log/error.log; > > location / { > return 301 https://mydomain.ru$request_uri; > } > > location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { > return 301 https://mydomain.ru$request_uri; > } > > location ~ \.php$ { > return 301 https://mydomain.ru$request_uri; > } > > location = /favicon.ico { > log_not_found off; > access_log off; > } > > location = /robots.txt { > rewrite ^ /robots.txt break; > allow all; > log_not_found off; > access_log off; > } > > location ~ /\.ht { > deny all; > } > } > > server { > listen 80; > server_name www.mydomain.ru; > rewrite ^ https://mydomainru$request_uri? permanent; > } > > server { > listen 443 ssl http2; > server_name mydomain.ru; > root /var/wwwmydomain.ru/www/; > index index.php index.html index.htm; > access_log /var/www/mydomain.ru/www/log/ssl-access.log main; > error_log /var/www/mydomain.ru/www/log/ssl-error.log; > > keepalive_timeout 60; > ssl_certificate > /etc/letsencrypt/live/mydomain.ru/fullchain.pem; > ssl_certificate_key > /etc/letsencrypt/live/mydomain.ru/privkey.pem; > 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:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; > ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; > add_header Strict-Transport-Security 'max-age=604800'; > > location / { > try_files $uri $uri/ /index.php?$args; > } > > location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { > access_log off; > expires max; > } > > location ~ \.php$ { > try_files $uri =404; > fastcgi_pass unix:/var/run/php72-fpm.sock; > #fastcgi_pass 127.0.0.1:9000; > fastcgi_index index.php; > fastcgi_param DOCUMENT_ROOT /var/www/mydomain.ru/www/; > fastcgi_param SCRIPT_FILENAME > /var/www/mydomain.ru/www$fastcgi_script_name; > fastcgi_param PATH_TRANSLATED > /var/www/mydomain.ru/www$fastcgi_script_name; > include fastcgi_params; > fastcgi_param QUERY_STRING $query_string; > fastcgi_param REQUEST_METHOD $request_method; > fastcgi_param CONTENT_TYPE $content_type; > fastcgi_param CONTENT_LENGTH $content_length; > fastcgi_param HTTPS on; > fastcgi_intercept_errors on; > fastcgi_ignore_client_abort off; > fastcgi_connect_timeout 60; > fastcgi_send_timeout 180; > fastcgi_read_timeout 180; > fastcgi_buffer_size 128k; > fastcgi_buffers 4 256k; > fastcgi_busy_buffers_size 256k; > fastcgi_temp_file_write_size 256k; > } > > location = /favicon.ico { > log_not_found off; > access_log off; > } > > location = /robots.txt { > allow all; > log_not_found off; > access_log off; > } > > location = /robots.txt { > allow all; > log_not_found off; > access_log off; > } > > location ~ /\.ht { > deny all; > } > } > > server { > listen 443 ssl http2; > server_name www.mydomain.ru; > rewrite ^ https://mydomain.ru$request_uri? permanent; > > Помогите, укажите перстом куда и чего написать чтобы все работало нормально? > Почитав интернеты понял что дело точно в https to http, вот только как его > правильно сделать применимо к моему конфигу не пойму. > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287055,287055#msg-287055 > > _______________________________________________ > 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 Feb 19 12:49:58 2020 From: nginx-forum на forum.nginx.org (sergius_anp) Date: Wed, 19 Feb 2020 07:49:58 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0YHRgtCw0LLQuNGC0Ywgbmdpbngg0YDQtdC00LjRgNC1?= =?UTF-8?B?0LrRgtC40YLRjCBodHRwcyDQvdCwIGh0dHAsINC40LvQuCDQvdC1INGA0LA=?= =?UTF-8?B?0LHQvtGC0LDQtdGCIGlmcmFtZQ==?= In-Reply-To: <2B73456E-3B9F-4003-95E2-712F3BD90387@gmail.com> References: <2B73456E-3B9F-4003-95E2-712F3BD90387@gmail.com> Message-ID: <2c44318449bee9ff505320203f50fa1c.NginxMailingListRussian@forum.nginx.org> Спасибо за оперативность! Добавил в conf файл запись location /stranica { proxy_pass http://172.16.0.68:8085; #это реальный адрес и порт сервера proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; } Теперь на странице новое изображение, но тоже ничего хорошего =( error-404 Page not found. Lets go to home Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287055,287057#msg-287057 From shadow.tehb на gmail.com Wed Feb 19 12:57:18 2020 From: shadow.tehb на gmail.com (=?utf-8?B?0KHQtdGA0LPQtdC5INCi0YPRgNCz0YPQt9C+0LI=?=) Date: Wed, 19 Feb 2020 15:57:18 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0YHRgtCw0LLQuNGC0Ywgbmdpbngg0YDQtdC00LjRgNC1?= =?UTF-8?B?0LrRgtC40YLRjCBodHRwcyDQvdCwIGh0dHAsINC40LvQuCDQvdC1INGA0LA=?= =?UTF-8?B?0LHQvtGC0LDQtdGCIGlmcmFtZQ==?= In-Reply-To: <2c44318449bee9ff505320203f50fa1c.NginxMailingListRussian@forum.nginx.org> References: <2B73456E-3B9F-4003-95E2-712F3BD90387@gmail.com> <2c44318449bee9ff505320203f50fa1c.NginxMailingListRussian@forum.nginx.org> Message-ID: А где страница с html кодом для iframe? Я не просто так изменил название страницы. P.s. location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { return 301 https://mydomain.ru$request_uri; } location ~ \.php$ { return 301 https://mydomain.ru$request_uri; } Вот это лишнее. > 19 февр. 2020 г., в 15:49, sergius_anp написал(а): > > Спасибо за оперативность! > Добавил в conf файл запись > location /stranica { > proxy_pass http://172.16.0.68:8085; #это реальный адрес и порт > сервера > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_set_header Host $http_host; > } > Теперь на странице новое изображение, но тоже ничего хорошего =( > > error-404 > Page not found. > Lets go to home > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287055,287057#msg-287057 > > _______________________________________________ > 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 Feb 19 14:01:08 2020 From: nginx-forum на forum.nginx.org (sergius_anp) Date: Wed, 19 Feb 2020 09:01:08 -0500 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQt9Cw0YHRgtCw0LLQuNGC0Ywgbmdpbngg0YDQtdC00LjRgNC1?= =?UTF-8?B?0LrRgtC40YLRjCBodHRwcyDQvdCwIGh0dHAsINC40LvQuCDQvdC1INGA0LA=?= =?UTF-8?B?0LHQvtGC0LDQtdGCIGlmcmFtZQ==?= In-Reply-To: References: Message-ID: <1218f48926f4991041561e1e56e79a12.NginxMailingListRussian@forum.nginx.org> Опишите подробнее логику, я не пойму зачем переименовывать страницу в stranica-src или делать еще одну? У меня есть страница stranica и в ней код с iframe. Прописав location server { { proxy-pass http://127.0.0.1:8085 listen 443 ssl http2; вывода было 2 или 404 или пропадал весь сайт. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287055,287060#msg-287060 From nginx-forum на forum.nginx.org Fri Feb 21 19:19:07 2020 From: nginx-forum на forum.nginx.org (mikhal123) Date: Fri, 21 Feb 2020 14:19:07 -0500 Subject: [crit] SSL_read_early_data() failed Message-ID: Включил на своём сервере опцию "ssl_early_data". Всё вроде бы хорошо, но в error.log довольно много (порядка 0.5% от общего числа запросов, что на трафике в миллион уже немного напрягает) записей вида: [crit] 11016#11016: *46796 SSL_read_early_data() failed (SSL: error:1423D06E:SSL routines:tls_parse_ctos_server_name:bad extension) while SSL handshaking, client: , server: 0.0.0.0:443 В связи с этим хотелось бы узнать: 1. Правильно ли я понимаю, что это проблемы со стороны клиентов (слишком старые клиенты?), и на сервере невозможно что-либо поделать для исправления этой ситуации? 2. Если так, то с какой целью данное извещение выводится с таким высоким уровнем приоритета (crit) 3. Можно ли как-то отключить вывод данного извещения (например, понизив его приоритет до warn) в логи для приведения их в прежний благопристойный вид? nginx -V nginx version: nginx/1.17.8 built by gcc 8.3.0 (Debian 8.3.0-6) built with OpenSSL 1.1.1d 10 Sep 2019 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_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-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.17.8/debian/debuild-base/nginx-1.17.8=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie' Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287080,287080#msg-287080 From pluknet на nginx.com Sat Feb 22 15:12:09 2020 From: pluknet на nginx.com (Sergey Kandaurov) Date: Sat, 22 Feb 2020 18:12:09 +0300 Subject: [crit] SSL_read_early_data() failed In-Reply-To: References: Message-ID: <5637FD0E-6E36-4D83-AC0A-E751CAD38E52@nginx.com> > On 21 Feb 2020, at 22:19, mikhal123 wrote: > > Включил на своём сервере опцию "ssl_early_data". Всё вроде бы хорошо, но в > error.log довольно много (порядка 0.5% от общего числа запросов, что на > трафике в миллион уже немного напрягает) записей вида: > [crit] 11016#11016: *46796 SSL_read_early_data() failed (SSL: > error:1423D06E:SSL routines:tls_parse_ctos_server_name:bad extension) while > SSL handshaking, client: , server: 0.0.0.0:443 > Было бы интересно посмотреть, что конкретно там прилетает. > В связи с этим хотелось бы узнать: > 1. Правильно ли я понимаю, что это проблемы со стороны клиентов (слишком > старые клиенты?), и на сервере невозможно что-либо поделать для исправления > этой ситуации? Верно. Так происходит, например, если получен испорченный SNI: плохой тип и/или длина значения, нулевые байты в значении, плохой формат. > 2. Если так, то с какой целью данное извещение выводится с таким высоким > уровнем приоритета (crit) Так происходит по умолчанию, чтобы не пропустить ничего важного. > 3. Можно ли как-то отключить вывод данного извещения (например, понизив его > приоритет до warn) в логи для приведения их в прежний благопристойный вид? > Можно попробовать патч, понижающий уровень: # HG changeset patch # User Sergey Kandaurov # Date 1582383432 -10800 # Sat Feb 22 17:57:12 2020 +0300 # Node ID ffb1eaf3bd88886233d941e531d68785671ae457 # Parent 72b792bb3885727bf381d4c4e66cfaf754ac7a59 SSL: logging level of "bad extension". The "bad extension" errors are reported by OpenSSL 1.1.1 if an invalid servername extension value is received. diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c --- a/src/event/ngx_event_openssl.c +++ b/src/event/ngx_event_openssl.c @@ -2896,6 +2896,9 @@ ngx_ssl_connection_error(ngx_connection_ #ifdef SSL_R_NO_SUITABLE_KEY_SHARE || n == SSL_R_NO_SUITABLE_KEY_SHARE /* 101 */ #endif +#ifdef SSL_R_BAD_EXTENSION + || n == SSL_R_BAD_EXTENSION /* 110 */ +#endif #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM /* 118 */ #endif Или конкретно для SNI: diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c --- a/src/event/ngx_event_openssl.c +++ b/src/event/ngx_event_openssl.c @@ -2896,6 +2896,11 @@ ngx_ssl_connection_error(ngx_connection_ #ifdef SSL_R_NO_SUITABLE_KEY_SHARE || n == SSL_R_NO_SUITABLE_KEY_SHARE /* 101 */ #endif +#ifdef SSL_R_BAD_EXTENSION + || (n == SSL_R_BAD_EXTENSION /* 100 */ + && ERR_GET_FUNC(ERR_peek_error()) + == SSL_F_TLS_PARSE_CTOS_SERVER_NAME) +#endif #ifdef SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM || n == SSL_R_NO_SUITABLE_SIGNATURE_ALGORITHM /* 118 */ #endif -- Sergey Kandaurov From nginx-forum на forum.nginx.org Sun Feb 23 18:07:23 2020 From: nginx-forum на forum.nginx.org (mikhal123) Date: Sun, 23 Feb 2020 13:07:23 -0500 Subject: [crit] SSL_read_early_data() failed In-Reply-To: <5637FD0E-6E36-4D83-AC0A-E751CAD38E52@nginx.com> References: <5637FD0E-6E36-4D83-AC0A-E751CAD38E52@nginx.com> Message-ID: > > [crit] 11016#11016: *46796 SSL_read_early_data() failed (SSL:error:1423D06E:SSL routines:tls_parse_ctos_server_name:bad extension) while SSL handshaking, client: , server: 0.0.0.0:443 > Было бы интересно посмотреть, что конкретно там прилетает. Каким образом можно это сделать? nginx-debug записывает отладочный лог до такой степени детализации? > > 2. Если так, то с какой целью данное извещение выводится с таким высоким уровнем приоритета (crit) > Так происходит по умолчанию, чтобы не пропустить ничего важного. > > 3. Можно ли как-то отключить вывод данного извещения (например, понизив его приоритет до warn) в логи для приведения их в прежний благопристойный вид? > Можно попробовать патч, понижающий уровень: Патч наверняка сработает, но пара тысяч ненужных записей в логах в день не перевешивают необходимости собрать nginx самому и потом патчить его заново при выходе каждой следующей версии. Может быть, команда разработчиков рассмотрит возможность добавления директивы переопределения пользователем уровня ошибок, по аналогии например с http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req_log_level ? Или я единственный админ, который недоумевает что там может быть такого важного при установке ssl-соединения, раз я всё равно никак не могу повлиять на повторное возникновение этих же ошибок Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287080,287093#msg-287093 From sytar.alex на gmail.com Tue Feb 25 07:13:21 2020 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Tue, 25 Feb 2020 10:13:21 +0300 Subject: [crit] SSL_read_early_data() failed In-Reply-To: References: <5637FD0E-6E36-4D83-AC0A-E751CAD38E52@nginx.com> Message-ID: вс, 23 февр. 2020 г. в 21:07, mikhal123 : > Может быть, команда разработчиков > рассмотрит возможность добавления директивы переопределения пользователем > уровня ошибок, по аналогии например с > > http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req_log_level > ? > Обычно ребята предлагают протестировать подобные штуки, тем более что ты тот клиент кто может верифицировать - помогает патч или нет. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Tue Feb 25 17:33:32 2020 From: nginx-forum на forum.nginx.org (mikhal123) Date: Tue, 25 Feb 2020 12:33:32 -0500 Subject: [crit] SSL_read_early_data() failed In-Reply-To: References: Message-ID: <184571d77de48ec6262ae5e78983657e.NginxMailingListRussian@forum.nginx.org> > > Может быть, команда разработчиков рассмотрит возможность добавления директивы переопределения пользователем уровня ошибок, по аналогии например с http://nginx.org/ru/docs/http/ngx_http_limit_req_module.html#limit_req_log_level ? > Обычно ребята предлагают протестировать подобные штуки, тем более что ты тот клиент кто может верифицировать - помогает патч или нет. Можешь смело считать что я протестировал предлагаемый патч, и он работает. Но вот здесь определено ещё 100500 кодов ошибок (и будут появляться новые), о которых nginx в настоящее время ничего не знает и считает по-умолчанию критическими https://github.com/openssl/openssl/blob/6d53ad6b5cf726d92860e973d7bc8c1930762086/include/openssl/sslerr.h#L464 Наверное, есть какая-то логика обучать nginx по одной ошибке за раз, но от меня она ускользает :) Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287080,287103#msg-287103 From nginx-ru на sadok.spb.ru Wed Feb 26 18:56:58 2020 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Wed, 26 Feb 2020 21:56:58 +0300 Subject: forum.nginx.org Message-ID: <1083868481.20200226215658@sadok.spb.ru> Здравствуйте, All. forum.nginx.org - сертификат просрочен. Действителен по 23.02.2020, 03:24:07 (Europe/Moscow) -- С уважением, Dmitry From sytar.alex на gmail.com Wed Feb 26 20:54:45 2020 From: sytar.alex на gmail.com (Aleksandr Sytar) Date: Wed, 26 Feb 2020 23:54:45 +0300 Subject: forum.nginx.org In-Reply-To: <1083868481.20200226215658@sadok.spb.ru> References: <1083868481.20200226215658@sadok.spb.ru> Message-ID: ср, 26 февр. 2020 г. в 21:57, Dmitry Ivanov : > Здравствуйте, All. > > forum.nginx.org - сертификат просрочен. Действителен по > 23.02.2020, 03:24:07 (Europe/Moscow) > > > Да там и список cname в сертификате прикольный. @Dmitry - форум это просто веб-морда к почтовой рассылке - можно подписаться на странице - http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-ru на sadok.spb.ru Wed Feb 26 21:08:42 2020 From: nginx-ru на sadok.spb.ru (Dmitry Ivanov) Date: Thu, 27 Feb 2020 00:08:42 +0300 Subject: forum.nginx.org In-Reply-To: References: <1083868481.20200226215658@sadok.spb.ru> Message-ID: <428193329.20200227000842@sadok.spb.ru> Здравствуйте, Aleksandr. > @Dmitry - форум это просто веб-морда к почтовой рассылке - можно > подписаться на странице - > http://mailman.nginx.org/mailman/listinfo/nginx-ru Я в рассылке и читаю. А с форума тяну RSS -- С уважением, Dmitry nginx-ru на sadok.spb.ru From kpoxa на kpoxa.net Thu Feb 27 10:08:47 2020 From: kpoxa на kpoxa.net (kpoxa) Date: Thu, 27 Feb 2020 13:08:47 +0300 Subject: =?UTF-8?B?0JvQvtCz0LPQuNGA0L7QstCw0L3QuNC1INC60L7QvdC90LXQutGC0L7QsiDQsdC1?= =?UTF-8?B?0Lcg0LfQsNC/0YDQvtGB0L7Qsg==?= Message-ID: Добрый день. Браузеры часто делают коннекты без запросов, которые выглядят как "а ну ка я сделаю коннект, мало ли что надо будет.. не.. не понадобилось, разрываю коннект" и информации об этом коннекте в access_log конечно же нет, но логгировать такие коннекты надо. Как это можно сделать? Если писать свой модуль, то в какой обработчик придёт подобная информация? -- Рустам. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin на mdounin.ru Thu Feb 27 12:09:19 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 27 Feb 2020 15:09:19 +0300 Subject: forum.nginx.org In-Reply-To: <428193329.20200227000842@sadok.spb.ru> References: <1083868481.20200226215658@sadok.spb.ru> <428193329.20200227000842@sadok.spb.ru> Message-ID: <20200227120919.GE12894@mdounin.ru> Hello! On Thu, Feb 27, 2020 at 12:08:42AM +0300, Dmitry Ivanov wrote: > Здравствуйте, Aleksandr. > > > @Dmitry - форум это просто веб-морда к почтовой рассылке - можно > > подписаться на странице - > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > Я в рассылке и читаю. А с форума тяну RSS Форум - поддерживается не нами, его держит Jim Ohlstein. Соответственно писать о проблемах форума в русскую рассылку - приблизительно полностью бесполезно. Мы со своей стороны - в связи с неоднократными проблемами уже давно выпилили все ссылки с nginx.org на форум. Можем и DNS убрать, но наверное это не совсем то, что хотят люди, использующие форум хоть как-то. В данном случае, кажется, правильным решением было бы прикрутить RSS к mailman'у. Нативно он, похоже, не умеет, но гуглятся всякие сторонние решения: https://pypi.org/project/mailman-rss/ Кто-нибудь пробовал? -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Thu Feb 27 12:22:45 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 27 Feb 2020 15:22:45 +0300 Subject: =?UTF-8?B?UmU6INCb0L7Qs9Cz0LjRgNC+0LLQsNC90LjQtSDQutC+0L3QvdC10LrRgtC+0LIg?= =?UTF-8?B?0LHQtdC3INC30LDQv9GA0L7RgdC+0LI=?= In-Reply-To: References: Message-ID: <20200227122245.GF12894@mdounin.ru> Hello! On Thu, Feb 27, 2020 at 01:08:47PM +0300, kpoxa wrote: > Браузеры часто делают коннекты без запросов, которые выглядят как "а ну ка > я сделаю коннект, мало ли что надо будет.. не.. не понадобилось, разрываю > коннект" > и информации об этом коннекте в access_log конечно же нет, но логгировать > такие коннекты надо. Как это можно сделать? > Если писать свой модуль, то в какой обработчик придёт подобная информация? Сейчас для http эта информация есть только на уровне debug log'а. И в своём модуле - её тоже никак не получить, модули в http начинают работать только после получения заголовков запроса. Мы пару раз задумывались над вопросом "а не добавить ли строчку в error log на уровне info?", вида "client X connected to Y", аналогично тому, что делается в mail и stream. Но пока нет разумного ответа на вопрос "а надо ли это вообще кому-то". -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Thu Feb 27 20:24:27 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Thu, 27 Feb 2020 15:24:27 -0500 Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQv9C10YDQtdC30LDQv9GD0YHQutC+0Lwg0LIg?= =?UTF-8?B?Y2VudG9zIDg=?= Message-ID: Добрый день! Обновился на centos8 и столкнулся с проблемой: После ребута системы, сервис nginx не стартует автоматически из за ошибки: nginx: [emerg] host not found in upstream, апстрим на амазоне вида: site-0000000.eu-central-1.elb.amazonaws.com, на centos 7/6 такой проблемы не было. Пробовал для интереса убирать этот апстрим, но он не стартует и ругается уже на внутренние линки содержащие доменные имена, например nginx: [emerg] host not found in upstream, example.com После того как сервер загрузился, nginx -t и service start - без проблем работают... Что это за проблема? Как ее решить? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287141#msg-287141 From chipitsine на gmail.com Thu Feb 27 20:56:33 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Feb 2020 01:56:33 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: то, что у вас работало на centos 6/7 это случайность. скажем, by chance. причины работать или не работать одинаковые - в момент чтения конфига nginx ресолвит все днс имена в IP адреса и далее работает уже с IP адресами (у вас будут проблемы, если на ELB поменяется адрес) если не ресолвит, то это emerg. что вы и видите в логе. из каких-то простых вещей, которые приходят в голову, посмотрите After и Wants в юните ? After=network-online.target remote-fs.target nss-lookup.target Wants=network-online.target возможно (я не проверял), пакет под RHEL8 собран с такими зависимостями, что он запускается раньше, чем network-online, в то время, когда ресолвера еще нет. из "фокусов", вы можете проксировать на переменную. и для бесплатного nginx это единственный вариант динамического ресолва на ELB пт, 28 февр. 2020 г. в 01:24, windos321 : > Добрый день! > Обновился на centos8 и столкнулся с проблемой: > После ребута системы, сервис nginx не стартует автоматически из за ошибки: > nginx: [emerg] host not found in upstream, > апстрим на амазоне вида: site-0000000.eu-central-1.elb.amazonaws.com, на > centos 7/6 такой проблемы не было. > Пробовал для интереса убирать этот апстрим, но он не стартует и ругается > уже > на внутренние линки содержащие доменные имена, например nginx: [emerg] host > not found in upstream, example.com > > После того как сервер загрузился, nginx -t и service start - без проблем > работают... > Что это за проблема? Как ее решить? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287141,287141#msg-287141 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From shadow.tehb на gmail.com Fri Feb 28 02:59:46 2020 From: shadow.tehb на gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCe0LvQtdCz0L7QstC40Yc=?=) Date: Fri, 28 Feb 2020 05:59:46 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: <17089bc50e8.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> А банальный пинг из консоли центося проходит? "windos321" 27 февраля 2020 г. 23:24:36 написал: > Добрый день! > Обновился на centos8 и столкнулся с проблемой: > После ребута системы, сервис nginx не стартует автоматически из за ошибки: > nginx: [emerg] host not found in upstream, > апстрим на амазоне вида: site-0000000.eu-central-1.elb.amazonaws.com, на > centos 7/6 такой проблемы не было. > Пробовал для интереса убирать этот апстрим, но он не стартует и ругается уже > на внутренние линки содержащие доменные имена, например nginx: [emerg] host > not found in upstream, example.com > > После того как сервер загрузился, nginx -t и service start - без проблем > работают... > Что это за проблема? Как ее решить? > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287141,287141#msg-287141 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From nginx-forum на forum.nginx.org Fri Feb 28 06:12:30 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 01:12:30 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> Спасибо! Тут нужно пояснить, nginx собираю всегда сам и схема сборки не изменилась, пробовал 17.7 и 16.1... Но изменился unit! На os 6 / 7 работал этот юнит: https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginxinit/ и все было ок...Но на centos 8 он стал выдавать ошибку...Поэтому я его заменил на стандартный nginx.service из репозитория... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287147#msg-287147 From nginx-forum на forum.nginx.org Fri Feb 28 06:24:24 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 01:24:24 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> Message-ID: <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> windos321 Wrote: ------------------------------------------------------- > Спасибо! > Тут нужно пояснить, nginx собираю всегда сам и схема сборки не > изменилась, пробовал 17.7 и 16.1... > Но изменился unit! На os 6 / 7 работал этот юнит: > https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginx > init/ и все было ок...Но на centos 8 он стал выдавать ошибку...Поэтому > я его заменил на стандартный nginx.service из репозитория... https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginx выдает ошибку: nginx.service: Failed with result 'protocol' да и предложенный вами вариант с переменной мне не подходит, потому-что как вы сказали - может смениться IP, к тому же nginx пишет host not found не только для elb доменов...Он даже даже для обычных доменов такое пишет, host not found example.com Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287148#msg-287148 From chipitsine на gmail.com Fri Feb 28 06:44:30 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Feb 2020 11:44:30 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> Message-ID: пт, 28 февр. 2020 г. в 11:24, windos321 : > windos321 Wrote: > ------------------------------------------------------- > > Спасибо! > > Тут нужно пояснить, nginx собираю всегда сам и схема сборки не > > изменилась, пробовал 17.7 и 16.1... > > Но изменился unit! На os 6 / 7 работал этот юнит: > > https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginx > > init/ и все было ок...Но на centos 8 он стал выдавать ошибку...Поэтому > > я его заменил на стандартный nginx.service из репозитория... > > https://www.nginx.com/resources/wiki/start/topics/examples/redhatnginx > выдает ошибку: nginx.service: Failed with result 'protocol' > то, что написано в приведенных примерах, это SysV скрипт. nginx.service это systemd скрипт. "заменить" одно на другое нельзя, эти штуки для разных механизмов > > да и предложенный вами вариант с переменной мне не подходит, потому-что как > вариант с переменной это set $elb site-0000000.eu-central-1.elb.amazonaws.com; proxy_pass http://$elb; в этом случае ресолв будет происходить во время проксирования. во всех остальных случаях nginx отресолвит имя в IP единожды и далее будет помнить ip адрес > вы сказали - может смениться IP, к тому же nginx пишет host not found не > только для elb доменов...Он даже даже для обычных доменов такое пишет, host > not found example.com > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287141,287148#msg-287148 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From boco на ufanet.ru Fri Feb 28 07:20:47 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Fri, 28 Feb 2020 12:20:47 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200228072045.GS24754@ufanet.ru> On Fri, Feb 28, 2020 at 11:44:30AM +0500, Илья Шипицин wrote: > > да и предложенный вами вариант с переменной мне не подходит > > вариант с переменной это > > set $elb site-0000000.eu-central-1.elb.amazonaws.com; > proxy_pass http://$elb; > > в этом случае ресолв будет происходить во время проксирования. во всех > остальных случаях nginx отресолвит имя в IP единожды и далее будет > помнить ip адрес почему просто не прописать resolver? https://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver -- boco From chipitsine на gmail.com Fri Feb 28 07:26:22 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Feb 2020 12:26:22 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228072045.GS24754@ufanet.ru> References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> <20200228072045.GS24754@ufanet.ru> Message-ID: пт, 28 февр. 2020 г. в 12:21, damir bikmuhametov : > On Fri, Feb 28, 2020 at 11:44:30AM +0500, Илья Шипицин wrote: > > > да и предложенный вами вариант с переменной мне не подходит > > > > вариант с переменной это > > > > set $elb site-0000000.eu-central-1.elb.amazonaws.com; > > proxy_pass http://$elb; > > > > в этом случае ресолв будет происходить во время проксирования. во всех > > остальных случаях nginx отресолвит имя в IP единожды и далее будет > > помнить ip адрес > > почему просто не прописать resolver? > > https://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver прописать ресолвер можно (а в некоторых случаях нужно). а вы думаете, если пропишете ресолвер, то что произойдет ? начнется динамический ресолв днс имен (во время работы) ? > > > -- > boco > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From boco на ufanet.ru Fri Feb 28 07:31:13 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Fri, 28 Feb 2020 12:31:13 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> <20200228072045.GS24754@ufanet.ru> Message-ID: <20200228073113.GT24754@ufanet.ru> On Fri, Feb 28, 2020 at 12:26:22PM +0500, Илья Шипицин wrote: > > почему просто не прописать resolver? > > https://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver > > прописать ресолвер можно (а в некоторых случаях нужно). > а вы думаете, если пропишете ресолвер, то что произойдет ? начнется > динамический ресолв днс имен (во время работы) ? да. описание директивы: === Задаёт серверы DNS, используемые для преобразования имён вышестоящих серверов в адреса, например: ... По умолчанию nginx кэширует ответы, используя значение TTL из ответа. Необязательный параметр valid позволяет это переопределить: === кроме того, именно проблему топикстартера (невозможность отрезолвить ip при старте нгинкс и как следствие отказ стартовать) это решает. проверено. -- boco From chipitsine на gmail.com Fri Feb 28 07:46:41 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Feb 2020 12:46:41 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228073113.GT24754@ufanet.ru> References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> <20200228072045.GS24754@ufanet.ru> <20200228073113.GT24754@ufanet.ru> Message-ID: пт, 28 февр. 2020 г. в 12:31, damir bikmuhametov : > On Fri, Feb 28, 2020 at 12:26:22PM +0500, Илья Шипицин wrote: > > > почему просто не прописать resolver? > > > https://nginx.org/ru/docs/http/ngx_http_core_module.html#resolver > > > > прописать ресолвер можно (а в некоторых случаях нужно). > > а вы думаете, если пропишете ресолвер, то что произойдет ? начнется > > динамический ресолв днс имен (во время работы) ? > > да. описание директивы: > > === > Задаёт серверы DNS, используемые для преобразования имён вышестоящих > серверов в адреса, например: > ... > По умолчанию nginx кэширует ответы, используя значение TTL из ответа. > Необязательный параметр valid позволяет это переопределить: > === > это точно касается имен, на которые вы делаете proxy_pass ? потому что, например, вот https://trac.nginx.org/nginx/ticket/1372?cversion=0&cnum_hist=2 (и это совпадает с тем, что я вижу в коде) > > кроме того, именно проблему топикстартера (невозможность отрезолвить ip > при старте нгинкс и как следствие отказ стартовать) это решает. > проверено. > проблема топикстартера в том, что в момент запуска nginx ресолвер, прописанный в /etc/resolv.conf, недоступен (вероятно, из-за порядка старта сервисов) если бы ресолвер был доступен, проблемы бы не было но указание директивы resolver, про которую вы говорите не помешает (хотя и не решит проблему) > > -- > boco > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From boco на ufanet.ru Fri Feb 28 08:15:21 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Fri, 28 Feb 2020 13:15:21 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: <5622fa36398f4afca898cc8230a6d87d.NginxMailingListRussian@forum.nginx.org> <8ebfc55238b6716b6a31dce38b7b95d3.NginxMailingListRussian@forum.nginx.org> <20200228072045.GS24754@ufanet.ru> <20200228073113.GT24754@ufanet.ru> Message-ID: <20200228081520.GV24754@ufanet.ru> On Fri, Feb 28, 2020 at 12:46:41PM +0500, Илья Шипицин wrote: > > === > > Задаёт серверы DNS, используемые для преобразования имён вышестоящих > > серверов в адреса, например: > > ... > > По умолчанию nginx кэширует ответы, используя значение TTL из ответа. > > Необязательный параметр valid позволяет это переопределить: > > === > > это точно касается имен, на которые вы делаете proxy_pass ? > потому что, например, вот > > https://trac.nginx.org/nginx/ticket/1372?cversion=0&cnum_hist=2 > > (и это совпадает с тем, что я вижу в коде) теперь уже не уверен, потому что в своем утверждении, что это решает проблему топикстартера я однозначно ошибся. при недоступности резолвера нгинкс не стартует так же, как и при недоступности серверов из resolv.conf без директивы resolver. нужна переменная, согласен. а еще можно прописать ip бакенда в hosts =) -- boco From nginx-forum на forum.nginx.org Fri Feb 28 10:11:42 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 05:11:42 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228081520.GV24754@ufanet.ru> References: <20200228081520.GV24754@ufanet.ru> Message-ID: <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> Вообщем проблема именно в centos 8. Ставил на голые ОС nginx с своими настройками...Centos 7 все работает, в Centos 8 такая ошибка... Сам unit файл одинаковый. директива reslove в nginx не помогает. У кого какие мысли? Все что нагуглил, перепробовал в настройках unit, не помогло... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287164#msg-287164 From chipitsine на gmail.com Fri Feb 28 10:16:12 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Feb 2020 15:16:12 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> References: <20200228081520.GV24754@ufanet.ru> <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> Message-ID: пт, 28 февр. 2020 г. в 15:11, windos321 : > Вообщем проблема именно в centos 8. > Ставил на голые ОС nginx с своими настройками...Centos 7 все работает, в > Centos 8 такая ошибка... > Сам unit файл одинаковый. > > директива reslove в nginx не помогает. > > У кого какие мысли? > перейти на haproxy (или другой реверс прокси) ? > Все что нагуглил, перепробовал в настройках unit, не помогло... > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287141,287164#msg-287164 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Fri Feb 28 10:16:39 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 05:16:39 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> References: <20200228081520.GV24754@ufanet.ru> <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> Message-ID: <05e36dac1d75f46ca370e1d5beb8c268.NginxMailingListRussian@forum.nginx.org> https://access.redhat.com/solutions/4255211 Может у кого-то есть сюда доступ? Здесь вроде как такая-же проблема обсуждается Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287165#msg-287165 From chipitsine на gmail.com Fri Feb 28 10:28:52 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 28 Feb 2020 15:28:52 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <05e36dac1d75f46ca370e1d5beb8c268.NginxMailingListRussian@forum.nginx.org> References: <20200228081520.GV24754@ufanet.ru> <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> <05e36dac1d75f46ca370e1d5beb8c268.NginxMailingListRussian@forum.nginx.org> Message-ID: пт, 28 февр. 2020 г. в 15:16, windos321 : > https://access.redhat.com/solutions/4255211 > Может у кого-то есть сюда доступ? Здесь вроде как такая-же проблема > обсуждается > необязательно, чтобы у кого-то доступ уже был. если его нет, его, наверное, можно получить > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287141,287165#msg-287165 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From kovalkov на fastvps.ru Fri Feb 28 12:34:46 2020 From: kovalkov на fastvps.ru (Dmitriy Kovalkov) Date: Fri, 28 Feb 2020 15:34:46 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: <20200228081520.GV24754@ufanet.ru> <1d67094e87c4c93f2bf9d59eaa902014.NginxMailingListRussian@forum.nginx.org> <05e36dac1d75f46ca370e1d5beb8c268.NginxMailingListRussian@forum.nginx.org> Message-ID: > > https://access.redhat.com/solutions/4255211 > Может у кого-то есть сюда доступ? Здесь вроде как такая-же проблема > обсуждается nginx does not start after server restart in the RHEL 8 SOLUTION VERIFIED - Updated July 1 2019 at 3:20 PM - English Environment Red Hat Enterprise Linux (RHEL) 8 nginx 1:1.14.1-8 Issue When restarting the server, the nginx service does not start automatically, as it does not resolve the hostname in the upstream configuration: Raw upstream test { ip_hash; server test.example.com; The error message: Raw host not found in upstream "test.example.com" in /etc/nginx/conf.d/configfile.conf:4 After that the server is up, nginx starts without issues. Resolution Create the file /etc/systemd/system/nginx.service.d/dependency.conf with contents: Raw [Unit] After=network-online.target Requires=network-online.target That means that nginx.service would depend on network-online.target meaning that it would start only after the network is started and system is online. Root Cause Currently nginx service depends on network.target. That means that it starts after network initiation is started, but not after the system is online. This is the expected behaviour as explained in BZ 1725248. Но вообще проще взять корректный юнит файл http://hg.nginx.org/pkg-oss/file/tip/rpm/SOURCES/nginx.service --- Respectfully, Dmitrii Kovalkov FASTVPS technical department пт, 28 февр. 2020 г. в 13:29, Илья Шипицин : > > > пт, 28 февр. 2020 г. в 15:16, windos321 : > >> https://access.redhat.com/solutions/4255211 >> Может у кого-то есть сюда доступ? Здесь вроде как такая-же проблема >> обсуждается >> > > необязательно, чтобы у кого-то доступ уже был. если его нет, его, > наверное, можно получить > > >> >> Posted at Nginx Forum: >> https://forum.nginx.org/read.php?21,287141,287165#msg-287165 >> >> _______________________________________________ >> 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 Fri Feb 28 13:07:43 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 08:07:43 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: Спасибо! Ну думал теперь точно решена проблема, а нефига... Вот же зараза, не помогает создание: Create the file /etc/systemd/system/nginx.service.d/dependency.conf with After=network-online.target Requires=network-online.target И использование этого и множества других юнитов: http://hg.nginx.org/pkg-oss/file/tip/rpm/SOURCES/nginx.service Подчеркну - centos 8 - голая, сразу после установки оси ставлю nginx... На centos 7 такой ошибки нет... Напомню ошибку: nginx: [emerg] host not found in upstream "ЛЮБОЙ домен из upstream" только после ребута, потом нормально стартует Что делать блин? Варианты сменить OS и веб-сервер не предлагать... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287170#msg-287170 From boco на ufanet.ru Fri Feb 28 15:43:32 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Fri, 28 Feb 2020 20:43:32 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: <20200228154331.GD24754@ufanet.ru> On Fri, Feb 28, 2020 at 08:07:43AM -0500, windos321 wrote: > Подчеркну - centos 8 - голая, сразу после установки оси ставлю nginx... > На centos 7 такой ошибки нет... > > Напомню ошибку: > nginx: [emerg] host not found in upstream "ЛЮБОЙ домен из upstream" > только после ребута, потом нормально стартует поставил голый centos 8, minimal install. поставил nginx из http://nginx.org/packages/mainline/centos/$releasever/$basearch/ запилил простейший конфиг === server { listen 80 default; server_name _; location / { proxy_pass https://legacy.iproperty.com.my; } } === несколько раз перезагрузил вм - нгинкс всегда стартует. а что у вас в /etc/resolv.conf? -- boco From nginx-forum на forum.nginx.org Fri Feb 28 16:29:28 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 11:29:28 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228154331.GD24754@ufanet.ru> References: <20200228154331.GD24754@ufanet.ru> Message-ID: <2bcfddc64f0cde69fb438089f1a7fd96.NginxMailingListRussian@forum.nginx.org> nameserver 8.8.8.8 и все Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287178#msg-287178 From nginx-forum на forum.nginx.org Fri Feb 28 16:30:39 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 11:30:39 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228154331.GD24754@ufanet.ru> References: <20200228154331.GD24754@ufanet.ru> Message-ID: damir bikmuhametov Wrote: ------------------------------------------------------- > On Fri, Feb 28, 2020 at 08:07:43AM -0500, windos321 wrote: > > Подчеркну - centos 8 - голая, сразу после установки оси ставлю > nginx... > > На centos 7 такой ошибки нет... > > > > Напомню ошибку: > > nginx: [emerg] host not found in upstream "ЛЮБОЙ домен из upstream" > > только после ребута, потом нормально стартует > > поставил голый centos 8, minimal install. поставил nginx из > http://nginx.org/packages/mainline/centos/$releasever/$basearch/ > > запилил простейший конфиг > > === > server { > listen 80 default; > server_name _; > > location / { > proxy_pass https://legacy.iproperty.com.my; > } > } > === > > несколько раз перезагрузил вм - нгинкс всегда стартует. > > а что у вас в /etc/resolv.conf? > > -- > boco > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru upstream секция есть? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287179#msg-287179 From boco на ufanet.ru Fri Feb 28 16:36:27 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Fri, 28 Feb 2020 21:36:27 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: <20200228154331.GD24754@ufanet.ru> Message-ID: <20200228163626.GE24754@ufanet.ru> On Fri, Feb 28, 2020 at 11:30:39AM -0500, windos321 wrote: > > поставил голый centos 8, minimal install. поставил nginx из > > http://nginx.org/packages/mainline/centos/$releasever/$basearch/ > > > > запилил простейший конфиг > > upstream секция есть? да, пробовал и такой конфиг === upstream test { ip_hash; server legacy.iproperty.com.my; } server { listen 80 default; server_name _; location / { proxy_pass https://test; } } === тоже стартует после ребута. -- boco From nginx-forum на forum.nginx.org Fri Feb 28 16:45:44 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 11:45:44 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228154331.GD24754@ufanet.ru> References: <20200228154331.GD24754@ufanet.ru> Message-ID: centos 8 = CentOS Linux release 8.1.1911 (Core) kernel = 4.18.0-147.3.1.el8_1.x86_64 #1 SMP Fri Jan 3 23:55:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux центось с шаблона ovh.... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287181#msg-287181 From boco на ufanet.ru Fri Feb 28 16:52:20 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Fri, 28 Feb 2020 21:52:20 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: <20200228154331.GD24754@ufanet.ru> Message-ID: <20200228165220.GF24754@ufanet.ru> On Fri, Feb 28, 2020 at 11:45:44AM -0500, windos321 wrote: > centos 8 = CentOS Linux release 8.1.1911 (Core) > kernel = 4.18.0-147.3.1.el8_1.x86_64 #1 SMP Fri Jan 3 23:55:26 UTC 2020 > x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release CentOS Linux release 8.1.1911 (Core) $ uname -a Linux centos8 4.18.0-147.5.1.el8_1.x86_64 #1 SMP Wed Feb 5 02:00:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > центось с шаблона ovh я ставил с iso: https://mirror.yandex.ru/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-x86_64-boot.iso -- boco From nginx-forum на forum.nginx.org Fri Feb 28 20:06:51 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 15:06:51 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200228165220.GF24754@ufanet.ru> References: <20200228165220.GF24754@ufanet.ru> Message-ID: <3701e431e9f4ebea0b7ce62e432f9117.NginxMailingListRussian@forum.nginx.org> https://mirror.yandex.ru/centos/8.1.1911/isos/x86_64/CentOS-8.1.1911-x86_64-boot.iso поставил этот образ начисто, в версии minimal ошибки не решило Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287184#msg-287184 From nginx-forum на forum.nginx.org Fri Feb 28 20:10:50 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 15:10:50 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <17089bc50e8.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> References: <17089bc50e8.2797.c9c0c8e23854510de0246f8a19aa7b8d@gmail.com> Message-ID: <4f346306aa385941671633636022e767.NginxMailingListRussian@forum.nginx.org> конечно Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287185#msg-287185 From chipitsine на gmail.com Fri Feb 28 20:41:59 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Sat, 29 Feb 2020 01:41:59 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: пт, 28 февр. 2020 г. в 18:08, windos321 : > Спасибо! Ну думал теперь точно решена проблема, а нефига... > статья на сайте редхата касается RHEL8. оно проверено редхатом. у Вас проверенное решение не работает, возможно, есть какие-то отличия CentOS от RHEL ? я не могу придумать другую причину. > > Вот же зараза, не помогает создание: > Create the file /etc/systemd/system/nginx.service.d/dependency.conf with > After=network-online.target > Requires=network-online.target > > И использование этого и множества других юнитов: > http://hg.nginx.org/pkg-oss/file/tip/rpm/SOURCES/nginx.service > > Подчеркну - centos 8 - голая, сразу после установки оси ставлю nginx... > На centos 7 такой ошибки нет... > > Напомню ошибку: > nginx: [emerg] host not found in upstream "ЛЮБОЙ домен из upstream" > только после ребута, потом нормально стартует > > Что делать блин? Варианты сменить OS и веб-сервер не предлагать... > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287141,287170#msg-287170 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ngnx8810773a83 на avksrv.org Fri Feb 28 21:07:42 2020 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Sat, 29 Feb 2020 00:07:42 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: cat /etc/systemd/system/multi-user.target.wants/nginx.service там точно есть After= ... network-online.target ... nss-lookup.target ... Wants= network-online.target ? systemctl daemon-reload после правки /usr/lib/systemd/system/nginx.service делался ? точно эта же проблемы была на 7 центоси пускаемой в контейнере, и жалобы на чтото типы юбунты тоже были. Проблема в том, что systemd сильна асинхронно пускает все сервисы, и нгинкс успевает стартануть до сети, и обламывается потому, что до ресловера достутчаться нельзя.. при network-online.target и nss-lookup.target ресолв должен работать бы... у вас часом адреса не по DHCP ? если DHCP,  можно затычку вида https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html и зависимость от него... /А 28.02.2020 16:07, windos321 пишет: > Спасибо! Ну думал теперь точно решена проблема, а нефига... > > Вот же зараза, не помогает создание: > Create the file /etc/systemd/system/nginx.service.d/dependency.conf with > After=network-online.target > Requires=network-online.target > > И использование этого и множества других юнитов: > http://hg.nginx.org/pkg-oss/file/tip/rpm/SOURCES/nginx.service > > Подчеркну - centos 8 - голая, сразу после установки оси ставлю nginx... > На centos 7 такой ошибки нет... > > Напомню ошибку: > nginx: [emerg] host not found in upstream "ЛЮБОЙ домен из upstream" > только после ребута, потом нормально стартует > > Что делать блин? Варианты сменить OS и веб-сервер не предлагать... > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287170#msg-287170 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From andrey на kopeyko.ru Fri Feb 28 22:44:09 2020 From: andrey на kopeyko.ru (Andrey Kopeyko) Date: Sat, 29 Feb 2020 01:44:09 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: <6b9485c0f15ea969fbf46b05b9a6c236@kopeyko.ru> windos321 писал 2020-02-28 16:07: > > Вот же зараза, не помогает создание: > Create the file /etc/systemd/system/nginx.service.d/dependency.conf > with > After=network-online.target > Requires=network-online.target Наверное, потому что вы секцию не указали +[Unit] After=network-online.target Requires=network-online.target > -- Best regards, Andrey A. Kopeyko From nginx-forum на forum.nginx.org Sat Feb 29 03:53:19 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 22:53:19 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: systemctl daemon-reload делал на centos 8 управление сетью заменено на network manager, но разве systemd-networkd-wait-online.service и подобный не относятся к network-online.target? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287189#msg-287189 From nginx-forum на forum.nginx.org Sat Feb 29 03:55:10 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 22:55:10 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <6b9485c0f15ea969fbf46b05b9a6c236@kopeyko.ru> References: <6b9485c0f15ea969fbf46b05b9a6c236@kopeyko.ru> Message-ID: <5a1ce52467ea216f78decf1f813093d4.NginxMailingListRussian@forum.nginx.org> исключено, все там было сделано правильно) я с этой проблемой вторые сутки воюю, конечно можно списать на усталость, но такие мелочи грех допускать..иначе войну не выиграть, а я надеюсь Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287190#msg-287190 From nginx-forum на forum.nginx.org Sat Feb 29 03:59:55 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 22:59:55 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: вообщем из актуального: чистая centos 8 с оф.сайта в версии minimal - ошибка есть решение с сайта redhat и игра с разными зависимостями UNIT (много перебрал) - ошибка есть пробовал конфиг вида: ------------------------------------------------------------------------------------------------------------------------------ upstream test { ip_hash; server legacy.iproperty.com.my; } server { listen 80 default; server_name _; location / { proxy_pass https://test; } } } ------------------------------------------------------------------------------------------------------------------------------ ошибка есть как говорил damir bikmuhametov, у него на чистой centos 8 и с таким конфигом все работало. остается одно направление раскопок - видимо настройка сети, другого не вижу да и в centos 8 по сравнению с centos 7 работает NetworkManager вместо netowrk-scirpts, а на centos 7 такой проблемы нет, хоть тресни... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287191#msg-287191 From nginx-forum на forum.nginx.org Sat Feb 29 04:00:25 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Fri, 28 Feb 2020 23:00:25 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <3701e431e9f4ebea0b7ce62e432f9117.NginxMailingListRussian@forum.nginx.org> References: <20200228165220.GF24754@ufanet.ru> <3701e431e9f4ebea0b7ce62e432f9117.NginxMailingListRussian@forum.nginx.org> Message-ID: <100d250c2fd95194ee7e25ef2f464c95.NginxMailingListRussian@forum.nginx.org> вообщем из актуального: чистая centos 8 с оф.сайта в версии minimal - ошибка есть решение с сайта redhat и игра с разными зависимостями UNIT (много перебрал) - ошибка есть пробовал конфиг вида: ------------------------------------------------------------------------------------------------------------------------------ upstream test { ip_hash; server legacy.iproperty.com.my; } server { listen 80 default; server_name _; location / { proxy_pass https://test; } } } ------------------------------------------------------------------------------------------------------------------------------ ошибка есть остается одно направление раскопок - видимо настройка сети, другого не вижу да и в centos 8 по сравнению с centos 7 работает NetworkManager вместо netowrk-scirpts, а на centos 7 такой проблемы нет, хоть тресни... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287192#msg-287192 From nginx-forum на forum.nginx.org Sat Feb 29 06:11:40 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Sat, 29 Feb 2020 01:11:40 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <100d250c2fd95194ee7e25ef2f464c95.NginxMailingListRussian@forum.nginx.org> References: <20200228165220.GF24754@ufanet.ru> <3701e431e9f4ebea0b7ce62e432f9117.NginxMailingListRussian@forum.nginx.org> <100d250c2fd95194ee7e25ef2f464c95.NginxMailingListRussian@forum.nginx.org> Message-ID: <368ecde57fbd4c0d6aea764789f4c522.NginxMailingListRussian@forum.nginx.org> Можете скинуть конфиг своих сетевых интерфейсов где у вас все работает? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287193#msg-287193 From boco на ufanet.ru Sat Feb 29 07:02:45 2020 From: boco на ufanet.ru (damir bikmuhametov) Date: Sat, 29 Feb 2020 12:02:45 +0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <368ecde57fbd4c0d6aea764789f4c522.NginxMailingListRussian@forum.nginx.org> References: <20200228165220.GF24754@ufanet.ru> <3701e431e9f4ebea0b7ce62e432f9117.NginxMailingListRussian@forum.nginx.org> <100d250c2fd95194ee7e25ef2f464c95.NginxMailingListRussian@forum.nginx.org> <368ecde57fbd4c0d6aea764789f4c522.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200229070244.GG24754@ufanet.ru> On Sat, Feb 29, 2020 at 01:11:40AM -0500, windos321 wrote: > Можете скинуть конфиг своих сетевых интерфейсов где у вас все работает? [boco на centos8 ~]$ ls -l /etc/sysconfig/network-scripts/ total 4 -rw-r--r--. 1 root root 422 Feb 28 20:19 ifcfg-ens18 [boco на centos8 ~]$ cat /etc/sysconfig/network-scripts/ifcfg-ens18 TYPE="Ethernet" PROXY_METHOD="none" BROWSER_ONLY="no" BOOTPROTO="none" DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="no" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" IPV6_ADDR_GEN_MODE="stable-privacy" NAME="ens18" UUID="f2a1193d-adbf-4e8c-afcc-87ecbe8b5e2f" DEVICE="ens18" ONBOOT="yes" ETHTOOL_OPTS="wol d" IPADDR="10.2.88.252" PREFIX="24" GATEWAY="10.2.88.1" DNS1="81.30.199.94" DOMAIN="ufanet.ru" -- boco From ngnx8810773a83 на avksrv.org Sat Feb 29 08:24:13 2020 From: ngnx8810773a83 на avksrv.org (Alexey) Date: Sat, 29 Feb 2020 11:24:13 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: References: Message-ID: Запускаем пинг на шлюз, вынимаем провод, пинг, понятно, пропадает, вставляем.. сколько проходит до появления пинга ? Какойнить portfast не включен ? 29.02.2020 6:53, windos321 пишет: > systemctl daemon-reload > делал > > на centos 8 управление сетью заменено на network manager, но разве > systemd-networkd-wait-online.service и подобный не относятся к > network-online.target? > > Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287189#msg-287189 > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru From bgx на protva.ru Sat Feb 29 13:29:28 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Sat, 29 Feb 2020 16:29:28 +0300 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <5a1ce52467ea216f78decf1f813093d4.NginxMailingListRussian@forum.nginx.org> References: <6b9485c0f15ea969fbf46b05b9a6c236@kopeyko.ru> <5a1ce52467ea216f78decf1f813093d4.NginxMailingListRussian@forum.nginx.org> Message-ID: <20200229132928.GS1422@sie.protva.ru> On Fri, Feb 28, 2020 at 10:55:10PM -0500, windos321 wrote: > исключено, все там было сделано правильно) я с этой проблемой вторые сутки > воюю, конечно можно списать на усталость, но такие мелочи грех > допускать..иначе войну не выиграть, а я надеюсь И что, за двое суток дёрганья всех ручек наугад не появилась идея провести хотя бы минимальную диагностику? Ввставить в скрипт запуска nginx команды по выводу состояния сети, хотя бы "networkctl -a status", дополнить пингом резолвера, etc. Я вот думаю что если два дня подряд палить из всех пушек в белый свет, но при этом не читать сводок с фронта, войну точно не выиграешь. :) -- Eugene Berdnikov From nginx-forum на forum.nginx.org Sat Feb 29 13:55:47 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Sat, 29 Feb 2020 08:55:47 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <20200229132928.GS1422@sie.protva.ru> References: <20200229132928.GS1422@sie.protva.ru> Message-ID: <10971e10c1bf6767cfdf5153a9519860.NginxMailingListRussian@forum.nginx.org> Появилось понимание что это точно связано с сетью...network-online.target работает не так, как ожидается...проблема в конфиге сети... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287198#msg-287198 From nginx-forum на forum.nginx.org Sat Feb 29 15:34:59 2020 From: nginx-forum на forum.nginx.org (windos321) Date: Sat, 29 Feb 2020 10:34:59 -0500 Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L/QtdGA0LXQt9Cw0L/Rg9GB0LrQvtC8?= =?UTF-8?B?INCyIGNlbnRvcyA4?= In-Reply-To: <10971e10c1bf6767cfdf5153a9519860.NginxMailingListRussian@forum.nginx.org> References: <20200229132928.GS1422@sie.protva.ru> <10971e10c1bf6767cfdf5153a9519860.NginxMailingListRussian@forum.nginx.org> Message-ID: <6cd59cc47f00a9238784882612ce47ac.NginxMailingListRussian@forum.nginx.org> Вообщем единственного что удалось добиться чтобы nginx стартовал с задержкой как положено.... Вышло случайно...Вообщем когда включен IPMI remote KVM, в девайсах появляется USB Ethernet: Wired connection 1...и тогда в 100% случаев сервис nginx стартует с задержкой и автозапуск проходит удачно...Без этого устройства - все так-же ошибка nginx... Перебрал все возможные юниты, network-scripts... Готов сдаться уже...Что за ересь... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287141,287201#msg-287201