From chipitsine на gmail.com  Tue Dec  1 05:52:48 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 1 Dec 2020 10:52:48 +0500
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201130231115.GJ1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
Message-ID: <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>

вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > может кто сталкивался, и знает, что с этим можно сделать.
> > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > домены разные, каждый со своей бизнес логикой.
> >
> > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я
> > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
> > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > подключение до конкретного сайта, а вообще все, которые он умудрился
> > связать с этим tcp подключением.
> >
> > частный пример - сайт, который иногда формирует очень длинные URL, не
> > помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
> > ситуации Chrome рвет всё до этого IP адреса.
> >
> > как-то не по христиански чтоли.
> >
> > подумалось, что аналогичных хостингов высокой плотности в рассылке может
> > быть достаточное количество. не первый же  я с таким столкнулся?
>
> Это называется connection reuse, правила прописаны тут:
>
> https://tools.ietf.org/html/rfc7540#section-9.1.1
>
> В частности:
>
>    For "https" resources, connection reuse additionally depends on
>    having a certificate that is valid for the host in the URI.  The
>    certificate presented by the server MUST satisfy any checks that the
>    client would perform when forming a new TLS connection for the host
>    in the URI.
>
> То есть если хочется, чтобы соединения не reuse'ались, можно
> сконфигурировать разные сертификаты для разных серверов (или групп
> серверов).
>
> Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
>

в исходниках это вот так

    if ((size_t) len > h2scf->max_field_size) {
        ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
                      "client exceeded http2_max_field_size limit");

        return ngx_http_v2_connection_error(h2c,
NGX_HTTP_V2_ENHANCE_YOUR_CALM);
    }


как можно в этом месте вернуть "по необходимости" 421 ?



>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/6331924d/attachment.htm>

From mdounin на mdounin.ru  Tue Dec  1 13:13:20 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 1 Dec 2020 16:13:20 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>
Message-ID: <20201201131320.GM1147@mdounin.ru>

Hello!

On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:

> вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdounin на mdounin.ru>:
> 
> > Hello!
> >
> > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> >
> > > привет!
> > >
> > > может кто сталкивался, и знает, что с этим можно сделать.
> > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > домены разные, каждый со своей бизнес логикой.
> > >
> > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я
> > > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
> > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > подключение до конкретного сайта, а вообще все, которые он умудрился
> > > связать с этим tcp подключением.
> > >
> > > частный пример - сайт, который иногда формирует очень длинные URL, не
> > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
> > > ситуации Chrome рвет всё до этого IP адреса.
> > >
> > > как-то не по христиански чтоли.
> > >
> > > подумалось, что аналогичных хостингов высокой плотности в рассылке может
> > > быть достаточное количество. не первый же  я с таким столкнулся?
> >
> > Это называется connection reuse, правила прописаны тут:
> >
> > https://tools.ietf.org/html/rfc7540#section-9.1.1
> >
> > В частности:
> >
> >    For "https" resources, connection reuse additionally depends on
> >    having a certificate that is valid for the host in the URI.  The
> >    certificate presented by the server MUST satisfy any checks that the
> >    client would perform when forming a new TLS connection for the host
> >    in the URI.
> >
> > То есть если хочется, чтобы соединения не reuse'ались, можно
> > сконфигурировать разные сертификаты для разных серверов (или групп
> > серверов).
> >
> > Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
> >
> 
> в исходниках это вот так
> 
>     if ((size_t) len > h2scf->max_field_size) {
>         ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
>                       "client exceeded http2_max_field_size limit");
> 
>         return ngx_http_v2_connection_error(h2c,
> NGX_HTTP_V2_ENHANCE_YOUR_CALM);
>     }
> 
> 
> как можно в этом месте вернуть "по необходимости" 421 ?

Нет, это фатальная ошибка для соединения, дальнейшая работа с этим 
соединением невозможна.  Возвращать 421 надо заранее, до того, как 
придёт кривой запрос.

-- 
Maxim Dounin
http://mdounin.ru/

From chipitsine на gmail.com  Tue Dec  1 13:18:32 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 1 Dec 2020 18:18:32 +0500
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201201131320.GM1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>
 <20201201131320.GM1147@mdounin.ru>
Message-ID: <CAFHpkQH8NEvvf9Pj6jsVU9O=JosZamhdxZzde=n9-95XzhK_pw@mail.gmail.com>

вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdounin на mdounin.ru>:
> >
> > > Hello!
> > >
> > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > >
> > > > привет!
> > > >
> > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > домены разные, каждый со своей бизнес логикой.
> > > >
> > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один,
> то я
> > > > буду весь трафик гонять через одно tcp подключение". все бы ничего,
> но
> > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > подключение до конкретного сайта, а вообще все, которые он умудрился
> > > > связать с этим tcp подключением.
> > > >
> > > > частный пример - сайт, который иногда формирует очень длинные URL, не
> > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> такой
> > > > ситуации Chrome рвет всё до этого IP адреса.
> > > >
> > > > как-то не по христиански чтоли.
> > > >
> > > > подумалось, что аналогичных хостингов высокой плотности в рассылке
> может
> > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > >
> > > Это называется connection reuse, правила прописаны тут:
> > >
> > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > >
> > > В частности:
> > >
> > >    For "https" resources, connection reuse additionally depends on
> > >    having a certificate that is valid for the host in the URI.  The
> > >    certificate presented by the server MUST satisfy any checks that the
> > >    client would perform when forming a new TLS connection for the host
> > >    in the URI.
> > >
> > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > серверов).
> > >
> > > Ну либо руками возвращать 421 по необходимости, проверяя
> $ssl_server_name.
> > >
> >
> > в исходниках это вот так
> >
> >     if ((size_t) len > h2scf->max_field_size) {
> >         ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> >                       "client exceeded http2_max_field_size limit");
> >
> >         return ngx_http_v2_connection_error(h2c,
> > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> >     }
> >
> >
> > как можно в этом месте вернуть "по необходимости" 421 ?
>
> Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> соединением невозможна.  Возвращать 421 надо заранее, до того, как
> придёт кривой запрос.
>
>
пардон. я не понимаю, что вы предлагаете.
можете привести пример, как сделать ?



> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/e323e9c8/attachment.htm>

From mdounin на mdounin.ru  Tue Dec  1 13:42:53 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 1 Dec 2020 16:42:53 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <CAFHpkQH8NEvvf9Pj6jsVU9O=JosZamhdxZzde=n9-95XzhK_pw@mail.gmail.com>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>
 <20201201131320.GM1147@mdounin.ru>
 <CAFHpkQH8NEvvf9Pj6jsVU9O=JosZamhdxZzde=n9-95XzhK_pw@mail.gmail.com>
Message-ID: <20201201134253.GN1147@mdounin.ru>

Hello!

On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:

> вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <mdounin на mdounin.ru>:
> 
> > Hello!
> >
> > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> >
> > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdounin на mdounin.ru>:
> > >
> > > > Hello!
> > > >
> > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > >
> > > > > привет!
> > > > >
> > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > домены разные, каждый со своей бизнес логикой.
> > > > >
> > > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один,
> > то я
> > > > > буду весь трафик гонять через одно tcp подключение". все бы ничего,
> > но
> > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > подключение до конкретного сайта, а вообще все, которые он умудрился
> > > > > связать с этим tcp подключением.
> > > > >
> > > > > частный пример - сайт, который иногда формирует очень длинные URL, не
> > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> > такой
> > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > >
> > > > > как-то не по христиански чтоли.
> > > > >
> > > > > подумалось, что аналогичных хостингов высокой плотности в рассылке
> > может
> > > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > > >
> > > > Это называется connection reuse, правила прописаны тут:
> > > >
> > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > >
> > > > В частности:
> > > >
> > > >    For "https" resources, connection reuse additionally depends on
> > > >    having a certificate that is valid for the host in the URI.  The
> > > >    certificate presented by the server MUST satisfy any checks that the
> > > >    client would perform when forming a new TLS connection for the host
> > > >    in the URI.
> > > >
> > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > серверов).
> > > >
> > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > $ssl_server_name.
> > > >
> > >
> > > в исходниках это вот так
> > >
> > >     if ((size_t) len > h2scf->max_field_size) {
> > >         ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > >                       "client exceeded http2_max_field_size limit");
> > >
> > >         return ngx_http_v2_connection_error(h2c,
> > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > >     }
> > >
> > >
> > > как можно в этом месте вернуть "по необходимости" 421 ?
> >
> > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > соединением невозможна.  Возвращать 421 надо заранее, до того, как
> > придёт кривой запрос.
> >
> >
> пардон. я не понимаю, что вы предлагаете.
> можете привести пример, как сделать ?

Если добавить что-нибудь вроде:

    if ($ssl_server_name != "example.com") {
        return 421;
    }

во все релевантные блоки server{}, это предотвратит reuse 
соединений, кроме первых запросов.  Соответственно соединения 
будут отдельными, и при необходимости закрыть соединение - будет 
закрываться только соединение с одним сервером, а не со всеми 
серверами на данном IP.

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

-- 
Maxim Dounin
http://mdounin.ru/

From chipitsine на gmail.com  Tue Dec  1 13:55:16 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 1 Dec 2020 18:55:16 +0500
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201201134253.GN1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>
 <20201201131320.GM1147@mdounin.ru>
 <CAFHpkQH8NEvvf9Pj6jsVU9O=JosZamhdxZzde=n9-95XzhK_pw@mail.gmail.com>
 <20201201134253.GN1147@mdounin.ru>
Message-ID: <CAFHpkQH2JV_snaWtSy1AH8ZT-x-6bvFX365KMjSmfp44BTT9iw@mail.gmail.com>

вт, 1 дек. 2020 г. в 18:43, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <mdounin на mdounin.ru>:
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdounin на mdounin.ru>:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > > >
> > > > > > привет!
> > > > > >
> > > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > > домены разные, каждый со своей бизнес логикой.
> > > > > >
> > > > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP
> один,
> > > то я
> > > > > > буду весь трафик гонять через одно tcp подключение". все бы
> ничего,
> > > но
> > > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > > подключение до конкретного сайта, а вообще все, которые он
> умудрился
> > > > > > связать с этим tcp подключением.
> > > > > >
> > > > > > частный пример - сайт, который иногда формирует очень длинные
> URL, не
> > > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> > > такой
> > > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > > >
> > > > > > как-то не по христиански чтоли.
> > > > > >
> > > > > > подумалось, что аналогичных хостингов высокой плотности в
> рассылке
> > > может
> > > > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > > > >
> > > > > Это называется connection reuse, правила прописаны тут:
> > > > >
> > > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > > >
> > > > > В частности:
> > > > >
> > > > >    For "https" resources, connection reuse additionally depends on
> > > > >    having a certificate that is valid for the host in the URI.  The
> > > > >    certificate presented by the server MUST satisfy any checks
> that the
> > > > >    client would perform when forming a new TLS connection for the
> host
> > > > >    in the URI.
> > > > >
> > > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > > серверов).
> > > > >
> > > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > > $ssl_server_name.
> > > > >
> > > >
> > > > в исходниках это вот так
> > > >
> > > >     if ((size_t) len > h2scf->max_field_size) {
> > > >         ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > > >                       "client exceeded http2_max_field_size limit");
> > > >
> > > >         return ngx_http_v2_connection_error(h2c,
> > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > > >     }
> > > >
> > > >
> > > > как можно в этом месте вернуть "по необходимости" 421 ?
> > >
> > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > > соединением невозможна.  Возвращать 421 надо заранее, до того, как
> > > придёт кривой запрос.
> > >
> > >
> > пардон. я не понимаю, что вы предлагаете.
> > можете привести пример, как сделать ?
>
> Если добавить что-нибудь вроде:
>
>     if ($ssl_server_name != "example.com") {
>         return 421;
>     }
>

идею понял, протестируем


>
> во все релевантные блоки server{}, это предотвратит reuse
> соединений, кроме первых запросов.  Соответственно соединения
> будут отдельными, и при необходимости закрыть соединение - будет
> закрываться только соединение с одним сервером, а не со всеми
> серверами на данном IP.
>
> Ну и обращаю внимание на озвученный выше и проигнорированный
> вариант разных сертификатов.  Он позволяет контроллировать
> поведение на стороне браузера и соответственно более эффективен,
> т.к. нет проблемы первых запросов.
>

если это вайлдкард, где я возьму разных сертификатов



вообще, я расчитывал на

1) более адекватное поведение хрома (хотя о чем это я)
2) более адекватное поведение nginx с учетом пункта "1", например, вместо
фатального для браузера GO AWAY, отвечать 421



>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/2196c02b/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Tue Dec  1 15:01:29 2020
From: nginx-forum на forum.nginx.org (macmealan)
Date: Tue, 01 Dec 2020 10:01:29 -0500
Subject: =?UTF-8?B?0L/RgNC4INC/0L7Qv9GL0YLQutC1INGB0L7Qt9C00LDQvdC40Y8g0L/QsNC/0Lo=?=
 =?UTF-8?B?0Lgg0LIg0LvQvtCz0LDRhSAibWtjb2wgY2FuIGNyZWF0ZSBhIGNvbGxlY3Rp?=
 =?UTF-8?B?b24gb25seSI=?=
Message-ID: <652243a24b2fd24dc075e57c02e2eec7.NginxMailingListRussian@forum.nginx.org>

Подключился через файл менеджер в  kde. При попытке создать папку ошибка.
*3 MKCOL can create a collection only, client: 10.10.1.200, server: _,
request: "MKCOL /webdav/test/test HTTP/1.1", host: "10.10.1.108"
Файлы тоже создавать не дает ошибка
*5 dav_ext stat failed on '/var/www/html/webdav/testfile' (2: No such file
or directory), client: 10.10.1.200, server: _, request: "PROPFIND
/webdav/testfile HTTP/1.1", host: "10.10.1.108"


Конфиг:
# Default server configuration
#
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location /webdav{
            client_max_body_size 1g;
            # Сюда будут загружаться файлы
            root /var/www/html;
            # Разрешаем чтение и удаление
            dav_access user:rw group:rw all:rw;
            # Все методы для удобства работы (с возможностью удаления)
            dav_methods PUT DELETE MKCOL COPY MOVE;
            # Требуется для некоторых webdav клиентов (Cyberduck и
Monosnap)
            dav_ext_methods   PROPFIND OPTIONS;
            # Чтобы клиенты могли создавать пусть сами
            create_full_put_path on;
            charset utf-8;
            # Возможность просмотра каталога
            autoindex on;
            # Включаем авторизоацию для загрузки файлов
            auth_basic "restricted";
            auth_basic_user_file /etc/nginx/htpasswd;
        }
        # А тут описывается отдача файлов, причем root указана директория
куда мы заливаем файлы
        location / {
            root /var/www/html;
        }
}

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


From bgx на protva.ru  Tue Dec  1 15:31:24 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 1 Dec 2020 18:31:24 +0300
Subject: =?UTF-8?B?UmU6INC/0YDQuCDQv9C+0L/Ri9GC0LrQtSDRgdC+0LfQtNCw0L3QuNGPINC/0LA=?=
 =?UTF-8?B?0L/QutC4INCyINC70L7Qs9Cw0YUgIm1rY29sIGNhbiBjcmVhdGUgYSBjb2xs?=
 =?UTF-8?B?ZWN0aW9uIG9ubHki?=
In-Reply-To: <652243a24b2fd24dc075e57c02e2eec7.NginxMailingListRussian@forum.nginx.org>
References: <652243a24b2fd24dc075e57c02e2eec7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20201201153124.GH11896@sie.protva.ru>

On Tue, Dec 01, 2020 at 10:01:29AM -0500, macmealan wrote:
> Подключился через файл менеджер в  kde. При попытке создать папку ошибка.
> *3 MKCOL can create a collection only, client: 10.10.1.200, server: _,
> request: "MKCOL /webdav/test/test HTTP/1.1", host: "10.10.1.108"

 Ваш файл-менеджер делает кривой запрос: урл без слэша на конце это
 не коллекция согласно стандарту, о чём сервер и сообщает.

> Файлы тоже создавать не дает ошибка
> *5 dav_ext stat failed on '/var/www/html/webdav/testfile' (2: No such file
> or directory), client: 10.10.1.200, server: _, request: "PROPFIND
> /webdav/testfile HTTP/1.1", host: "10.10.1.108"

 PROPFIND это не запрос на создание файла, а чтение атрибутов.
-- 
 Eugene Berdnikov

From alnkapa на gmail.com  Tue Dec  1 15:52:47 2020
From: alnkapa на gmail.com (Aln Kapa)
Date: Tue, 1 Dec 2020 18:52:47 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201130231115.GJ1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
Message-ID: <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>

А вот такое поведение? В какой-то момент chrome перестает что либо получать
по websocket, если открыть несколько вкладок на разные сайты с одним ip.

вт, 1 дек. 2020 г., 2:11 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>
> > привет!
> >
> > может кто сталкивался, и знает, что с этим можно сделать.
> > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > домены разные, каждый со своей бизнес логикой.
> >
> > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я
> > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
> > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > подключение до конкретного сайта, а вообще все, которые он умудрился
> > связать с этим tcp подключением.
> >
> > частный пример - сайт, который иногда формирует очень длинные URL, не
> > помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
> > ситуации Chrome рвет всё до этого IP адреса.
> >
> > как-то не по христиански чтоли.
> >
> > подумалось, что аналогичных хостингов высокой плотности в рассылке может
> > быть достаточное количество. не первый же  я с таким столкнулся?
>
> Это называется connection reuse, правила прописаны тут:
>
> https://tools.ietf.org/html/rfc7540#section-9.1.1
>
> В частности:
>
>    For "https" resources, connection reuse additionally depends on
>    having a certificate that is valid for the host in the URI.  The
>    certificate presented by the server MUST satisfy any checks that the
>    client would perform when forming a new TLS connection for the host
>    in the URI.
>
> То есть если хочется, чтобы соединения не reuse'ались, можно
> сконфигурировать разные сертификаты для разных серверов (или групп
> серверов).
>
> Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/c1cc3cf9/attachment.htm>

From chipitsine на gmail.com  Tue Dec  1 15:57:14 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 1 Dec 2020 20:57:14 +0500
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
Message-ID: <CAFHpkQExbVEBvMicL=QNd1-abwu8+-AVd=_gSK=wmV9Kdc3zng@mail.gmail.com>

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


это лишь гипотеза. но тем не менее

вт, 1 дек. 2020 г. в 20:53, Aln Kapa <alnkapa на gmail.com>:

> А вот такое поведение? В какой-то момент chrome перестает что либо
> получать по websocket, если открыть несколько вкладок на разные сайты с
> одним ip.
>
> вт, 1 дек. 2020 г., 2:11 Maxim Dounin <mdounin на mdounin.ru>:
>
>> Hello!
>>
>> On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
>>
>> > привет!
>> >
>> > может кто сталкивался, и знает, что с этим можно сделать.
>> > ситуация - хостинг высокой плотности, на одном IP много доменов.
>> > домены разные, каждый со своей бизнес логикой.
>> >
>> > у Chrome  включается какая-то оптимизация, и типа "ну раз IP один, то я
>> > буду весь трафик гонять через одно tcp подключение". все бы ничего, но
>> > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
>> > подключение до конкретного сайта, а вообще все, которые он умудрился
>> > связать с этим tcp подключением.
>> >
>> > частный пример - сайт, который иногда формирует очень длинные URL, не
>> > помещающиеся в  дефолтный http2_max_field_fize, при возникновение такой
>> > ситуации Chrome рвет всё до этого IP адреса.
>> >
>> > как-то не по христиански чтоли.
>> >
>> > подумалось, что аналогичных хостингов высокой плотности в рассылке может
>> > быть достаточное количество. не первый же  я с таким столкнулся?
>>
>> Это называется connection reuse, правила прописаны тут:
>>
>> https://tools.ietf.org/html/rfc7540#section-9.1.1
>>
>> В частности:
>>
>>    For "https" resources, connection reuse additionally depends on
>>    having a certificate that is valid for the host in the URI.  The
>>    certificate presented by the server MUST satisfy any checks that the
>>    client would perform when forming a new TLS connection for the host
>>    in the URI.
>>
>> То есть если хочется, чтобы соединения не reuse'ались, можно
>> сконфигурировать разные сертификаты для разных серверов (или групп
>> серверов).
>>
>> Ну либо руками возвращать 421 по необходимости, проверяя $ssl_server_name.
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/8c211d5b/attachment-0001.htm>

From mdounin на mdounin.ru  Tue Dec  1 17:16:33 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 1 Dec 2020 20:16:33 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
Message-ID: <20201201171633.GP1147@mdounin.ru>

Hello!

On Tue, Dec 01, 2020 at 06:52:47PM +0300, Aln Kapa wrote:

> А вот такое поведение? В какой-то момент chrome перестает что либо получать
> по websocket, если открыть несколько вкладок на разные сайты с одним ip.

Вебсокеты не ходят по HTTP/2, стандарт не предусматривает 
(отдельно сбоку их прикручивать пытались, не следил чем 
закончилось, но в любом случае nginx этого не поддерживает).  
Соответственно если у вас работают вебсокеты через nginx - то они 
работают в отдельных соединениях, устанавливаемых с помощью 
HTTP/1.1.

Так что если проблемы с вебсокетами - это совершенно точно другая 
проблема, не имеющая отношения к обсуждаемому вопросу про HTTP/2 и 
connection reuse.

Я бы скорее предполжил одно из двух: либо это какой-то косяк 
Хрома, связанный с ограничением количества соединений на хост / 
ip, либо это вообще где-то firewall чудит.

-- 
Maxim Dounin
http://mdounin.ru/

From alnkapa на gmail.com  Tue Dec  1 17:26:57 2020
From: alnkapa на gmail.com (Aln Kapa)
Date: Tue, 1 Dec 2020 20:26:57 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201201171633.GP1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
 <20201201171633.GP1147@mdounin.ru>
Message-ID: <CAJqqVEWeE+F_B_fRyg2YaXq9ObxReomNQFy6uenOn0K3Eze19Q@mail.gmail.com>

От это поворот!
без tls и на каждый коннект  отдельное соединение. А sse  работает так же?

вт, 1 дек. 2020 г., 20:16 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Dec 01, 2020 at 06:52:47PM +0300, Aln Kapa wrote:
>
> > А вот такое поведение? В какой-то момент chrome перестает что либо
> получать
> > по websocket, если открыть несколько вкладок на разные сайты с одним ip.
>
> Вебсокеты не ходят по HTTP/2, стандарт не предусматривает
> (отдельно сбоку их прикручивать пытались, не следил чем
> закончилось, но в любом случае nginx этого не поддерживает).
> Соответственно если у вас работают вебсокеты через nginx - то они
> работают в отдельных соединениях, устанавливаемых с помощью
> HTTP/1.1.
>
> Так что если проблемы с вебсокетами - это совершенно точно другая
> проблема, не имеющая отношения к обсуждаемому вопросу про HTTP/2 и
> connection reuse.
>
> Я бы скорее предполжил одно из двух: либо это какой-то косяк
> Хрома, связанный с ограничением количества соединений на хост /
> ip, либо это вообще где-то firewall чудит.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/fbc28e86/attachment.htm>

From mdounin на mdounin.ru  Tue Dec  1 18:48:04 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 1 Dec 2020 21:48:04 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <CAJqqVEWeE+F_B_fRyg2YaXq9ObxReomNQFy6uenOn0K3Eze19Q@mail.gmail.com>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
 <20201201171633.GP1147@mdounin.ru>
 <CAJqqVEWeE+F_B_fRyg2YaXq9ObxReomNQFy6uenOn0K3Eze19Q@mail.gmail.com>
Message-ID: <20201201184804.GQ1147@mdounin.ru>

Hello!

On Tue, Dec 01, 2020 at 08:26:57PM +0300, Aln Kapa wrote:

> От это поворот!
> без tls и на каждый коннект  отдельное соединение.

Про "без tls" - это уж как сконфигурите.  А то, что соединение 
это, ВНЕЗАПНО, соединение - ну да, так уж получилось.

> А sse  работает так же?

Если под SSE вы имеете в виду Server-Sent Events, то они работают 
в рамках стриминга HTTP-ответа с Content-Type "text/event-stream", 
и могут работать как по HTTP/1.x, так и по HTTP/2.

-- 
Maxim Dounin
http://mdounin.ru/

From chipitsine на gmail.com  Tue Dec  1 18:58:58 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 1 Dec 2020 23:58:58 +0500
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201201134253.GN1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAFHpkQGRw9jp+f7gP3rpAc1M8gJyQHjBnpr=wJ4TK6ry_KXygw@mail.gmail.com>
 <20201201131320.GM1147@mdounin.ru>
 <CAFHpkQH8NEvvf9Pj6jsVU9O=JosZamhdxZzde=n9-95XzhK_pw@mail.gmail.com>
 <20201201134253.GN1147@mdounin.ru>
Message-ID: <CAFHpkQEfCKA+0puPpjeq-Ja+_9ZwEh9RD+3Oiir9YWJD4at5HQ@mail.gmail.com>

вспомнил. мы проводили исследование на то, пользуются ли клиенты SNI.
в принципе, на вайлдкардовых сертах, как оказалось, можно работать и без
SNI.
некоторые случаи мы идентифицировали, это клиенты с определенными билдами
КриптоПро (как-то оно афектит даже RSA криптографию)

я к чему. в приведенном ниже условии, кажется, придется легитимизировать
пустой $ssl_server_name

но даже с учетом этого хак выглядит несложным. мы затестим.

    if ($ssl_server_name != "example.com") {
        return 421;
    }

вт, 1 дек. 2020 г. в 18:43, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Dec 01, 2020 at 06:18:32PM +0500, Илья Шипицин wrote:
>
> > вт, 1 дек. 2020 г. в 18:13, Maxim Dounin <mdounin на mdounin.ru>:
> >
> > > Hello!
> > >
> > > On Tue, Dec 01, 2020 at 10:52:48AM +0500, Илья Шипицин wrote:
> > >
> > > > вт, 1 дек. 2020 г. в 04:11, Maxim Dounin <mdounin на mdounin.ru>:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Nov 30, 2020 at 11:58:59PM +0500, Илья Шипицин wrote:
> > > > >
> > > > > > привет!
> > > > > >
> > > > > > может кто сталкивался, и знает, что с этим можно сделать.
> > > > > > ситуация - хостинг высокой плотности, на одном IP много доменов.
> > > > > > домены разные, каждый со своей бизнес логикой.
> > > > > >
> > > > > > у Chrome  включается какая-то оптимизация, и типа "ну раз IP
> один,
> > > то я
> > > > > > буду весь трафик гонять через одно tcp подключение". все бы
> ничего,
> > > но
> > > > > > некоторые сайты иногда рвут соединение. а Chrome в итоге рвет не
> > > > > > подключение до конкретного сайта, а вообще все, которые он
> умудрился
> > > > > > связать с этим tcp подключением.
> > > > > >
> > > > > > частный пример - сайт, который иногда формирует очень длинные
> URL, не
> > > > > > помещающиеся в  дефолтный http2_max_field_fize, при возникновение
> > > такой
> > > > > > ситуации Chrome рвет всё до этого IP адреса.
> > > > > >
> > > > > > как-то не по христиански чтоли.
> > > > > >
> > > > > > подумалось, что аналогичных хостингов высокой плотности в
> рассылке
> > > может
> > > > > > быть достаточное количество. не первый же  я с таким столкнулся?
> > > > >
> > > > > Это называется connection reuse, правила прописаны тут:
> > > > >
> > > > > https://tools.ietf.org/html/rfc7540#section-9.1.1
> > > > >
> > > > > В частности:
> > > > >
> > > > >    For "https" resources, connection reuse additionally depends on
> > > > >    having a certificate that is valid for the host in the URI.  The
> > > > >    certificate presented by the server MUST satisfy any checks
> that the
> > > > >    client would perform when forming a new TLS connection for the
> host
> > > > >    in the URI.
> > > > >
> > > > > То есть если хочется, чтобы соединения не reuse'ались, можно
> > > > > сконфигурировать разные сертификаты для разных серверов (или групп
> > > > > серверов).
> > > > >
> > > > > Ну либо руками возвращать 421 по необходимости, проверяя
> > > $ssl_server_name.
> > > > >
> > > >
> > > > в исходниках это вот так
> > > >
> > > >     if ((size_t) len > h2scf->max_field_size) {
> > > >         ngx_log_error(NGX_LOG_INFO, h2c->connection->log, 0,
> > > >                       "client exceeded http2_max_field_size limit");
> > > >
> > > >         return ngx_http_v2_connection_error(h2c,
> > > > NGX_HTTP_V2_ENHANCE_YOUR_CALM);
> > > >     }
> > > >
> > > >
> > > > как можно в этом месте вернуть "по необходимости" 421 ?
> > >
> > > Нет, это фатальная ошибка для соединения, дальнейшая работа с этим
> > > соединением невозможна.  Возвращать 421 надо заранее, до того, как
> > > придёт кривой запрос.
> > >
> > >
> > пардон. я не понимаю, что вы предлагаете.
> > можете привести пример, как сделать ?
>
> Если добавить что-нибудь вроде:
>
>     if ($ssl_server_name != "example.com") {
>         return 421;
>     }
>
> во все релевантные блоки server{}, это предотвратит reuse
> соединений, кроме первых запросов.  Соответственно соединения
> будут отдельными, и при необходимости закрыть соединение - будет
> закрываться только соединение с одним сервером, а не со всеми
> серверами на данном IP.
>
> Ну и обращаю внимание на озвученный выше и проигнорированный
> вариант разных сертификатов.  Он позволяет контроллировать
> поведение на стороне браузера и соответственно более эффективен,
> т.к. нет проблемы первых запросов.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201201/fdc1a63d/attachment-0001.htm>

From alnkapa на gmail.com  Wed Dec  2 04:37:06 2020
From: alnkapa на gmail.com (Aln Kapa)
Date: Wed, 2 Dec 2020 07:37:06 +0300
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <20201201184804.GQ1147@mdounin.ru>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
 <20201201171633.GP1147@mdounin.ru>
 <CAJqqVEWeE+F_B_fRyg2YaXq9ObxReomNQFy6uenOn0K3Eze19Q@mail.gmail.com>
 <20201201184804.GQ1147@mdounin.ru>
Message-ID: <CAJqqVEXrcQO2KzTp36PomHx6p=+oiXE2gL82U+WhK=AAVC1DKw@mail.gmail.com>

Понял.
А ещё вопрос, вот сейчас http3 ждём там все также печально?

вт, 1 дек. 2020 г., 21:48 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Dec 01, 2020 at 08:26:57PM +0300, Aln Kapa wrote:
>
> > От это поворот!
> > без tls и на каждый коннект  отдельное соединение.
>
> Про "без tls" - это уж как сконфигурите.  А то, что соединение
> это, ВНЕЗАПНО, соединение - ну да, так уж получилось.
>
> > А sse  работает так же?
>
> Если под SSE вы имеете в виду Server-Sent Events, то они работают
> в рамках стриминга HTTP-ответа с Content-Type "text/event-stream",
> и могут работать как по HTTP/1.x, так и по HTTP/2.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201202/0839e4be/attachment.htm>

From chipitsine на gmail.com  Wed Dec  2 04:53:41 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 2 Dec 2020 09:53:41 +0500
Subject: =?UTF-8?B?UmU6INGB0YLRgNCw0L3QvdC+0LUg0L/QvtCy0LXQtNC10L3QuNC1IENocm9tZSA=?=
 =?UTF-8?B?0L3QsCBodHRwMg==?=
In-Reply-To: <CAJqqVEXrcQO2KzTp36PomHx6p=+oiXE2gL82U+WhK=AAVC1DKw@mail.gmail.com>
References: <CAFHpkQFCVXQj2i7abzT2kWq+sjua1uKM8Q=db1j87a27Y8hbsQ@mail.gmail.com>
 <20201130231115.GJ1147@mdounin.ru>
 <CAJqqVEXzUeE4E_sec6jTtwGwcfiAZBDaRA=zQVGVz909p4bkvw@mail.gmail.com>
 <20201201171633.GP1147@mdounin.ru>
 <CAJqqVEWeE+F_B_fRyg2YaXq9ObxReomNQFy6uenOn0K3Eze19Q@mail.gmail.com>
 <20201201184804.GQ1147@mdounin.ru>
 <CAJqqVEXrcQO2KzTp36PomHx6p=+oiXE2gL82U+WhK=AAVC1DKw@mail.gmail.com>
Message-ID: <CAFHpkQE1sg-g9=Y78nEOJWD9dorsk62vweMB574yt38QRw54ZQ@mail.gmail.com>

нельзя сказать, чтобы с вебсокетами или http2 всё было прямо печально.
обе годные технологии с какими-то небольшими изъянами проектирования, не
более

ср, 2 дек. 2020 г. в 09:37, Aln Kapa <alnkapa на gmail.com>:

> Понял.
> А ещё вопрос, вот сейчас http3 ждём там все также печально?
>
> вт, 1 дек. 2020 г., 21:48 Maxim Dounin <mdounin на mdounin.ru>:
>
>> Hello!
>>
>> On Tue, Dec 01, 2020 at 08:26:57PM +0300, Aln Kapa wrote:
>>
>> > От это поворот!
>> > без tls и на каждый коннект  отдельное соединение.
>>
>> Про "без tls" - это уж как сконфигурите.  А то, что соединение
>> это, ВНЕЗАПНО, соединение - ну да, так уж получилось.
>>
>> > А sse  работает так же?
>>
>> Если под SSE вы имеете в виду Server-Sent Events, то они работают
>> в рамках стриминга HTTP-ответа с Content-Type "text/event-stream",
>> и могут работать как по HTTP/1.x, так и по HTTP/2.
>>
>> --
>> Maxim Dounin
>> http://mdounin.ru/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201202/d9a856fa/attachment.htm>

From nginx-forum на forum.nginx.org  Tue Dec  8 08:19:42 2020
From: nginx-forum на forum.nginx.org (fbulkin)
Date: Tue, 08 Dec 2020 03:19:42 -0500
Subject: =?UTF-8?B?0J3QtSDRgdGC0LDRgNGC0YPQtdGCIG5naW54LCDQtdGB0LvQuCDRgdC10YDQstC1?=
 =?UTF-8?B?0YAg0LjQtyB1cHN0cmVhbSDQvdC10LTQvtGB0YLRg9C/0LXQvS4=?=
Message-ID: <2c5495d284bb5c3604574fd3869df4b3.NginxMailingListRussian@forum.nginx.org>

Приветствую.

Как запустить nginx. при условии, если часть серверов в upstream
недоступны?

upstream upstream-agw {
    ip_hash;
    server i18s-a-agw1:8080 max_fails=0;
    server i18s-a-agw3:8080 max_fails=0;
}

 i18s-a-agw1:8080 - доступен!
 i18s-a-agw3:8080 - На момент запуска не резолвится

error:
nginx[29440]: nginx: [emerg] host not found in upstream "i18s-a-agw3:8080"
in

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


From chipitsine на gmail.com  Wed Dec  9 18:21:18 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 9 Dec 2020 23:21:18 +0500
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgtCw0YDRgtGD0LXRgiBuZ2lueCwg0LXRgdC70Lgg0YHQtdGA?=
 =?UTF-8?B?0LLQtdGAINC40LcgdXBzdHJlYW0g0L3QtdC00L7RgdGC0YPQv9C10L0u?=
In-Reply-To: <2c5495d284bb5c3604574fd3869df4b3.NginxMailingListRussian@forum.nginx.org>
References: <2c5495d284bb5c3604574fd3869df4b3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQEKTjPg8UYFo11_pcu66_vfbb3+jUnJcUJDv11Zm9b-kw@mail.gmail.com>

я сталкивался с несколькими вариантами

1) платный nginx (там есть отложенный ресолв)
2) haproxy
3) проксировать не на апстрим, а на бекенд напрямую, тогда можно через
переменную ресолвить динамически
4) спрятать ресолв в consul templates

вт, 8 дек. 2020 г. в 13:19, fbulkin <nginx-forum на forum.nginx.org>:

> Приветствую.
>
> Как запустить nginx. при условии, если часть серверов в upstream
> недоступны?
>
> upstream upstream-agw {
>     ip_hash;
>     server i18s-a-agw1:8080 max_fails=0;
>     server i18s-a-agw3:8080 max_fails=0;
> }
>
>  i18s-a-agw1:8080 - доступен!
>  i18s-a-agw3:8080 - На момент запуска не резолвится
>
> error:
> nginx[29440]: nginx: [emerg] host not found in upstream "i18s-a-agw3:8080"
> in
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,290166,290166#msg-290166
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201209/7a653304/attachment.htm>

From nginx-forum на forum.nginx.org  Sun Dec 13 00:53:48 2020
From: nginx-forum на forum.nginx.org (vanzhiganov)
Date: Sat, 12 Dec 2020 19:53:48 -0500
Subject: =?UTF-8?B?UmU6IE5naW54K0x10LA9INCd0LXQvNC90L7QttC60L4g0L7QsdC70LDRh9C90L4g?=
 =?UTF-8?B?0YEgV0VCREFW?=
In-Reply-To: <9ff32402cb1fef2eb7ac51c9be9d24ed.NginxMailingListRussian@forum.nginx.org>
References: <7875fe266a403e004a176b23ca8c3c60.NginxMailingListRussian@forum.nginx.org>
 <9ff32402cb1fef2eb7ac51c9be9d24ed.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1ee09af3d20d4795fc6430d9557fa21d.NginxMailingListRussian@forum.nginx.org>

посмотри тут:

https://github.com/itcod/auth-dav

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


From mdounin на mdounin.ru  Tue Dec 15 15:00:02 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 15 Dec 2020 18:00:02 +0300
Subject: nginx-1.19.6
Message-ID: <20201215150002.GV1147@mdounin.ru>

Изменения в nginx 1.19.6                                          15.12.2020

    *) Исправление: ошибки "no live upstreams", если server в блоке upstream
       был помечен как down.

    *) Исправление: при использовании HTTPS в рабочем процессе мог произойти
       segmentation fault; ошибка появилась в 1.19.5.

    *) Исправление: nginx возвращал ошибку 400 на запросы вида
       "GET http://example.com?args HTTP/1.0".

    *) Исправление: в модулях ngx_http_flv_module и ngx_http_mp4_module.
       Спасибо Chris Newton.


-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Tue Dec 22 08:48:37 2020
From: nginx-forum на forum.nginx.org (Alexey Koscheev)
Date: Tue, 22 Dec 2020 03:48:37 -0500
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDQv9GA0Lgg0L/RgNC+0LrRgdC40YDQvtCy0LDQvdC4?=
 =?UTF-8?B?0Lgg0L3QsCBuZ2lueCDRgSBzc2wgcmVqZWN0IGhhbmRzaGFrZSBvbg==?=
Message-ID: <15f4ad030a948811a823582d66da7b61.NginxMailingListRussian@forum.nginx.org>

Сервер1 (принимает запросы и проксирует на сервер 2):

server {
listen a.b.c.d:443 ssl;
server_name
abcd.example
;
access_log off;
ssl_certificate     path_to.crt;
ssl_certificate_key path_to.key;
location / {
proxy_pass https://b.c.d.e:443;
proxy_ssl_server_name on;
proxy_set_header Host $host;
}
}

Сервер2
    server {
        listen b.c.d.e:443 ssl default_server;
        server_name _;

        access_log off;
        ssl_certificate /usr/local/nginx/conf/cert.pem;
        ssl_certificate_key /usr/local/nginx/conf/key.pem;
        ssl_reject_handshake on;

        location / {
            return 444;
        }
    }

server {
listen b.c.d.e:443 ssl http2;
server_name abcd.example
;
access_log access.log combined;
root /home2/xyz/abcd.example/WWW;
ssl_certificate     path_to.crt;
ssl_certificate_key path_to.key;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate path_to.trusted;
location / {
proxy_pass http://127.0.0.1:80;
}

}


Если на Сервер2 ssl_reject_handshake on;, то запросы к Сервер 1 завершаются
502 ошибкой. В error лог такое:
2020/12/22 11:05:13 [crit] 57654#0: *13192673 SSL_do_handshake() failed
(SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized
name:SSL alert number 112) while SSL handshaking to upstream, client:
192.168.10.250, server: abcd.example, request: "GET / HTTP/2.0", upstream:
"https://b.c.d.e:443/", host: "xn--b1aghahdtcfeb2aifj5e.xn--p1ai"

Наличие строк 
proxy_ssl_server_name on;
proxy_set_header Host $host;
в конфиге server на Сервер1 никак не влияет на проблему.

В чем может быть дело?

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


From nginx-forum на forum.nginx.org  Tue Dec 22 09:57:31 2020
From: nginx-forum на forum.nginx.org (Alexey Koscheev)
Date: Tue, 22 Dec 2020 04:57:31 -0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0L/RgNC4INC/0YDQvtC60YHQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC4INC90LAgbmdpbngg0YEgc3NsIHJlamVjdCBoYW5kc2hha2Ugb24=?=
In-Reply-To: <15f4ad030a948811a823582d66da7b61.NginxMailingListRussian@forum.nginx.org>
References: <15f4ad030a948811a823582d66da7b61.NginxMailingListRussian@forum.nginx.org>
Message-ID: <510bc57b25638ee5900324be67272d41.NginxMailingListRussian@forum.nginx.org>

Сам себе отвечу :)

На Сервер1 не хватало строки:
proxy_ssl_name $host;

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


From chipitsine на gmail.com  Tue Dec 22 11:52:36 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 22 Dec 2020 16:52:36 +0500
Subject: =?UTF-8?B?0YDQtdC20LjQvCBkcnkgcnVuINC00LvRjyAicmV0dXJuIDQyMSI=?=
Message-ID: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>

привет!

рассматриваем вариант

if ($some_condition != $host) { return 421; }

вопрос - как можно по дешевому в этом месте сделать "логирование вместо
return" ?

Илья Шипицин
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201222/6d78e005/attachment.htm>

From bgx на protva.ru  Tue Dec 22 12:32:37 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 22 Dec 2020 15:32:37 +0300
Subject: =?UTF-8?B?UmU6INGA0LXQttC40LwgZHJ5IHJ1biDQtNC70Y8gInJldHVybiA0MjEi?=
In-Reply-To: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
References: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
Message-ID: <20201222123237.GF2688@protva.ru>

On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
>    привет!
>    рассматриваем вариант
>    if ($some_condition != $host) { return 421; }
>    вопрос - как можно по дешевому в этом месте сделать "логирование вместо
>    return" ?

 return 302 <logger-url>
 ?
 
 Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
 Логгирование это не ответ, а этап обработки запроса.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Tue Dec 22 13:17:13 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 22 Dec 2020 18:17:13 +0500
Subject: =?UTF-8?B?UmU6INGA0LXQttC40LwgZHJ5IHJ1biDQtNC70Y8gInJldHVybiA0MjEi?=
In-Reply-To: <20201222123237.GF2688@protva.ru>
References: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
 <20201222123237.GF2688@protva.ru>
Message-ID: <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>

грубо - сделать все то же самое, что было бы без "return 421" +
залогировать попытку вернуть.
классический dry run

error_page 421  = @handler_421;

location / {
   if ($some_condition != $host) { return 421; }

   proxy_pass http://upstream;

   access_log /var/log/my.log;
}

location @handler_421 {
   proxy_pass http://upstream;

   access_log /var/log/my.log;
   access_log /var/log/additional.log special_format;
}



On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov <bgx на protva.ru> wrote:

> On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
> >    привет!
> >    рассматриваем вариант
> >    if ($some_condition != $host) { return 421; }
> >    вопрос - как можно по дешевому в этом месте сделать "логирование
> вместо
> >    return" ?
>
>  return 302 <logger-url>
>  ?
>
>  Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
>  Логгирование это не ответ, а этап обработки запроса.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201222/01ddaa62/attachment.htm>

From bgx на protva.ru  Tue Dec 22 14:57:38 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Tue, 22 Dec 2020 17:57:38 +0300
Subject: =?UTF-8?B?UmU6INGA0LXQttC40LwgZHJ5IHJ1biDQtNC70Y8gInJldHVybiA0MjEi?=
In-Reply-To: <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>
References: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
 <20201222123237.GF2688@protva.ru>
 <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>
Message-ID: <X+IJYoRt40T49MSj@vvs.protva.ru>

On Tue, Dec 22, 2020 at 06:17:13PM +0500, Илья Шипицин wrote:
>    грубо - сделать все то же самое, что было бы без "return 421" +
>    залогировать попытку вернуть.
>    классический dry run
>    error_page 421  = @handler_421;
>    location / {
>       if ($some_condition != $host) { return 421; }
>       proxy_pass http://upstream;
>       access_log /var/log/my.log;
>    }
>    location @handler_421 {
>       proxy_pass http://upstream;
>       access_log /var/log/my.log;
>       access_log /var/log/additional.log special_format;
>    }

 Какой же он "dry" если в хендлере есть то же самое обращение апстриму?
 Тут просто добавочное логгирование... И статус чисто внутренний, он может
 быть любой, не обязательно 421. Тогда чем этот паровоз не устраивает?


>    On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov <[3]bgx на protva.ru> wrote:
> 
>      On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
>      >    привет!
>      >    рассматриваем вариант
>      >    if ($some_condition != $host) { return 421; }
>      >    вопрос - как можно по дешевому в этом месте сделать "логирование
>      вместо
>      >    return" ?
> 
>       return 302 <logger-url>
>       ?
> 
>       Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
>       Логгирование это не ответ, а этап обработки запроса.
>      --
>       Eugene Berdnikov
>      _______________________________________________
>      nginx-ru mailing list
>      [4]nginx-ru на nginx.org
>      [5]http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> References
> 
>    Visible links
>    1. http://upstream/
>    2. http://upstream/
>    3. mailto:bgx на protva.ru
>    4. mailto:nginx-ru на nginx.org
>    5. http://mailman.nginx.org/mailman/listinfo/nginx-ru

> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Tue Dec 22 15:29:22 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 22 Dec 2020 20:29:22 +0500
Subject: =?UTF-8?B?UmU6INGA0LXQttC40LwgZHJ5IHJ1biDQtNC70Y8gInJldHVybiA0MjEi?=
In-Reply-To: <X+IJYoRt40T49MSj@vvs.protva.ru>
References: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
 <20201222123237.GF2688@protva.ru>
 <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>
 <X+IJYoRt40T49MSj@vvs.protva.ru>
Message-ID: <CAFHpkQE++qUFCKECp0xhUvTozzHNZ6RrKLBSnTMsuuhzX-RQ=g@mail.gmail.com>

вт, 22 дек. 2020 г. в 19:58, Evgeniy Berdnikov <bgx на protva.ru>:

> On Tue, Dec 22, 2020 at 06:17:13PM +0500, Илья Шипицин wrote:
> >    грубо - сделать все то же самое, что было бы без "return 421" +
> >    залогировать попытку вернуть.
> >    классический dry run
> >    error_page 421  = @handler_421;
> >    location / {
> >       if ($some_condition != $host) { return 421; }
> >       proxy_pass http://upstream;
> >       access_log /var/log/my.log;
> >    }
> >    location @handler_421 {
> >       proxy_pass http://upstream;
> >       access_log /var/log/my.log;
> >       access_log /var/log/additional.log special_format;
> >    }
>
>  Какой же он "dry" если в хендлере есть то же самое обращение апстриму?
>

изначально у меня вот так

location / {
  proxy_pass http://upstream;
}

я хочу добавить if ($some_condition != $host) { return 421; } в режиме, в
котором поведение не поменяется, но я убеждусь, что конструкция будет
срабатывать ровно тогда, когда я имею в виду



>  Тут просто добавочное логгирование... И статус чисто внутренний, он может
>  быть любой, не обязательно 421. Тогда чем этот паровоз не устраивает?
>


с POST-ами есть вопросы. ну и вообще конструкция громоздкая.


>
>
> >    On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov <[3]bgx на protva.ru>
> wrote:
> >
> >      On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
> >      >    привет!
> >      >    рассматриваем вариант
> >      >    if ($some_condition != $host) { return 421; }
> >      >    вопрос - как можно по дешевому в этом месте сделать
> "логирование
> >      вместо
> >      >    return" ?
> >
> >       return 302 <logger-url>
> >       ?
> >
> >       Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
> >       Логгирование это не ответ, а этап обработки запроса.
> >      --
> >       Eugene Berdnikov
> >      _______________________________________________
> >      nginx-ru mailing list
> >      [4]nginx-ru на nginx.org
> >      [5]http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > References
> >
> >    Visible links
> >    1. http://upstream/
> >    2. http://upstream/
> >    3. mailto:bgx на protva.ru
> >    4. mailto:nginx-ru на nginx.org
> >    5. http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201222/bc5a5afc/attachment-0001.htm>

From oleg на mamontov.net  Tue Dec 22 18:22:44 2020
From: oleg на mamontov.net (Oleg A. Mamontov)
Date: Tue, 22 Dec 2020 21:22:44 +0300
Subject: =?UTF-8?B?UmU6INGA0LXQttC40LwgZHJ5IHJ1biDQtNC70Y8gInJldHVybiA0MjEi?=
In-Reply-To: <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>
References: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
 <20201222123237.GF2688@protva.ru>
 <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>
Message-ID: <20201222182244.ofqklygihsuok54q@xenon.mamontov.net>

On Tue, Dec 22, 2020 at 06:17:13PM +0500, Илья Шипицин wrote:
>грубо - сделать все то же самое, что было бы без "return 421" + залогировать
>попытку вернуть.
>классический dry run

Возможно, вам подойдет дополнительный access_log по условию:
---
map $host $condition {
     default         1;
     some_condition  0;
}
...
location / {
   proxy_pass http://upstream;

   access_log /var/log/my.log;
   access_log /var/log/conditional.log if=$condition;
}
---

>error_page 421  = @handler_421;
>
>location / {
>   if ($some_condition != $host) { return 421; }
>
>   proxy_pass http://upstream;
>
>   access_log /var/log/my.log;
>}
>
>location @handler_421 {
>   proxy_pass http://upstream;
>
>   access_log /var/log/my.log;
>   access_log /var/log/additional.log special_format;
>}
>
>
>
>On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov <bgx на protva.ru> wrote:
>
>    On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
>    >    привет!
>    >    рассматриваем вариант
>    >    if ($some_condition != $host) { return 421; }
>    >    вопрос - как можно по дешевому в этом месте сделать "логирование
>    вместо
>    >    return" ?
>
>     return 302 <logger-url>
>     ?
>
>     Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
>     Логгирование это не ответ, а этап обработки запроса.
>    --
>     Eugene Berdnikov
>    _______________________________________________
>    nginx-ru mailing list
>    nginx-ru на nginx.org
>    http://mailman.nginx.org/mailman/listinfo/nginx-ru
>

>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
Cheers,
Oleg A. Mamontov

mailto: oleg на mamontov.net

skype:  lonerr11
cell:   +7 (903) 798-1352

From chipitsine на gmail.com  Tue Dec 22 19:00:27 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 23 Dec 2020 00:00:27 +0500
Subject: =?UTF-8?B?UmU6INGA0LXQttC40LwgZHJ5IHJ1biDQtNC70Y8gInJldHVybiA0MjEi?=
In-Reply-To: <20201222182244.ofqklygihsuok54q@xenon.mamontov.net>
References: <CAFHpkQGHO1yOpKKQfKQ6jUxm-_7m+HcfbEQcTY_xAFqRtriogw@mail.gmail.com>
 <20201222123237.GF2688@protva.ru>
 <CAFHpkQFvCEm928QPUvVfPfFZoVMdApzzyy3G6E5XR-G9oX9x0g@mail.gmail.com>
 <20201222182244.ofqklygihsuok54q@xenon.mamontov.net>
Message-ID: <CAFHpkQGJPF7fYxgr8m8b=bNcRe2f2N7uiJe8QZY7JPjhHTycfA@mail.gmail.com>

Да, так и сделаю. Спасибо

On Tue, Dec 22, 2020, 11:22 PM Oleg A. Mamontov <oleg на mamontov.net> wrote:

> On Tue, Dec 22, 2020 at 06:17:13PM +0500, Илья Шипицин wrote:
> >грубо - сделать все то же самое, что было бы без "return 421" +
> залогировать
> >попытку вернуть.
> >классический dry run
>
> Возможно, вам подойдет дополнительный access_log по условию:
> ---
> map $host $condition {
>      default         1;
>      some_condition  0;
> }
> ...
> location / {
>    proxy_pass http://upstream;
>
>    access_log /var/log/my.log;
>    access_log /var/log/conditional.log if=$condition;
> }
> ---
>
> >error_page 421  = @handler_421;
> >
> >location / {
> >   if ($some_condition != $host) { return 421; }
> >
> >   proxy_pass http://upstream;
> >
> >   access_log /var/log/my.log;
> >}
> >
> >location @handler_421 {
> >   proxy_pass http://upstream;
> >
> >   access_log /var/log/my.log;
> >   access_log /var/log/additional.log special_format;
> >}
> >
> >
> >
> >On Tue, Dec 22, 2020, 5:32 PM Evgeniy Berdnikov <bgx на protva.ru> wrote:
> >
> >    On Tue, Dec 22, 2020 at 04:52:36PM +0500, Илья Шипицин wrote:
> >    >    привет!
> >    >    рассматриваем вариант
> >    >    if ($some_condition != $host) { return 421; }
> >    >    вопрос - как можно по дешевому в этом месте сделать "логирование
> >    вместо
> >    >    return" ?
> >
> >     return 302 <logger-url>
> >     ?
> >
> >     Вообще, что значит "вместо"? Какой-то ответ на запрос должен быть.
> >     Логгирование это не ответ, а этап обработки запроса.
> >    --
> >     Eugene Berdnikov
> >    _______________________________________________
> >    nginx-ru mailing list
> >    nginx-ru на nginx.org
> >    http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
>
> >_______________________________________________
> >nginx-ru mailing list
> >nginx-ru на nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
> --
> Cheers,
> Oleg A. Mamontov
>
> mailto: oleg на mamontov.net
>
> skype:  lonerr11
> cell:   +7 (903) 798-1352
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201223/a1922442/attachment.htm>

From chipitsine на gmail.com  Wed Dec 23 07:26:44 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 23 Dec 2020 12:26:44 +0500
Subject: =?UTF-8?B?0L/RgNC10LTQv9C+0LvQsNCz0LDQtdGC0YHRjyDQu9C4INC40L3QuNGG0LjQsNC7?=
 =?UTF-8?B?0LjQt9Cw0YbQuNGPINCy0YDQtdC80LXQvdC90YvRhSDQv9Cw0L/QvtC6INC/?=
 =?UTF-8?B?0YDQuCDQstGL0LfQvtCy0LUgIm5naW54IC10IiA/?=
Message-ID: <CAFHpkQGv=1qodjVA=X+kSgndfDscX6zEbygnu9Wa8DvG3vo7qA@mail.gmail.com>

привет!

беру чистый centos, ставлю nginx из стокового репозитория.
в /var/cache/nginx - пусто. ожидаемо

делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.

почему так ?


[root на centos system]# cd /var/cache/nginx/
[root на centos nginx]# ls
[root на centos nginx]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
[root на centos nginx]# ls
client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
[root на centos nginx]#



Илья Шипицин
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201223/8375a604/attachment-0001.htm>

From marck на rinet.ru  Wed Dec 23 08:53:52 2020
From: marck на rinet.ru (Dmitry Morozovsky)
Date: Wed, 23 Dec 2020 11:53:52 +0300 (MSK)
Subject: =?UTF-8?B?UmU6INC/0YDQtdC00L/QvtC70LDQs9Cw0LXRgtGB0Y8g0LvQuCDQuNC90LjRhtC4?=
 =?UTF-8?B?0LDQu9C40LfQsNGG0LjRjyDQstGA0LXQvNC10L3QvdGL0YUg0L/QsNC/0L4=?=
 =?UTF-8?B?0Log0L/RgNC4INCy0YvQt9C+0LLQtSAibmdpbnggLXQiID8=?=
In-Reply-To: <CAFHpkQGv=1qodjVA=X+kSgndfDscX6zEbygnu9Wa8DvG3vo7qA@mail.gmail.com>
References: <CAFHpkQGv=1qodjVA=X+kSgndfDscX6zEbygnu9Wa8DvG3vo7qA@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.2012231153061.76785@woozle.rinet.ru>

On Wed, 23 Dec 2020, Илья Шипицин wrote:

> привет!
> 
> беру чистый centos, ставлю nginx из стокового репозитория.
> в /var/cache/nginx - пусто. ожидаемо
> 
> делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.
> 
> почему так ?


ожидаемо: чтоб проверить, что прав хватает.

доплогику засовывать, чтобы удалять пустые? а если параллельно nginx уже 
бегает, просто ничего туда ещё не написал?

> 
> 
> [root на centos system]# cd /var/cache/nginx/
> [root на centos nginx]# ls
> [root на centos nginx]# nginx -t
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> [root на centos nginx]# ls
> client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
> [root на centos nginx]#
> 
> 
> 
> Илья Шипицин
> 

-- 
Sincerely,
D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                    marck на FreeBSD.org ]
---------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net ***
---------------------------------------------------------------------------

From chipitsine на gmail.com  Wed Dec 23 09:55:41 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 23 Dec 2020 14:55:41 +0500
Subject: =?UTF-8?B?UmU6INC/0YDQtdC00L/QvtC70LDQs9Cw0LXRgtGB0Y8g0LvQuCDQuNC90LjRhtC4?=
 =?UTF-8?B?0LDQu9C40LfQsNGG0LjRjyDQstGA0LXQvNC10L3QvdGL0YUg0L/QsNC/0L4=?=
 =?UTF-8?B?0Log0L/RgNC4INCy0YvQt9C+0LLQtSAibmdpbnggLXQiID8=?=
In-Reply-To: <alpine.BSF.2.00.2012231153061.76785@woozle.rinet.ru>
References: <CAFHpkQGv=1qodjVA=X+kSgndfDscX6zEbygnu9Wa8DvG3vo7qA@mail.gmail.com>
 <alpine.BSF.2.00.2012231153061.76785@woozle.rinet.ru>
Message-ID: <CAFHpkQGB_C+bba-uG7vmZOGSsO1ppTpfEd76Hk-40DdnUjeeQQ@mail.gmail.com>

ср, 23 дек. 2020 г. в 13:54, Dmitry Morozovsky <marck на rinet.ru>:

> On Wed, 23 Dec 2020, Илья Шипицин wrote:
>
> > привет!
> >
> > беру чистый centos, ставлю nginx из стокового репозитория.
> > в /var/cache/nginx - пусто. ожидаемо
> >
> > делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.
> >
> > почему так ?
>
>
> ожидаемо: чтоб проверить, что прав хватает.
>
> доплогику засовывать, чтобы удалять пустые? а если параллельно nginx уже
> бегает, просто ничего туда ещё не написал?
>

мы ловим "access denied" на уже запущенном и работающем воркере в момент,
когда запускаем "nginx -t"

ну и как бы не очень ожидаемо, что тестирование конфигурации это еще
создание временных папок



>
> >
> >
> > [root на centos system]# cd /var/cache/nginx/
> > [root на centos nginx]# ls
> > [root на centos nginx]# nginx -t
> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> > nginx: configuration file /etc/nginx/nginx.conf test is successful
> > [root на centos nginx]# ls
> > client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
> > [root на centos nginx]#
> >
> >
> >
> > Илья Шипицин
> >
>
> --
> Sincerely,
> D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
> [ FreeBSD committer:                                    marck на FreeBSD.org
> ]
> ---------------------------------------------------------------------------
> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net
> ***
> ---------------------------------------------------------------------------
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201223/7cc16917/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Dec 23 12:02:32 2020
From: nginx-forum на forum.nginx.org (mouserok)
Date: Wed, 23 Dec 2020 07:02:32 -0500
Subject: =?UTF-8?B?0J/Rg9GF0L3QtdGCINCx0YPRhNC10YAg0LrRjdGI0LAg0L/RgNC4INC90LDQs9GA?=
 =?UTF-8?B?0YPQt9C60LU=?=
Message-ID: <c407ee67edae38f7824e51be2e97f877.NginxMailingListRussian@forum.nginx.org>

Пухнет кэш памяти если включить логирование. При нагрузке это становится
критичным - память съедается и не высвобождается.

cat nginx.conf
--------------------------------------------------------------------------------------------
worker_processes  2;

pid        pid/nginx.pid;

events {
    use epoll;
    worker_connections  2048;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '[$time_local] "$request" $status $body_bytes_sent';

    access_log off;
    sendfile        on;

    keepalive_timeout  65;

server {
    listen       8182;
    access_log  logs/8182.access.log main;
    root /opt/http;
    }
}
--------------------------------------------------------------------------------------------

./nginx -V
--------------------------------------------------------------------------------------------
nginx version: nginx/1.17.8
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
built with OpenSSL 1.1.1d  10 Sep 2019
TLS SNI support enabled
configure arguments: --prefix=/opt/nginx --with-pcre=../pcre-8.43
--with-zlib=../zlib-1.2.11 --with-http_ssl_module
--with-openssl=../openssl-1.1.1d --with-http_realip_module
--with-http_stub_status_module
--------------------------------------------------------------------------------------------

free -m
              total        used        free      shared  buff/cache  
available
Mem:           4782         274        3501          73        1006       
4134
Swap:          2047           0        2047
--------------------------------------------------------------------------------------------
head -n1 ../logs/8182.access.log
[23/Dec/2020:13:47:58 +0200] "GET /1.html HTTP/1.1" 200 4
--------------------------------------------------------------------------------------------
tail -n1 ../logs/8182.access.log
[23/Dec/2020:13:48:09 +0200] "GET /1.html HTTP/1.1" 200 4
--------------------------------------------------------------------------------------------
cat ../logs/8182.access.log | wc -l
104262
--------------------------------------------------------------------------------------------
free -m
              total        used        free      shared  buff/cache  
available
Mem:           4782         276        3494          73        1012       
4133
Swap:          2047           0        2047

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


From bgx на protva.ru  Wed Dec 23 12:44:20 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 23 Dec 2020 15:44:20 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRhdC90LXRgiDQsdGD0YTQtdGAINC60Y3RiNCwINC/0YDQuCDQvdCw?=
 =?UTF-8?B?0LPRgNGD0LfQutC1?=
In-Reply-To: <c407ee67edae38f7824e51be2e97f877.NginxMailingListRussian@forum.nginx.org>
References: <c407ee67edae38f7824e51be2e97f877.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20201223124420.GI2656@protva.ru>

On Wed, Dec 23, 2020 at 07:02:32AM -0500, mouserok wrote:
> Пухнет кэш памяти если включить логирование. При нагрузке это становится
> критичным - память съедается и не высвобождается.

 Вы что конкретно имеете в виду под "буфер кэша" и "кэш памяти"?

 Покажите, где в приведённых числах что-то пухнет, а также поясните,
 почему источником проблемы считаете nginx. Он пухнет?
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Wed Dec 23 13:34:11 2020
From: nginx-forum на forum.nginx.org (mouserok)
Date: Wed, 23 Dec 2020 08:34:11 -0500
Subject: =?UTF-8?B?UmU6INCf0YPRhdC90LXRgiDQsdGD0YTQtdGAINC60Y3RiNCwINC/0YDQuCDQvdCw?=
 =?UTF-8?B?0LPRgNGD0LfQutC1?=
In-Reply-To: <20201223124420.GI2656@protva.ru>
References: <20201223124420.GI2656@protva.ru>
Message-ID: <760da090669b0fef2b7803663a28fd0d.NginxMailingListRussian@forum.nginx.org>

было 1006
стало 1012
эти значения есть в начальном сообщении 
запускались до и после нагрузки

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


From bgx на protva.ru  Wed Dec 23 14:34:10 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Wed, 23 Dec 2020 17:34:10 +0300
Subject: =?UTF-8?B?UmU6INCf0YPRhdC90LXRgiDQsdGD0YTQtdGAINC60Y3RiNCwINC/0YDQuCDQvdCw?=
 =?UTF-8?B?0LPRgNGD0LfQutC1?=
In-Reply-To: <760da090669b0fef2b7803663a28fd0d.NginxMailingListRussian@forum.nginx.org>
References: <20201223124420.GI2656@protva.ru>
 <760da090669b0fef2b7803663a28fd0d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <X+NVYtZQ8b1D1bf0@sie.protva.ru>

On Wed, Dec 23, 2020 at 08:34:11AM -0500, mouserok wrote:
> было 1006
> стало 1012
> эти значения есть в начальном сообщении 
> запускались до и после нагрузки

 Вы не ответили на заданные вопросы. Если нет понимания, что означают
 эти цифры, то нет и никакого смысла отвечать почему они меняются.
 Никаких проблем с nginx этот кейс не иллюстрирует.
-- 
 Eugene Berdnikov

From chipitsine на gmail.com  Wed Dec 23 15:31:18 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 23 Dec 2020 20:31:18 +0500
Subject: =?UTF-8?B?UmU6INC/0YDQtdC00L/QvtC70LDQs9Cw0LXRgtGB0Y8g0LvQuCDQuNC90LjRhtC4?=
 =?UTF-8?B?0LDQu9C40LfQsNGG0LjRjyDQstGA0LXQvNC10L3QvdGL0YUg0L/QsNC/0L4=?=
 =?UTF-8?B?0Log0L/RgNC4INCy0YvQt9C+0LLQtSAibmdpbnggLXQiID8=?=
In-Reply-To: <CAFHpkQGB_C+bba-uG7vmZOGSsO1ppTpfEd76Hk-40DdnUjeeQQ@mail.gmail.com>
References: <CAFHpkQGv=1qodjVA=X+kSgndfDscX6zEbygnu9Wa8DvG3vo7qA@mail.gmail.com>
 <alpine.BSF.2.00.2012231153061.76785@woozle.rinet.ru>
 <CAFHpkQGB_C+bba-uG7vmZOGSsO1ppTpfEd76Hk-40DdnUjeeQQ@mail.gmail.com>
Message-ID: <CAFHpkQENuN7BdCrVz+SJbFecw=Z-4LeuqSuki8JKjt9U23xviQ@mail.gmail.com>

отбой. наши "access denied"  вызваны сугубо нашими локальными приколами

On Wed, Dec 23, 2020, 2:55 PM Илья Шипицин <chipitsine на gmail.com> wrote:

>
>
> ср, 23 дек. 2020 г. в 13:54, Dmitry Morozovsky <marck на rinet.ru>:
>
>> On Wed, 23 Dec 2020, Илья Шипицин wrote:
>>
>> > привет!
>> >
>> > беру чистый centos, ставлю nginx из стокового репозитория.
>> > в /var/cache/nginx - пусто. ожидаемо
>> >
>> > делаю "nginx -t", и уже не пусто. а вот это не очень ожидаемо было.
>> >
>> > почему так ?
>>
>>
>> ожидаемо: чтоб проверить, что прав хватает.
>>
>> доплогику засовывать, чтобы удалять пустые? а если параллельно nginx уже
>> бегает, просто ничего туда ещё не написал?
>>
>
> мы ловим "access denied" на уже запущенном и работающем воркере в момент,
> когда запускаем "nginx -t"
>
> ну и как бы не очень ожидаемо, что тестирование конфигурации это еще
> создание временных папок
>
>
>
>>
>> >
>> >
>> > [root на centos system]# cd /var/cache/nginx/
>> > [root на centos nginx]# ls
>> > [root на centos nginx]# nginx -t
>> > nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
>> > nginx: configuration file /etc/nginx/nginx.conf test is successful
>> > [root на centos nginx]# ls
>> > client_temp  fastcgi_temp  proxy_temp  scgi_temp  uwsgi_temp
>> > [root на centos nginx]#
>> >
>> >
>> >
>> > Илья Шипицин
>> >
>>
>> --
>> Sincerely,
>> D.Marck                                        [DM5020, MCK-RIPE,
>> DM3-RIPN]
>> [ FreeBSD committer:                                    marck на FreeBSD.org
>> ]
>>
>> ---------------------------------------------------------------------------
>> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net
>> ***
>>
>> ---------------------------------------------------------------------------
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201223/ed0e0b91/attachment.htm>

From mdounin на mdounin.ru  Wed Dec 23 16:55:09 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 23 Dec 2020 19:55:09 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0L/RgNC4INC/0YDQvtC60YHQuNGA0L7QstCw?=
 =?UTF-8?B?0L3QuNC4INC90LAgbmdpbngg0YEgc3NsIHJlamVjdCBoYW5kc2hha2Ugb24=?=
In-Reply-To: <15f4ad030a948811a823582d66da7b61.NginxMailingListRussian@forum.nginx.org>
References: <15f4ad030a948811a823582d66da7b61.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20201223165509.GF1147@mdounin.ru>

Hello!

On Tue, Dec 22, 2020 at 03:48:37AM -0500, Alexey Koscheev wrote:

> Сервер1 (принимает запросы и проксирует на сервер 2):
> 
> server {
> listen a.b.c.d:443 ssl;
> server_name
> abcd.example
> ;
> access_log off;
> ssl_certificate     path_to.crt;
> ssl_certificate_key path_to.key;
> location / {
> proxy_pass https://b.c.d.e:443;
> proxy_ssl_server_name on;
> proxy_set_header Host $host;
> }
> }
> 
> Сервер2
>     server {
>         listen b.c.d.e:443 ssl default_server;
>         server_name _;
> 
>         access_log off;
>         ssl_certificate /usr/local/nginx/conf/cert.pem;
>         ssl_certificate_key /usr/local/nginx/conf/key.pem;
>         ssl_reject_handshake on;
> 
>         location / {
>             return 444;
>         }
>     }
> 
> server {
> listen b.c.d.e:443 ssl http2;
> server_name abcd.example
> ;
> access_log access.log combined;
> root /home2/xyz/abcd.example/WWW;
> ssl_certificate     path_to.crt;
> ssl_certificate_key path_to.key;
> ssl_stapling on;
> ssl_stapling_verify on;
> ssl_trusted_certificate path_to.trusted;
> location / {
> proxy_pass http://127.0.0.1:80;
> }
> 
> }
> 
> 
> Если на Сервер2 ssl_reject_handshake on;, то запросы к Сервер 1 завершаются
> 502 ошибкой. В error лог такое:
> 2020/12/22 11:05:13 [crit] 57654#0: *13192673 SSL_do_handshake() failed
> (SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized
> name:SSL alert number 112) while SSL handshaking to upstream, client:
> 192.168.10.250, server: abcd.example, request: "GET / HTTP/2.0", upstream:
> "https://b.c.d.e:443/", host: "xn--b1aghahdtcfeb2aifj5e.xn--p1ai"
> 
> Наличие строк 
> proxy_ssl_server_name on;
> proxy_set_header Host $host;
> в конфиге server на Сервер1 никак не влияет на проблему.
> 
> В чем может быть дело?

Для передачи имени "abcd.example" в рамках SSL handshake 
недостаточно включить proxy_ssl_server_name, т.к. в директиве 
proxy_pass у вас указано "https://b.c.d.e:443".  Нужно либо 
указать правильное имя в директиве proxy_pass, либо задать явно 
имя для SSL handshake с помощью директивы proxy_ssl_name 
(http://nginx.org/r/proxy_ssl_name).

Что до директивы proxy_set_header, то она задаёт заголовок 
HTTP-запроса, и никак не влияет на имена, используемые в 
SSL handshake.

-- 
Maxim Dounin
http://mdounin.ru/

From marck на rinet.ru  Wed Dec 23 18:51:44 2020
From: marck на rinet.ru (Dmitry Morozovsky)
Date: Wed, 23 Dec 2020 21:51:44 +0300 (MSK)
Subject: =?UTF-8?B?UmU6INC/0YDQtdC00L/QvtC70LDQs9Cw0LXRgtGB0Y8g0LvQuCDQuNC90LjRhtC4?=
 =?UTF-8?B?0LDQu9C40LfQsNGG0LjRjyDQstGA0LXQvNC10L3QvdGL0YUg0L/QsNC/0L4=?=
 =?UTF-8?B?0Log0L/RgNC4INCy0YvQt9C+0LLQtSAibmdpbnggLXQiID8=?=
In-Reply-To: <CAFHpkQGB_C+bba-uG7vmZOGSsO1ppTpfEd76Hk-40DdnUjeeQQ@mail.gmail.com>
References: <CAFHpkQGv=1qodjVA=X+kSgndfDscX6zEbygnu9Wa8DvG3vo7qA@mail.gmail.com>
 <alpine.BSF.2.00.2012231153061.76785@woozle.rinet.ru>
 <CAFHpkQGB_C+bba-uG7vmZOGSsO1ppTpfEd76Hk-40DdnUjeeQQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.2012232150440.76785@woozle.rinet.ru>

On Wed, 23 Dec 2020, Илья Шипицин wrote:

[snip]

> ну и как бы не очень ожидаемо, что тестирование конфигурации это еще
> создание временных папок

https://nginx.org/ru/docs/switches.html

-t . тестирование конфигурационного файла: nginx проверяет синтаксическую 
правильность конфигурации, 

**а затем пытается открыть файлы, описанные в конфигурации.**

-- 
Sincerely,
D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                    marck на FreeBSD.org ]
---------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net ***
---------------------------------------------------------------------------

From nginx-forum на forum.nginx.org  Wed Dec 23 22:33:36 2020
From: nginx-forum на forum.nginx.org (pavlusha23)
Date: Wed, 23 Dec 2020 17:33:36 -0500
Subject: =?UTF-8?B?0J/QvtGH0LjQvdC40YLQtSDRjdGC0L7RgiDRhNC+0YDRg9C8LCDQvdC10LLQvtC3?=
 =?UTF-8?B?0LzQvtC20L3QviDQt9Cw0YDQtdCz0LjRgdGC0YDQuNGA0L7QstCw0YLRjNGB?=
 =?UTF-8?B?0Y8uLi4=?=
Message-ID: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>

(Почините этот форум, невозможно зарегистрироваться если почта расположена
на серверах с современными строгими антиспам настройками.)

Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться, но не
могут. Я проверил сам, действительно невозможно. Они мне скинули логи своей
почты тоже. У всех ситуация примерно одинакова:

sender verify fail for <www на teresa.liquidhost.co>: all relevant MX records
point to non-existent hosts or (invalidly) to IP addresses.
F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>: Sender verify
failed

Т.е. этот форум для служебной рассылки использует какой-то левый
несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS неверно
настроен, и естественно такие письма сразу отсекаются почтовыми серверами
(по крайней мере всеми на базе ispmanager последних версий) на этапе
приёмки, даже в спам не попадают. Прошу администрацию уделить этому
внимание, вроде айтишники жеж.

У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем спасибо
и с наступающим рождеством!

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


From nginx-forum на forum.nginx.org  Thu Dec 24 05:58:21 2020
From: nginx-forum на forum.nginx.org (mouserok)
Date: Thu, 24 Dec 2020 00:58:21 -0500
Subject: =?UTF-8?B?UmU6INCf0YPRhdC90LXRgiDQsdGD0YTQtdGAINC60Y3RiNCwINC/0YDQuCDQvdCw?=
 =?UTF-8?B?0LPRgNGD0LfQutC1?=
In-Reply-To: <X+NVYtZQ8b1D1bf0@sie.protva.ru>
References: <X+NVYtZQ8b1D1bf0@sie.protva.ru>
Message-ID: <06e504f55938245cfb4db2faa8a08bcd.NginxMailingListRussian@forum.nginx.org>

ответ в числах приведен выше в первоначальном сообщении
кэш НЕ пухнет если вырубить логирование
как сделать чтоб кэш НЕ пухнул при использовании логирования ?

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


From 440hz на mail.ru  Thu Dec 24 06:01:39 2020
From: 440hz на mail.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCT0L7Qu9GD0LHQtdCy?=)
Date: Thu, 24 Dec 2020 09:01:39 +0300
Subject: =?UTF-8?B?UmVbMl06INCf0YPRhdC90LXRgiDQsdGD0YTQtdGAINC60Y3RiNCwINC/0YDQuCA=?=
 =?UTF-8?B?0L3QsNCz0YDRg9C30LrQtQ==?=
In-Reply-To: <06e504f55938245cfb4db2faa8a08bcd.NginxMailingListRussian@forum.nginx.org>
References: <X+NVYtZQ8b1D1bf0@sie.protva.ru>
 <06e504f55938245cfb4db2faa8a08bcd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1608789699.237306068@f710.i.mail.ru>


вам не приходило в голову, что он должен «пухнуть» и что использование памяти оно разное для разных типов использования?
 
=)
  
>Четверг, 24 декабря 2020, 8:58 +03:00 от mouserok <nginx-forum на forum.nginx.org>:
> 
>ответ в числах приведен выше в первоначальном сообщении
>кэш НЕ пухнет если вырубить логирование
>как сделать чтоб кэш НЕ пухнул при использовании логирования ?
>
>Posted at Nginx Forum:  https://forum.nginx.org/read.php?21,290279,290303#msg-290303
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru 
 
 
С уважением,
Андрей Голубев
440hz на mail.ru
 
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201224/9ca1317c/attachment.htm>

From bgx на protva.ru  Thu Dec 24 07:44:43 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 24 Dec 2020 10:44:43 +0300
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20201224074442.GA2665@protva.ru>

On Wed, Dec 23, 2020 at 05:33:36PM -0500, pavlusha23 wrote:
> (Почините этот форум, невозможно зарегистрироваться если почта расположена
> на серверах с современными строгими антиспам настройками.)
> 
> Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться, но не
> могут. Я проверил сам, действительно невозможно. Они мне скинули логи своей
> почты тоже. У всех ситуация примерно одинакова:
> 
> sender verify fail for <www на teresa.liquidhost.co>: all relevant MX records
> point to non-existent hosts or (invalidly) to IP addresses.
> F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>: Sender verify
> failed
> 
> Т.е. этот форум для служебной рассылки использует какой-то левый
> несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS неверно
> настроен, и естественно такие письма сразу отсекаются почтовыми серверами
> (по крайней мере всеми на базе ispmanager последних версий) на этапе
> приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> внимание, вроде айтишники жеж.

 Всё с точностью до наоборот. Ваши коллеги пишут с несуществующих адресов
 (точнее, с неверифицируемых). А приёмный рилей рассылки nginx-ru, видимо,
 такие адреса отсекает. И это абсолютно правильно: зачем подписываться
 на рассылку тому, кто почту (включая эту рассылку) получать не может?

 Предложите коллегам настроить у себя почтовую систему нормально или
 сменить почтового провайдера.
-- 
 Eugene Berdnikov

From nginx-forum на forum.nginx.org  Thu Dec 24 09:12:40 2020
From: nginx-forum на forum.nginx.org (plavsk)
Date: Thu, 24 Dec 2020 04:12:40 -0500
Subject: =?UTF-8?B?Tmdpbngg0LIg0YDQtdC20LjQvNC1INC+0LHRgNCw0YLQvdC+0LPQviDQv9GA0L4=?=
 =?UTF-8?B?0LrRgdC4INC90LAg0YXQvtGB0YLQuNC90LMo0L3QsCDRgdC10YDQstC10YAg?=
 =?UTF-8?B?0YEg0LLQuNGA0YLRg9Cw0LvRjNC90YvQvNC4INGF0L7RgdGC0LDQvNC4KT8=?=
Message-ID: <b76972bdeedf73f34080af64e6cf78a9.NginxMailingListRussian@forum.nginx.org>

Помогите настроить nginx в режиме обратного прокси на сервер с виртуальными
хостами
Суть такая часть сайта висит на внешнем хостинге webflow.io увидеть свою
страницу нужно настроить cname на днс на proxy-ssl.webflow.com и тогда на
моем субдомене крутиться моя страничка www.subdomen.domen.ru
Но нам нужно что бы данная страничка была частью нашего монолита ввиде
domen.ru/subdomen
Что бы правильно передать доменое имя есть параметр proxy_set_header Host
который заменяет хост и в ответе и врезультате браузер переходит на домен
www.subdomen.domen.ru а не остается domen.ru/subdomen

Моя настройка
location /subdomen {
proxy_pass https://www.subdomen.domen.ru;
proxy_set_header Host www.subdomen.domen.ru;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503
http_504;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass_header Referer;
}

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


From alex.hha на gmail.com  Thu Dec 24 09:25:11 2020
From: alex.hha на gmail.com (Alex Domoradov)
Date: Thu, 24 Dec 2020 11:25:11 +0200
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <20201224074442.GA2665@protva.ru>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
 <20201224074442.GA2665@protva.ru>
Message-ID: <CAK90gp4VPQ+VLfU=y2W9kW-i-yWyC456QOzcVP-AYETm=3TFkQ@mail.gmail.com>

> если почта расположена на серверах с современными строгими антиспам
настройками.

видать современные строгие админы не научились настраивать почту

$ host -t mx teresa.liquidhost.co
teresa.liquidhost.co mail is handled by 10 69.46.5.194.

Вообще mx должна указывать на A запись

$ telnet 69.46.5.194 25
Trying 69.46.5.194...
telnet: connect to address 69.46.5.194: Operation timed out
telnet: Unable to connect to remote host

тут вообще без комментариев

On Thu, Dec 24, 2020 at 9:44 AM Evgeniy Berdnikov <bgx на protva.ru> wrote:

> On Wed, Dec 23, 2020 at 05:33:36PM -0500, pavlusha23 wrote:
> > (Почините этот форум, невозможно зарегистрироваться если почта
> расположена
> > на серверах с современными строгими антиспам настройками.)
> >
> > Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться,
> но не
> > могут. Я проверил сам, действительно невозможно. Они мне скинули логи
> своей
> > почты тоже. У всех ситуация примерно одинакова:
> >
> > sender verify fail for <www на teresa.liquidhost.co>: all relevant MX
> records
> > point to non-existent hosts or (invalidly) to IP addresses.
> > F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>: Sender
> verify
> > failed
> >
> > Т.е. этот форум для служебной рассылки использует какой-то левый
> > несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS
> неверно
> > настроен, и естественно такие письма сразу отсекаются почтовыми серверами
> > (по крайней мере всеми на базе ispmanager последних версий) на этапе
> > приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> > внимание, вроде айтишники жеж.
>
>  Всё с точностью до наоборот. Ваши коллеги пишут с несуществующих адресов
>  (точнее, с неверифицируемых). А приёмный рилей рассылки nginx-ru, видимо,
>  такие адреса отсекает. И это абсолютно правильно: зачем подписываться
>  на рассылку тому, кто почту (включая эту рассылку) получать не может?
>
>  Предложите коллегам настроить у себя почтовую систему нормально или
>  сменить почтового провайдера.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201224/30e434fb/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Thu Dec 24 11:47:18 2020
From: nginx-forum на forum.nginx.org (mouserok)
Date: Thu, 24 Dec 2020 06:47:18 -0500
Subject: =?UTF-8?B?UmU6IFJlWzJdOiDQn9GD0YXQvdC10YIg0LHRg9GE0LXRgCDQutGN0YjQsCDQv9GA?=
 =?UTF-8?B?0Lgg0L3QsNCz0YDRg9C30LrQtQ==?=
In-Reply-To: <1608789699.237306068@f710.i.mail.ru>
References: <1608789699.237306068@f710.i.mail.ru>
Message-ID: <fc69a638193f2340c4dd5f5ad8026b6c.NginxMailingListRussian@forum.nginx.org>

приходило )))
видимо вопрос закрыт
сделал удаление лога и reload nginx  - освободил кэш без очистки страничного
кеша путем запуска " sync; echo 3 > /proc/sys/vm/drop_caches"

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


From nginx-forum на forum.nginx.org  Thu Dec 24 19:42:01 2020
From: nginx-forum на forum.nginx.org (pavlusha23)
Date: Thu, 24 Dec 2020 14:42:01 -0500
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <20201224074442.GA2665@protva.ru>
References: <20201224074442.GA2665@protva.ru>
Message-ID: <e656ec1e7833d2080e32f78c656e86dd.NginxMailingListRussian@forum.nginx.org>

Evgeniy Berdnikov, это шутка такая или что? Мои коллеги никуда не пишут. Они
просто вводят свой email. Это этот форум присылает проверочное письмо с
адреса www на teresa.liquidhost.co. Поскольку проверочное письмо присылается с
хрен пойми какого адреса, то оно отсекается, соответственно зарегиться здесь
на форуме невозможно. Или это вы сказали про криворукость местных админов,
если так то да, согласен, им пора научиться настраивать почту.

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


From nginx-forum на forum.nginx.org  Thu Dec 24 19:45:11 2020
From: nginx-forum на forum.nginx.org (pavlusha23)
Date: Thu, 24 Dec 2020 14:45:11 -0500
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <CAK90gp4VPQ+VLfU=y2W9kW-i-yWyC456QOzcVP-AYETm=3TFkQ@mail.gmail.com>
References: <CAK90gp4VPQ+VLfU=y2W9kW-i-yWyC456QOzcVP-AYETm=3TFkQ@mail.gmail.com>
Message-ID: <32b6ee84bb65f50033171ac018f5a0c9.NginxMailingListRussian@forum.nginx.org>

ALex_hha, и вы тоже не читаете что вам пишут, прям удивительная слепота.
Письмо с корявых адресов рассылает ЭТОТ форум, при регистрации или
восстановлении пароля.

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


From bgx на protva.ru  Thu Dec 24 22:04:42 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 25 Dec 2020 01:04:42 +0300
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <e656ec1e7833d2080e32f78c656e86dd.NginxMailingListRussian@forum.nginx.org>
References: <20201224074442.GA2665@protva.ru>
 <e656ec1e7833d2080e32f78c656e86dd.NginxMailingListRussian@forum.nginx.org>
Message-ID: <X+UQegSDXHNQQNU5@sie.protva.ru>

On Thu, Dec 24, 2020 at 02:42:01PM -0500, pavlusha23 wrote:
> Evgeniy Berdnikov, это шутка такая или что?

 Нет, не шутка.

> Мои коллеги никуда не пишут. Они
> просто вводят свой email. Это этот форум присылает проверочное письмо с
> адреса www на teresa.liquidhost.co. Поскольку проверочное письмо присылается с
> хрен пойми какого адреса, то оно отсекается, соответственно зарегиться здесь
> на форуме невозможно.

 Вы, скорее всего, пересказываете слова коллег и слепо верите в то, что
 их интерпретация лога верна. А вот проверить их утверждения не можете.

 К слову, если те коллеги такие крутые постмастеры, что у них антиспам
 круче гугла, яндекса и mail.ru, то им ничего не стоит внести на минуту
 www на teresa.liquidhost.co в белый список и подключиться к рассылке. :)
-- 
 Eugene Berdnikov

From ngnx8810773a83 на avksrv.org  Thu Dec 24 22:27:15 2020
From: ngnx8810773a83 на avksrv.org (Alexey)
Date: Fri, 25 Dec 2020 01:27:15 +0300
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
Message-ID: <8c911a02-855d-a45f-c03c-3d6020443c26@avksrv.org>

24.12.2020 1:33, pavlusha23 пишет:
> (Почините этот форум, невозможно зарегистрироваться если почта расположена
> на серверах с современными строгими антиспам настройками.)
>
> Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться, но не
> могут. Я проверил сам, действительно невозможно. Они мне скинули логи своей
> почты тоже. У всех ситуация примерно одинакова:
>
> sender verify fail for <www на teresa.liquidhost.co>: all relevant MX records
> point to non-existent hosts or (invalidly) to IP addresses.
> F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>: Sender verify
> failed
>
> Т.е. этот форум для служебной рассылки использует какой-то левый
> несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS неверно
> настроен, и естественно такие письма сразу отсекаются почтовыми серверами
> (по крайней мере всеми на базе ispmanager последних версий) на этапе
> приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> внимание, вроде айтишники жеж.
>
> У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем спасибо
> и с наступающим рождеством!



тут кажется уже неоднократно отвечали сотрудники нгинкса, что форум 
сделан сторонними людьми как прокладка между почтофой рассылкой и вебом. 
и кажется его (форума) владельцам он надоел, там то сертификат скисает 
на несколько недель, то вот подтверждения шлет непойми с каких адресов..


почему нгинс не уберет из ДНСа forum. при таком подходе, не понятно. Но 
совет был, не пользоваться, а ходить туда и пользоваться почтовой 
рассылкой.


ниже не единственный ответ по проблеме с форумом


27.02.2020 15:09, Maxim Dounin пишет:
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
убрать, но наверное это не совсем то, что хотят люди, использующие
форум хоть как-то.

From nikolaygrebnev на gmail.com  Thu Dec 24 22:34:53 2020
From: nikolaygrebnev на gmail.com (Nikolay Grebnev)
Date: Fri, 25 Dec 2020 01:34:53 +0300
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <8c911a02-855d-a45f-c03c-3d6020443c26@avksrv.org>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
 <8c911a02-855d-a45f-c03c-3d6020443c26@avksrv.org>
Message-ID: <CAB7NVcQgNSwM_FxR3i4nrryTPvXwVcK6Ukf_XBTtdojrt3Cbfg@mail.gmail.com>

Не выдержал, поискал форум и зарегистрировался.
Мне на гмейл письмо дошло без каких-либо проблем.
Если не придираться к странному www на teresa.liquidhost.co то все работает.

Delivered-To: niko.lay.grebnev на gmail.com
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@teresa.liquidhost.co header.s=x header.b=V8nVUu6W;
       spf=pass (google.com: domain of www на teresa.liquidhost.co
designates 69.46.5.194 as permitted sender)
smtp.mailfrom=www на teresa.liquidhost.co
Return-Path: <www на teresa.liquidhost.co>
Received: from teresa.liquidhost.co (teresa.liquidhost.co. [69.46.5.194])
        by mx.google.com with ESMTPS id q82si25308046ybb.349.2020.12.24.14.31.25
        for <niko.lay.grebnev на gmail.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 24 Dec 2020 14:31:25 -0800 (PST)
Received-SPF: pass (google.com: domain of www на teresa.liquidhost.co
designates 69.46.5.194 as permitted sender) client-ip=69.46.5.194;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@teresa.liquidhost.co header.s=x header.b=V8nVUu6W;
       spf=pass (google.com: domain of www на teresa.liquidhost.co
designates 69.46.5.194 as permitted sender)
smtp.mailfrom=www на teresa.liquidhost.co
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=teresa.liquidhost.co; s=x; h=Date:Sender:From:Message-ID:
Content-Transfer-Encoding:Content-Type:Subject:To:Reply-To:Cc:MIME-Version:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=KeAYON1uPKfiT7gBMq7vXqaYrWBWGyAb2NJ8aa5aPzw=;
b=V8nVUu6Wn4UqMKG6xM179lDFj
UtcRpp+KjdvejCTI52iyXkMVWEWJHMhInKX13xY3AZCGoxvceSKwUn0SGKn2nWp4o4sM0zpnt/VLW
ZCRdk4aXbEFtL0/dDI1k3UyhMXlbd4ibxyv00VOXEGKnk21MCmU50L1ocy0IMjlEjlqM8=;
Received: from www by teresa.liquidhost.co with local (Exim 4.91
(FreeBSD)) (envelope-from <www на teresa.liquidhost.co>) id
1ksZ8n-000O5o-9U for niko.lay.grebnev на gmail.com; Thu, 24 Dec 2020
17:31:25 -0500
To: niko.lay.grebnev на gmail.com
Subject: Please verify your account
X-PHP-Originating-Script: 1001:email_functions.php
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailer: Phorum5
Message-ID: <202012241731.68503279075290 на forum.nginx.org>
X-Phorum: df1b22e43d937f289ea4a05cca76e7e8fbad5c3b
From: Nginx Forum <nginx-forum на forum.nginx.org>
Sender: World Wide Web Owner <www на teresa.liquidhost.co>
Date: Thu, 24 Dec 2020 17:31:25 -0500

On Fri, Dec 25, 2020 at 1:27 AM Alexey <ngnx8810773a83 на avksrv.org> wrote:
>
> 24.12.2020 1:33, pavlusha23 пишет:
> > (Почините этот форум, невозможно зарегистрироваться если почта расположена
> > на серверах с современными строгими антиспам настройками.)
> >
> > Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться, но не
> > могут. Я проверил сам, действительно невозможно. Они мне скинули логи своей
> > почты тоже. У всех ситуация примерно одинакова:
> >
> > sender verify fail for <www на teresa.liquidhost.co>: all relevant MX records
> > point to non-existent hosts or (invalidly) to IP addresses.
> > F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>: Sender verify
> > failed
> >
> > Т.е. этот форум для служебной рассылки использует какой-то левый
> > несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS неверно
> > настроен, и естественно такие письма сразу отсекаются почтовыми серверами
> > (по крайней мере всеми на базе ispmanager последних версий) на этапе
> > приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> > внимание, вроде айтишники жеж.
> >
> > У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем спасибо
> > и с наступающим рождеством!
>
>
>
> тут кажется уже неоднократно отвечали сотрудники нгинкса, что форум
> сделан сторонними людьми как прокладка между почтофой рассылкой и вебом.
> и кажется его (форума) владельцам он надоел, там то сертификат скисает
> на несколько недель, то вот подтверждения шлет непойми с каких адресов..
>
>
> почему нгинс не уберет из ДНСа forum. при таком подходе, не понятно. Но
> совет был, не пользоваться, а ходить туда и пользоваться почтовой
> рассылкой.
>
>
> ниже не единственный ответ по проблеме с форумом
>
>
> 27.02.2020 15:09, Maxim Dounin пишет:
> 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
> убрать, но наверное это не совсем то, что хотят люди, использующие
> форум хоть как-то.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

From ngnx8810773a83 на avksrv.org  Thu Dec 24 23:08:06 2020
From: ngnx8810773a83 на avksrv.org (Alexey)
Date: Fri, 25 Dec 2020 02:08:06 +0300
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <CAB7NVcQgNSwM_FxR3i4nrryTPvXwVcK6Ukf_XBTtdojrt3Cbfg@mail.gmail.com>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
 <8c911a02-855d-a45f-c03c-3d6020443c26@avksrv.org>
 <CAB7NVcQgNSwM_FxR3i4nrryTPvXwVcK6Ukf_XBTtdojrt3Cbfg@mail.gmail.com>
Message-ID: <7b1cfe2d-cb3b-fd4a-7e2c-78ec9946ae78@avksrv.org>

25.12.2020 1:34, Nikolay Grebnev пишет:
> Не выдержал, поискал форум и зарегистрировался.
> Мне на гмейл письмо дошло без каких-либо проблем.
> Если не придираться к странному www на teresa.liquidhost.co то все работает.
>
гугл не пытается проверить адрес путём соединения обратно. многие 
пытаются. ответ на такой адрес отправить невозможно. соотв "анонимки не 
берем". принимать или нет такую почту, вопрос возможно спорный, но что 
писать с неработающих в принципе доменов не надо, это точно. postmaster@ 
в любом домене, откуда ходит почта, должен быть рабочим. а тут на 25 
порту никого нет. Ктото (не будем тыкать пальцем во владельца форума) не 
удосужился настроить сервис.

да и как уже писали

teresa.liquidhost.co.   7200    IN      MX      10 69.46.5.194.
это не валидная запись. и много кто по этому признаку тоже не примет. МХ 
должен указывать на FQDN а не на IP. уж лучше бы не писал вообще MX,


From chipitsine на gmail.com  Fri Dec 25 05:15:44 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Fri, 25 Dec 2020 10:15:44 +0500
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <CAB7NVcQgNSwM_FxR3i4nrryTPvXwVcK6Ukf_XBTtdojrt3Cbfg@mail.gmail.com>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
 <8c911a02-855d-a45f-c03c-3d6020443c26@avksrv.org>
 <CAB7NVcQgNSwM_FxR3i4nrryTPvXwVcK6Ukf_XBTtdojrt3Cbfg@mail.gmail.com>
Message-ID: <CAFHpkQGLXPvAhmhD11U6BVdRJ-CANcO+xQtk7hqBBAQE+LBx9A@mail.gmail.com>

это не показатель.


крупные почтовики не делают smtp callback. они могут себе позволить мэшн
лёрнинг на письмах.

пт, 25 дек. 2020 г. в 03:35, Nikolay Grebnev <nikolaygrebnev на gmail.com>:

> Не выдержал, поискал форум и зарегистрировался.
> Мне на гмейл письмо дошло без каких-либо проблем.
> Если не придираться к странному www на teresa.liquidhost.co то все работает.
>
> Delivered-To: niko.lay.grebnev на gmail.com
> ARC-Authentication-Results: i=1; mx.google.com;
>        dkim=pass header.i=@teresa.liquidhost.co header.s=x
> header.b=V8nVUu6W;
>        spf=pass (google.com: domain of www на teresa.liquidhost.co
> designates 69.46.5.194 as permitted sender)
> smtp.mailfrom=www на teresa.liquidhost.co
> Return-Path: <www на teresa.liquidhost.co>
> Received: from teresa.liquidhost.co (teresa.liquidhost.co. [69.46.5.194])
>         by mx.google.com with ESMTPS id
> q82si25308046ybb.349.2020.12.24.14.31.25
>         for <niko.lay.grebnev на gmail.com>
>         (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
>         Thu, 24 Dec 2020 14:31:25 -0800 (PST)
> Received-SPF: pass (google.com: domain of www на teresa.liquidhost.co
> designates 69.46.5.194 as permitted sender) client-ip=69.46.5.194;
> Authentication-Results: mx.google.com;
>        dkim=pass header.i=@teresa.liquidhost.co header.s=x
> header.b=V8nVUu6W;
>        spf=pass (google.com: domain of www на teresa.liquidhost.co
> designates 69.46.5.194 as permitted sender)
> smtp.mailfrom=www на teresa.liquidhost.co
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=teresa.liquidhost.co; s=x; h=Date:Sender:From:Message-ID:
> Content-Transfer-Encoding:Content-Type:Subject:To:Reply-To:Cc:MIME-Version:
> Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
> Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
>
> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
> bh=KeAYON1uPKfiT7gBMq7vXqaYrWBWGyAb2NJ8aa5aPzw=;
> b=V8nVUu6Wn4UqMKG6xM179lDFj
>
> UtcRpp+KjdvejCTI52iyXkMVWEWJHMhInKX13xY3AZCGoxvceSKwUn0SGKn2nWp4o4sM0zpnt/VLW
> ZCRdk4aXbEFtL0/dDI1k3UyhMXlbd4ibxyv00VOXEGKnk21MCmU50L1ocy0IMjlEjlqM8=;
> Received: from www by teresa.liquidhost.co with local (Exim 4.91
> (FreeBSD)) (envelope-from <www на teresa.liquidhost.co>) id
> 1ksZ8n-000O5o-9U for niko.lay.grebnev на gmail.com; Thu, 24 Dec 2020
> 17:31:25 -0500
> To: niko.lay.grebnev на gmail.com
> Subject: Please verify your account
> X-PHP-Originating-Script: 1001:email_functions.php
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> X-Mailer: Phorum5
> Message-ID: <202012241731.68503279075290 на forum.nginx.org>
> X-Phorum: df1b22e43d937f289ea4a05cca76e7e8fbad5c3b
> From: Nginx Forum <nginx-forum на forum.nginx.org>
> Sender: World Wide Web Owner <www на teresa.liquidhost.co>
> Date: Thu, 24 Dec 2020 17:31:25 -0500
>
> On Fri, Dec 25, 2020 at 1:27 AM Alexey <ngnx8810773a83 на avksrv.org> wrote:
> >
> > 24.12.2020 1:33, pavlusha23 пишет:
> > > (Почините этот форум, невозможно зарегистрироваться если почта
> расположена
> > > на серверах с современными строгими антиспам настройками.)
> > >
> > > Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться,
> но не
> > > могут. Я проверил сам, действительно невозможно. Они мне скинули логи
> своей
> > > почты тоже. У всех ситуация примерно одинакова:
> > >
> > > sender verify fail for <www на teresa.liquidhost.co>: all relevant MX
> records
> > > point to non-existent hosts or (invalidly) to IP addresses.
> > > F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>: Sender
> verify
> > > failed
> > >
> > > Т.е. этот форум для служебной рассылки использует какой-то левый
> > > несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS
> неверно
> > > настроен, и естественно такие письма сразу отсекаются почтовыми
> серверами
> > > (по крайней мере всеми на базе ispmanager последних версий) на этапе
> > > приёмки, даже в спам не попадают. Прошу администрацию уделить этому
> > > внимание, вроде айтишники жеж.
> > >
> > > У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем
> спасибо
> > > и с наступающим рождеством!
> >
> >
> >
> > тут кажется уже неоднократно отвечали сотрудники нгинкса, что форум
> > сделан сторонними людьми как прокладка между почтофой рассылкой и вебом.
> > и кажется его (форума) владельцам он надоел, там то сертификат скисает
> > на несколько недель, то вот подтверждения шлет непойми с каких адресов..
> >
> >
> > почему нгинс не уберет из ДНСа forum. при таком подходе, не понятно. Но
> > совет был, не пользоваться, а ходить туда и пользоваться почтовой
> > рассылкой.
> >
> >
> > ниже не единственный ответ по проблеме с форумом
> >
> >
> > 27.02.2020 15:09, Maxim Dounin пишет:
> > 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
> > убрать, но наверное это не совсем то, что хотят люди, использующие
> > форум хоть как-то.
> > _______________________________________________
> > 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 было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201225/43690154/attachment-0001.htm>

From 440hz на mail.ru  Fri Dec 25 05:44:13 2020
From: 440hz на mail.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCT0L7Qu9GD0LHQtdCy?=)
Date: Fri, 25 Dec 2020 08:44:13 +0300
Subject: =?UTF-8?B?UmVbNF06INCf0YPRhdC90LXRgiDQsdGD0YTQtdGAINC60Y3RiNCwINC/0YDQuCA=?=
 =?UTF-8?B?0L3QsNCz0YDRg9C30LrQtQ==?=
In-Reply-To: <fc69a638193f2340c4dd5f5ad8026b6c.NginxMailingListRussian@forum.nginx.org>
References: <1608789699.237306068@f710.i.mail.ru>
 <fc69a638193f2340c4dd5f5ad8026b6c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <1608875053.899918577@f705.i.mail.ru>


я бы рекомендовал кеш/буфер не чистить. смысла нет 100%. когда надо система сама его вычистит. на занимаемую/выделяемую память оно не влияет. он по этому и кеш/буфер называется.
 
т.е. если ПО вдруг понадобится реальная память оно буфера сбросит и освободит.
 
[server.versia.ru:~] free -h
              total        used        free      shared  buff/cache   available
Mem:            46G        8.3G         12G        2.4G         25G         35G
Swap:            0B          0B          0B
 
вот buff/cache, когда надо, система сама сбросит.
 
 
а drop_caches сбрасывать это диски насиловать. не жалко?

  
>Четверг, 24 декабря 2020, 14:47 +03:00 от mouserok <nginx-forum на forum.nginx.org>:
> 
>приходило )))
>видимо вопрос закрыт
>сделал удаление лога и reload nginx - освободил кэш без очистки страничного
>кеша путем запуска " sync; echo 3 > /proc/sys/vm/drop_caches"
>
>Posted at Nginx Forum:  https://forum.nginx.org/read.php?21,290279,290307#msg-290307
>
>_______________________________________________
>nginx-ru mailing list
>nginx-ru на nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
 
С уважением,
Андрей Голубев
440hz на mail.ru
 
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201225/14684c70/attachment.htm>

From alex.hha на gmail.com  Fri Dec 25 08:59:14 2020
From: alex.hha на gmail.com (Alex Domoradov)
Date: Fri, 25 Dec 2020 10:59:14 +0200
Subject: =?UTF-8?B?UmU6INCf0L7Rh9C40L3QuNGC0LUg0Y3RgtC+0YIg0YTQvtGA0YPQvCwg0L3QtdCy?=
 =?UTF-8?B?0L7Qt9C80L7QttC90L4g0LfQsNGA0LXQs9C40YHRgtGA0LjRgNC+0LLQsNGC?=
 =?UTF-8?B?0YzRgdGPLi4u?=
In-Reply-To: <CAFHpkQGLXPvAhmhD11U6BVdRJ-CANcO+xQtk7hqBBAQE+LBx9A@mail.gmail.com>
References: <93d93a9a0a79454f0babcc9fce5f2352.NginxMailingListRussian@forum.nginx.org>
 <8c911a02-855d-a45f-c03c-3d6020443c26@avksrv.org>
 <CAB7NVcQgNSwM_FxR3i4nrryTPvXwVcK6Ukf_XBTtdojrt3Cbfg@mail.gmail.com>
 <CAFHpkQGLXPvAhmhD11U6BVdRJ-CANcO+xQtk7hqBBAQE+LBx9A@mail.gmail.com>
Message-ID: <CAK90gp6+8v1Va=G21OC9RTSqTERD54cEgR6utjY0wvANH2XHoA@mail.gmail.com>

> это не валидная запись.

Валидная, просто не совсем "правильная"


>  и много кто по этому признаку тоже не примет

Так это их проблемы, не принимать по одному признаку - ССЗБ

пт, 25 дек. 2020 г., 07:16 Илья Шипицин <chipitsine на gmail.com>:

> это не показатель.
>
>
> крупные почтовики не делают smtp callback. они могут себе позволить мэшн
> лёрнинг на письмах.
>
> пт, 25 дек. 2020 г. в 03:35, Nikolay Grebnev <nikolaygrebnev на gmail.com>:
>
>> Не выдержал, поискал форум и зарегистрировался.
>> Мне на гмейл письмо дошло без каких-либо проблем.
>> Если не придираться к странному www на teresa.liquidhost.co то все работает.
>>
>> Delivered-To: niko.lay.grebnev на gmail.com
>> ARC-Authentication-Results: i=1; mx.google.com;
>>        dkim=pass header.i=@teresa.liquidhost.co header.s=x
>> header.b=V8nVUu6W;
>>        spf=pass (google.com: domain of www на teresa.liquidhost.co
>> designates 69.46.5.194 as permitted sender)
>> smtp.mailfrom=www на teresa.liquidhost.co
>> Return-Path: <www на teresa.liquidhost.co>
>> Received: from teresa.liquidhost.co (teresa.liquidhost.co. [69.46.5.194])
>>         by mx.google.com with ESMTPS id
>> q82si25308046ybb.349.2020.12.24.14.31.25
>>         for <niko.lay.grebnev на gmail.com>
>>         (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
>>         Thu, 24 Dec 2020 14:31:25 -0800 (PST)
>> Received-SPF: pass (google.com: domain of www на teresa.liquidhost.co
>> designates 69.46.5.194 as permitted sender) client-ip=69.46.5.194;
>> Authentication-Results: mx.google.com;
>>        dkim=pass header.i=@teresa.liquidhost.co header.s=x
>> header.b=V8nVUu6W;
>>        spf=pass (google.com: domain of www на teresa.liquidhost.co
>> designates 69.46.5.194 as permitted sender)
>> smtp.mailfrom=www на teresa.liquidhost.co
>> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
>> d=teresa.liquidhost.co; s=x; h=Date:Sender:From:Message-ID:
>>
>> Content-Transfer-Encoding:Content-Type:Subject:To:Reply-To:Cc:MIME-Version:
>> Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
>> Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
>>
>> List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
>> bh=KeAYON1uPKfiT7gBMq7vXqaYrWBWGyAb2NJ8aa5aPzw=;
>> b=V8nVUu6Wn4UqMKG6xM179lDFj
>>
>> UtcRpp+KjdvejCTI52iyXkMVWEWJHMhInKX13xY3AZCGoxvceSKwUn0SGKn2nWp4o4sM0zpnt/VLW
>> ZCRdk4aXbEFtL0/dDI1k3UyhMXlbd4ibxyv00VOXEGKnk21MCmU50L1ocy0IMjlEjlqM8=;
>> Received: from www by teresa.liquidhost.co with local (Exim 4.91
>> (FreeBSD)) (envelope-from <www на teresa.liquidhost.co>) id
>> 1ksZ8n-000O5o-9U for niko.lay.grebnev на gmail.com; Thu, 24 Dec 2020
>> 17:31:25 -0500
>> To: niko.lay.grebnev на gmail.com
>> Subject: Please verify your account
>> X-PHP-Originating-Script: 1001:email_functions.php
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>> X-Mailer: Phorum5
>> Message-ID: <202012241731.68503279075290 на forum.nginx.org>
>> X-Phorum: df1b22e43d937f289ea4a05cca76e7e8fbad5c3b
>> From: Nginx Forum <nginx-forum на forum.nginx.org>
>> Sender: World Wide Web Owner <www на teresa.liquidhost.co>
>> Date: Thu, 24 Dec 2020 17:31:25 -0500
>>
>> On Fri, Dec 25, 2020 at 1:27 AM Alexey <ngnx8810773a83 на avksrv.org> wrote:
>> >
>> > 24.12.2020 1:33, pavlusha23 пишет:
>> > > (Почините этот форум, невозможно зарегистрироваться если почта
>> расположена
>> > > на серверах с современными строгими антиспам настройками.)
>> > >
>> > > Добрый день, несколько моих коллег хотел ли бы тут
>> зарегистрироваться, но не
>> > > могут. Я проверил сам, действительно невозможно. Они мне скинули логи
>> своей
>> > > почты тоже. У всех ситуация примерно одинакова:
>> > >
>> > > sender verify fail for <www на teresa.liquidhost.co>: all relevant MX
>> records
>> > > point to non-existent hosts or (invalidly) to IP addresses.
>> > > F=<www на teresa.liquidhost.co> rejected RCPT <xxxxxx на xxxxx.xxx>:
>> Sender verify
>> > > failed
>> > >
>> > > Т.е. этот форум для служебной рассылки использует какой-то левый
>> > > несуществующий адрес отправителя www на teresa.liquidhost.co то ли DNS
>> неверно
>> > > настроен, и естественно такие письма сразу отсекаются почтовыми
>> серверами
>> > > (по крайней мере всеми на базе ispmanager последних версий) на этапе
>> > > приёмки, даже в спам не попадают. Прошу администрацию уделить этому
>> > > внимание, вроде айтишники жеж.
>> > >
>> > > У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем
>> спасибо
>> > > и с наступающим рождеством!
>> >
>> >
>> >
>> > тут кажется уже неоднократно отвечали сотрудники нгинкса, что форум
>> > сделан сторонними людьми как прокладка между почтофой рассылкой и вебом.
>> > и кажется его (форума) владельцам он надоел, там то сертификат скисает
>> > на несколько недель, то вот подтверждения шлет непойми с каких адресов..
>> >
>> >
>> > почему нгинс не уберет из ДНСа forum. при таком подходе, не понятно. Но
>> > совет был, не пользоваться, а ходить туда и пользоваться почтовой
>> > рассылкой.
>> >
>> >
>> > ниже не единственный ответ по проблеме с форумом
>> >
>> >
>> > 27.02.2020 15:09, Maxim Dounin пишет:
>> > 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
>> > убрать, но наверное это не совсем то, что хотят люди, использующие
>> > форум хоть как-то.
>> > _______________________________________________
>> > nginx-ru mailing list
>> > nginx-ru на nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201225/f9f8416b/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Wed Dec 30 06:59:23 2020
From: nginx-forum на forum.nginx.org (trekst777)
Date: Wed, 30 Dec 2020 01:59:23 -0500
Subject: =?UTF-8?B?Tmdpbng6INGA0LXQtNC40YDQtdC60YIg0YEgd3d3INC90LAg0LTQvtC80LXQvSA=?=
 =?UTF-8?B?0LHQtdC3IHd3dyDQv9C+IGh0dHBz?=
Message-ID: <6a6fc4a89a24568b9e4689a4b8b2ce4e.NginxMailingListRussian@forum.nginx.org>

Здравствуйте.

На vps решил избавиться от apache, перешел на Nginx + php-fpm. Все настроил,
но возникли проблемы с редиректами.
Через hestiacp, установлено Debian 10: Nginx + php-fpm, есть https, только 1
домен joomla на ip. 

В папке /home/USER/conf/web/DOMAIN/создал файл nginx.conf_redir, Где
работает команда rewrite ^(.*) https://%домен%$1 permanent;

1.Не могу сделать перенаправление с www на домен без www по https (в
nginx.conf_redir). На форуме hestiacp тему закрыли без ответов, предложенное
ранее на данной конфигурации не работает.

2.  Сейчас на ip адресе сервера стоит заглушка. На apache всегда делал
перенаправление на Nginx при желании не получатся направить ip адрес на
домен. Нужно ли вообще делать редирект с ip на домен, и как реализовать на
nginx?

3! Было бы здорово использовать Nginx для исключения нескольких страниц из
протокола https, оставив 2-3 на протоколе http, как это реализовать на nginx
?

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


From chipitsine на gmail.com  Wed Dec 30 16:30:04 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 30 Dec 2020 21:30:04 +0500
Subject: =?UTF-8?B?0L/QsNC60LXRgtGLINC00LvRjyBBUk02NA==?=
Message-ID: <CAFHpkQH6=ywROg=NezB11Ld37HBYwC1pyLidko8qUUsyEygapQ@mail.gmail.com>

привет!


http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml:
[Errno 14] HTTP Error 404 - Not Found
Trying other mirror.

(ну и файлов реально нет)

не было спроса на arm64 ?


Илья
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201230/2a1838f1/attachment.htm>

From thresh на nginx.com  Thu Dec 31 09:34:13 2020
From: thresh на nginx.com (Konstantin Pavlov)
Date: Thu, 31 Dec 2020 12:34:13 +0300
Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDQtNC70Y8gQVJNNjQ=?=
In-Reply-To: <CAFHpkQH6=ywROg=NezB11Ld37HBYwC1pyLidko8qUUsyEygapQ@mail.gmail.com>
References: <CAFHpkQH6=ywROg=NezB11Ld37HBYwC1pyLidko8qUUsyEygapQ@mail.gmail.com>
Message-ID: <5aeb9ab5-e5a1-343b-2f9b-b6968516ff25@nginx.com>

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

30.12.2020 19:30, Илья Шипицин wrote:
> привет!
> 
> 
> http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml
> <http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml>:
> [Errno 14] HTTP Error 404 - Not Found
> Trying other mirror.
> 
> (ну и файлов реально нет)
> 
> не было спроса на arm64 ?

Да, не было запросов конкретно на CentOS 7 aarch64 и мы их вообще не
собирали.

К тому же, в CentOS 7 это не официально поддерживаемая архитектура - их
собирает AltArch SIG.
Для RHEL 7 похоже в AWS EC2 Red Hat тоже arm64 AMI не выкладывают (в
отличие от RHEL 8) -- так что перспективы добавления этой ОС/архитектуры
в наши сборки довольно туманны.

-- 
Konstantin Pavlov
https://www.nginx.com/

From chipitsine на gmail.com  Thu Dec 31 09:53:06 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 31 Dec 2020 14:53:06 +0500
Subject: =?UTF-8?B?UmU6INC/0LDQutC10YLRiyDQtNC70Y8gQVJNNjQ=?=
In-Reply-To: <5aeb9ab5-e5a1-343b-2f9b-b6968516ff25@nginx.com>
References: <CAFHpkQH6=ywROg=NezB11Ld37HBYwC1pyLidko8qUUsyEygapQ@mail.gmail.com>
 <5aeb9ab5-e5a1-343b-2f9b-b6968516ff25@nginx.com>
Message-ID: <CAFHpkQFeDXg0NqAJsZSJOs3fiSoa50kD1dXCPwUkYqpiebE4nQ@mail.gmail.com>

Ага, я нашёл src.rpm, хотел посмотреть на опции компиляции. Вроде ничего
особенного. Intrinsic-и поддерживаются?

On Thu, Dec 31, 2020, 2:34 PM Konstantin Pavlov <thresh на nginx.com> wrote:

> Здравствуйте,
>
> 30.12.2020 19:30, Илья Шипицин wrote:
> > привет!
> >
> >
> > http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml
> > <http://nginx.org/packages/mainline/centos/7/aarch64/repodata/repomd.xml
> >:
> > [Errno 14] HTTP Error 404 - Not Found
> > Trying other mirror.
> >
> > (ну и файлов реально нет)
> >
> > не было спроса на arm64 ?
>
> Да, не было запросов конкретно на CentOS 7 aarch64 и мы их вообще не
> собирали.
>
> К тому же, в CentOS 7 это не официально поддерживаемая архитектура - их
> собирает AltArch SIG.
> Для RHEL 7 похоже в AWS EC2 Red Hat тоже arm64 AMI не выкладывают (в
> отличие от RHEL 8) -- так что перспективы добавления этой ОС/архитектуры
> в наши сборки довольно туманны.
>
> --
> Konstantin Pavlov
> https://www.nginx.com/
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20201231/7df2451c/attachment.htm>