Quantcast
Channel: Nginx Forum
Viewing all 53287 articles
Browse latest View live
↧

[nginx] Version bump.

November 23, 2017, 5:36 am
$
0
0
details: http://hg.nginx.org/nginx/rev/0a5e3d893a0c
branches:
changeset: 7160:0a5e3d893a0c
user: Maxim Dounin <mdounin@mdounin.ru>
date: Thu Nov 23 16:32:58 2017 +0300
description:
Version bump.

diffstat:

src/core/nginx.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diffs (14 lines):

diff --git a/src/core/nginx.h b/src/core/nginx.h
--- a/src/core/nginx.h
+++ b/src/core/nginx.h
@@ -9,8 +9,8 @@
#define _NGINX_H_INCLUDED_


-#define nginx_version 1013007
-#define NGINX_VERSION "1.13.7"
+#define nginx_version 1013008
+#define NGINX_VERSION "1.13.8"
#define NGINX_VER "nginx/" NGINX_VERSION

#ifdef NGX_BUILD
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
↧
Search

[nginx] Configure: fixed clang detection on MINIX.

November 23, 2017, 5:36 am
$
0
0
details: http://hg.nginx.org/nginx/rev/325b3042edd6
branches:
changeset: 7161:325b3042edd6
user: Maxim Dounin <mdounin@mdounin.ru>
date: Thu Nov 23 16:33:40 2017 +0300
description:
Configure: fixed clang detection on MINIX.

As per POSIX, basic regular expressions have no alternations, and the
interpretation of the "\|" construct is undefined. At least on MINIX
and Solaris grep interprets "\|" as literal "|", and not as an alternation
as GNU grep does. Removed such constructs introduced in f1daa0356a1d.
This fixes clang detection on MINIX.

diffstat:

auto/cc/clang | 2 +-
auto/cc/name | 6 +++++-
2 files changed, 6 insertions(+), 2 deletions(-)

diffs (28 lines):

diff --git a/auto/cc/clang b/auto/cc/clang
--- a/auto/cc/clang
+++ b/auto/cc/clang
@@ -5,7 +5,7 @@
# clang


-NGX_CLANG_VER=`$CC -v 2>&1 | grep '\(clang\|LLVM\) version' 2>&1 \
+NGX_CLANG_VER=`$CC -v 2>&1 | grep 'version' 2>&1 \
| sed -e 's/^.* version \(.*\)/\1/'`

echo " + clang version: $NGX_CLANG_VER"
diff --git a/auto/cc/name b/auto/cc/name
--- a/auto/cc/name
+++ b/auto/cc/name
@@ -44,7 +44,11 @@ elif `$CC -v 2>&1 | grep 'gcc version' >
NGX_CC_NAME=gcc
echo " + using GNU C compiler"

-elif `$CC -v 2>&1 | grep '\(clang\|LLVM\) version' >/dev/null 2>&1`; then
+elif `$CC -v 2>&1 | grep 'clang version' >/dev/null 2>&1`; then
+ NGX_CC_NAME=clang
+ echo " + using Clang C compiler"
+
+elif `$CC -v 2>&1 | grep 'LLVM version' >/dev/null 2>&1`; then
NGX_CC_NAME=clang
echo " + using Clang C compiler"

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
↧
↧

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 5:52 am
$
0
0
On 22.11.2017 19:43, Maxim Dounin wrote:

>> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

>> Можно ли как-то исправить поведение nginx,
>> чтобы systemd не флудил в логи сообщениями об ошибках?

> С точки зрения абстрактного счастья для всех даром - наверное,
> поведение systemd логично, и на момент выхода запущенного процесса
> pid-файл должен уже существовать.
>
> С точки зрения практики - паттерн "daemon(); write_pidfile();"
> используется чуть менее, чем везде, вплоть до соответствующих
> библиотечных функций. Так что инициатива выглядит, скажем так,
> сомнительной.

Спросил об этом в списке рассылки systemd-devel:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039812.html

Идея переписать systemd там энтузиазма не вызвала:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039820.html

Более того, мне прислали ссылку на официальную документацию systemd:

Many other deficiencies with the BSD daemon() function
are documented in systemd's daemon(7) manpage.

В systemd's daemon(7) manpage очень подробно расписано
как должны вести себя SysV Daemons при работе с systemd.
И очевидно, что nginx этим требованиям не соответствует.

Original process должен вызывать exit() только после того,
как будет полностью завершена инициализация daemon process,
в частности, после того как daemon process создаст свой pid файл.

> Проще всего, IMHO, это было бы заткнуть на уровне systemd,
> дожидаясь появления pid-файла при необходимости.

Кстати, дожидаться pid-файла - это не совсем тривиальная задача,
ведь nginx пишет свой pid-файл не атомарно. Может же быть так,
что файл уже появился, но он будет нулевого размера и попытка
прочитать из него pid завершится ошибкой? Или он будет частично
записан и тогда из pid-файла прочитается pid другого процесса?

Можно ли будет исправить поведение nginx чтобы он соответствовал
требованиям к SysV Daemons из systemd's daemon(7) manpage?

Поведение systemd изменить не получится, я уже пробовал.

--
Best regards,
Gena

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

Nginx + SSL problem for old browsers

November 23, 2017, 7:00 am
$
0
0
Hello everybody,

I have one single website running a RapidSSL certificate, that doesn't work on old mobile phones and browsers, like Symbian. My customer, however, insist in having this site with SSL fully compatible with old browsers.

I am already using and old cipher for old browsers generated at https://mozilla.github.io/server-side-tls/ssl-config-generator/

However, still doesn't work.

Just in case, on the same server I serve lot of other SSL certificates, all sharing the same IP.

This is my current Nginx configuration for this site :

# SSL config
listen 443 ssl;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP';
ssl_prefer_server_ciphers On;
ssl_dhparam /etc/nginx/dhparams.pem;
ssl_certificate /etc/nginx/ssl.crt/www.mysite.com.crt;
ssl_certificate_key /etc/nginx/ssl.key/www.mysite.com.key;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
# SSL config

Thanks
↧

Migrating from Varnish

November 23, 2017, 7:02 am
$
0
0
Hi all,

I've been using Varnish for 4 years now, but quite frankly I'm tired of
using it for HTTP traffic and Nginx for SSL offloading when Nginx can just
handle it all. One of the main issues I'm running into with the transition
is related to cache purging, and setting custom expiry TTL's per
zone/domain. My questions are:

- Does anyone have any recent working documentation on supported
modules/Lua scripts which can achieve wildcard purges as well as specific
URL purges?

- How should I go about defining custom cache TTL's for: frontpage,
dynamic, and static content requests? Currently I have Varnish configured
to set the ttl's based on request headers which are added in the config
with regex matches against the host being accessed.

Any other caveats or suggestions I should possibly know of?

--Andrei
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
↧

Re: Nginx + SSL problem for old browsers

November 23, 2017, 7:18 am
$
0
0
Could this be because of the lack of SNI support on old browsers?

Thanks
↧

Server Block Nginx

November 23, 2017, 7:24 am
$
0
0
Hi Zusammen,

ich versuche im Moment einen bereits verfügbaren virtuellen Host, über eine neue URL erreichbar zu machen.

Das Szenario ist folgendes:
Der Host "test-example.com" läuft bereits als aktiver Server Block und soll nun künftig auch von presentation.com/linktest erreichbar sein.
www.presentation.com/linktest wird über unseren Load Balancer auf den Port 8080 weitergeleitet.

Meine config für die presentation URL sieht wie folgt aus:

Server {
listen 8080
server_name www.presentation.com

root /var/virtual/www.presentation.com/linktest/current

Location ~ ^/linktest/?$ {
Proxy_pass https://test-example.com
}


Unter current verweißt ein Softlink auf das aktuelle test-example.com Verzeichnis

Die Umleitung funktioniert auch soweit, nur werden nun meine CSS nicht geladen ... da die im Quellcode auf presentation.com/style/style.css zugreifen.

Meine Frage ist wie ich die CSS nun auch eingespielt bekomme.

Ich würde mich über eure Hilfe sehr freuen

Liebe Grüße

Light
↧

Re: Migrating from Varnish

November 23, 2017, 7:26 am
$
0
0
To follow up on the purge implementation, I would like to avoid going
through the entire cache dir for a wildcard request, as the sites I have
stack up over 200k objects. I'm wondering if there would be a clean way of
taking a passive route, through which cache would be
invalidated/"refreshed" by subsequent requests. As in I send a purge
request for https://domain.com/.*, and subsequent requests for cached items
would then fetch the request from the backend, and update the cache. If
that makes any sense..

On Nov 23, 2017 17:00, "Andrei" <lagged@gmail.com> wrote:

> Hi all,
>
> I've been using Varnish for 4 years now, but quite frankly I'm tired of
> using it for HTTP traffic and Nginx for SSL offloading when Nginx can just
> handle it all. One of the main issues I'm running into with the transition
> is related to cache purging, and setting custom expiry TTL's per
> zone/domain. My questions are:
>
> - Does anyone have any recent working documentation on supported
> modules/Lua scripts which can achieve wildcard purges as well as specific
> URL purges?
>
> - How should I go about defining custom cache TTL's for: frontpage,
> dynamic, and static content requests? Currently I have Varnish configured
> to set the ttl's based on request headers which are added in the config
> with regex matches against the host being accessed.
>
> Any other caveats or suggestions I should possibly know of?
>
> --Andrei
>
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
Search

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 7:40 am
$
0
0
Hello!

On Thu, Nov 23, 2017 at 03:49:43PM +0200, Gena Makhomed wrote:

> On 22.11.2017 19:43, Maxim Dounin wrote:
>
> >> systemd: PID file /var/run/nginx.pid not readable (yet?) after start.
>
> >> Можно ли как-то исправить поведение nginx,
> >> чтобы systemd не флудил в логи сообщениями об ошибках?
>
> > С точки зрения абстрактного счастья для всех даром - наверное,
> > поведение systemd логично, и на момент выхода запущенного процесса
> > pid-файл должен уже существовать.
> >
> > С точки зрения практики - паттерн "daemon(); write_pidfile();"
> > используется чуть менее, чем везде, вплоть до соответствующих
> > библиотечных функций. Так что инициатива выглядит, скажем так,
> > сомнительной.
>
> Спросил об этом в списке рассылки systemd-devel:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039812.html
>
> Идея переписать systemd там энтузиазма не вызвала:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039820.html
>
> Более того, мне прислали ссылку на официальную документацию systemd:
>
> Many other deficiencies with the BSD daemon() function
> are documented in systemd's daemon(7) manpage.
>
> В systemd's daemon(7) manpage очень подробно расписано
> как должны вести себя SysV Daemons при работе с systemd.
> И очевидно, что nginx этим требованиям не соответствует.
>
> Original process должен вызывать exit() только после того,
> как будет полностью завершена инициализация daemon process,
> в частности, после того как daemon process создаст свой pid файл.

Это, что называется, всё очень интересно, но вызывает сомнение
успех подобных рекомендаций. Особенно с учётом отсутствия
каких-либо внятных примеров того, что же использовать вместо
daemon(3). О чём я, собственно, и писал выше.

Впрочем, если верить ответу тут:

https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html

то соответствующее сообщение можно смело игнорировать, и systemd
на самом деле умеет дожидаться создания pid-файла. То есть вопрос
лишь в том, что при этом systemd пишет в лог.

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

Re: Migrating from Varnish

November 23, 2017, 7:58 am
$
0
0
Hello!

On Thu, Nov 23, 2017 at 09:00:52AM -0600, Andrei wrote:

> Hi all,
>
> I've been using Varnish for 4 years now, but quite frankly I'm tired of
> using it for HTTP traffic and Nginx for SSL offloading when Nginx can just
> handle it all. One of the main issues I'm running into with the transition
> is related to cache purging, and setting custom expiry TTL's per
> zone/domain. My questions are:
>
> - Does anyone have any recent working documentation on supported
> modules/Lua scripts which can achieve wildcard purges as well as specific
> URL purges?

Cache purging is available in nginx-plus, see
http://nginx.org/r/proxy_cache_purge.

> - How should I go about defining custom cache TTL's for: frontpage,
> dynamic, and static content requests? Currently I have Varnish configured
> to set the ttl's based on request headers which are added in the config
> with regex matches against the host being accessed.

Normal nginx approach is to configure distinct server{} and
location{} blocks for different content, with appropriate cache
validity times. For example:

server {
listen 80;
server_name foo.example.com;

location / {
proxy_pass http://backend;
proxy_cache one;
proxy_cache_valid 200 5m;
}

location /static/ {
proxy_pass http://backend;
proxy_cache one;
proxy_cache_valid 200 24h;
}
}

Note well that by default nginx respects what is returned by the
backend in various response headers, and proxy_cache_valid time
only applies if there are no explicit cache validity time set, see
http://nginx.org/r/proxy_ignore_headers.

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

Re: Migrating from Varnish

November 23, 2017, 8:26 am
$
0
0
Hello Maxim!

On Nov 23, 2017 17:55, "Maxim Dounin" <mdounin@mdounin.ru> wrote:

Hello!

On Thu, Nov 23, 2017 at 09:00:52AM -0600, Andrei wrote:

> Hi all,
>
> I've been using Varnish for 4 years now, but quite frankly I'm tired of
> using it for HTTP traffic and Nginx for SSL offloading when Nginx can just
> handle it all. One of the main issues I'm running into with the transition
> is related to cache purging, and setting custom expiry TTL's per
> zone/domain. My questions are:
>
> - Does anyone have any recent working documentation on supported
> modules/Lua scripts which can achieve wildcard purges as well as specific
> URL purges?

Cache purging is available in nginx-plus, see
http://nginx.org/r/proxy_cache_purge.

I'm aware of the paid version, but I don't have a budget for it yet, and
quite frankly this should be a core feature for any caching service. Are
there no viable options for the community release? It's a rather pertinent
feature to have in my transition


> - How should I go about defining custom cache TTL's for: frontpage,
> dynamic, and static content requests? Currently I have Varnish configured
> to set the ttl's based on request headers which are added in the config
> with regex matches against the host being accessed.

Normal nginx approach is to configure distinct server{} and
location{} blocks for different content, with appropriate cache
validity times. For example:

server {
listen 80;
server_name foo.example.com;

location / {
proxy_pass http://backend;
proxy_cache one;
proxy_cache_valid 200 5m;
}

location /static/ {
proxy_pass http://backend;
proxy_cache one;
proxy_cache_valid 200 24h;
}
}

Note well that by default nginx respects what is returned by the
backend in various response headers, and proxy_cache_valid time
only applies if there are no explicit cache validity time set, see
http://nginx.org/r/proxy_ignore_headers.

So to override the ttls set by the backend, I would have to use
proxy_ignore_headers for all headers which can directly affect the intended
TTL?

Thank you for your time!


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

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 8:30 am
$
0
0
On 23.11.2017 17:37, Maxim Dounin wrote:

>> В systemd's daemon(7) manpage очень подробно расписано
>> как должны вести себя SysV Daemons при работе с systemd.
>> И очевидно, что nginx этим требованиям не соответствует.

>> Original process должен вызывать exit() только после того,
>> как будет полностью завершена инициализация daemon process,
>> в частности, после того как daemon process создаст свой pid файл.

> Это, что называется, всё очень интересно, но вызывает сомнение
> успех подобных рекомендаций. Особенно с учётом отсутствия
> каких-либо внятных примеров того, что же использовать вместо
> daemon(3). О чём я, собственно, и писал выше.

Что использовать вместо daemon(3) документировано в daemon(7):
https://www.freedesktop.org/software/systemd/man/daemon.html

Lennart Poettering очень подробно ответил на этот вопрос в рассылке:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html

Впрочем, если очень хочется использовать все-таки daemon(3) то можно:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html

Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html

> Впрочем, если верить ответу тут:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html

> то соответствующее сообщение можно смело игнорировать, и systemd
> на самом деле умеет дожидаться создания pid-файла. То есть вопрос
> лишь в том, что при этом systemd пишет в лог.

Не надо верить тому, что говорит Michael Chapman - он ошибается.
systemd не ждет появления pid-файла, я это проверял по исходникам.

Лучше верить тому, что говорит Lennart Poettering, автор systemd:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html

Всегда надо указывать корректный PIDFile= для сервисов Type=forking:
https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html

Максим, можно ли сделать так, чтобы nginx соответствовал
тем требованиям которые предъявляет systemd к SysV Daemons?

https://www.freedesktop.org/software/systemd/man/daemon.html

--
Best regards,
Gena

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

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 8:46 am
$
0
0
> On 23 Nov 2017, at 19:28, Gena Makhomed <gmm@csdoc.com> wrote:
>
> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html

Интересно, откуда он это придумал про двойной fork()?

Во FreeBSD используется только один fork() что в 2017 году:
https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025&view=co
что в 1994:
https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573&view=co


--
Igor Sysoev
http://nginx.com

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

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 9:14 am
$
0
0
Hello!

On Thu, Nov 23, 2017 at 06:28:55PM +0200, Gena Makhomed wrote:

> On 23.11.2017 17:37, Maxim Dounin wrote:
>
> >> В systemd's daemon(7) manpage очень подробно расписано
> >> как должны вести себя SysV Daemons при работе с systemd.
> >> И очевидно, что nginx этим требованиям не соответствует.
>
> >> Original process должен вызывать exit() только после того,
> >> как будет полностью завершена инициализация daemon process,
> >> в частности, после того как daemon process создаст свой pid файл.
>
> > Это, что называется, всё очень интересно, но вызывает сомнение
> > успех подобных рекомендаций. Особенно с учётом отсутствия
> > каких-либо внятных примеров того, что же использовать вместо
> > daemon(3). О чём я, собственно, и писал выше.
>
> Что использовать вместо daemon(3) документировано в daemon(7):
> https://www.freedesktop.org/software/systemd/man/daemon.html
>
> Lennart Poettering очень подробно ответил на этот вопрос в рассылке:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039830.html
>
> Впрочем, если очень хочется использовать все-таки daemon(3) то можно:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039834.html
>
> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html

Это всё замечательно (за вычетом того, предлагаемое использование
daemon(3) почему-то не учитывает, что после вызова daemon(3)
parent-процесса уже нет, а "ошибка" - не ошибка), но не отменяет
того, что чуть менее, чем все существующие демоны делают именно
"daemon(); write_pidfile();", и при таком подходе - ситуацию не
изменить.

> > Впрочем, если верить ответу тут:
> > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039825.html
>
> > то соответствующее сообщение можно смело игнорировать, и systemd
> > на самом деле умеет дожидаться создания pid-файла. То есть вопрос
> > лишь в том, что при этом systemd пишет в лог.
>
> Не надо верить тому, что говорит Michael Chapman - он ошибается.
> systemd не ждет появления pid-файла, я это проверял по исходникам.
>
> Лучше верить тому, что говорит Lennart Poettering, автор systemd:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039833.html
>
> Всегда надо указывать корректный PIDFile= для сервисов Type=forking:
> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039831.html
>
> Максим, можно ли сделать так, чтобы nginx соответствовал
> тем требованиям которые предъявляет systemd к SysV Daemons?
>
> https://www.freedesktop.org/software/systemd/man/daemon.html

Можно, я ж разве против?

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

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 9:18 am
$
0
0
Hello!

On Thu, Nov 23, 2017 at 07:44:57PM +0300, Igor Sysoev wrote:

> > On 23 Nov 2017, at 19:28, Gena Makhomed <gmm@csdoc.com> wrote:
> >
> > Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
> > https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html
>
> Интересно, откуда он это придумал про двойной fork()?
>
> Во FreeBSD используется только один fork() что в 2017 году:
> https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=326025&view=co
> что в 1994:
> https://svnweb.freebsd.org/base/head/lib/libc/gen/daemon.c?revision=1573&view=co

Двойной форк нужен на Линуксе, чтобы случайно не получить себе
обратно controlling terminal. Документировано, например, тут в
man daemon(3) у glibc,
http://man7.org/linux/man-pages/man3/daemon.3.html:

The GNU C library implementation of this function was taken from BSD,
and does not employ the double-fork technique (i.e., fork(2),
setsid(2), fork(2)) that is necessary to ensure that the resulting
daemon process is not a session leader. Instead, the resulting
daemon is a session leader. On systems that follow System V
semantics (e.g., Linux), this means that if the daemon opens a
terminal that is not already a controlling terminal for another
session, then that terminal will inadvertently become the controlling
terminal for the daemon.

Смысла это делать в nginx'е - скорее нет, IMHO.

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

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 9:30 am
$
0
0
> С точки зрения практики - паттерн "daemon(); write_pidfile();"
> используется чуть менее, чем везде, вплоть до соответствующих
> библиотечных функций. Так что инициатива выглядит, скажем так,
> сомнительной.
>
> Проще всего, IMHO, это было бы заткнуть на уровне systemd,
> дожидаясь появления pid-файла при необходимости.

Возможно я чего-то не понимаю, но для Systemd лучше вообще не указывать pid файл, вместо Type=fork использовать Type=notify, это более гибкий вариант сообщить Systemd что процесс готов к работе.

Вот подробней, кстати PostgreSQL и PHP-FPM уже перешли на него.
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=
↧

Re: systemd: PID file /var/run/nginx.pid not readable (yet?) after start.

November 23, 2017, 9:34 am
$
0
0
On 23.11.2017 18:44, Igor Sysoev wrote:

>> Кстати, Lennart Poettering нашел еще одну ошибку в исходниках nginx:
>> https://lists.freedesktop.org/archives/systemd-devel/2017-November/039832.html

> Интересно, откуда он это придумал про двойной fork()?

Скорее всего из книжки Richard W. Stevens
Advanced Programming in the UNIX Environment, 3rd Edition
https://www.amazon.com/Advanced-Programming-UNIX-Environment-3rd/dp/0321637739

Подробный ответ на stackoverflow с объяснением зачем двойной форк:
https://stackoverflow.com/a/31485256

Кстати, сама эта книжка
Advanced Programming in the UNIX Environment, 3rd Edition
в PDF формате на английском доступна для скачивания в интернете:
http://www.codeman.net/wp-content/uploads/2014/04/APUE-3rd.pdf
https://github.com/shihyu/Linux_Programming/blob/master/books/Advanced.Programming.in.the.UNIX.Environment.3rd.Edition.0321637739.pdf

--
Best regards,
Gena

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

denie open a file directly, but allow open as link/iframe

November 23, 2017, 9:44 am
$
0
0
I would like to ask, if there is a way to denie opening of a HTML file and *.js if they are accessed directly, but to allow access to this files, when they are opened via a link or inside a iframe?
↧

Re: Migrating from Varnish

November 23, 2017, 9:53 am
$
0
0
Andrei Wrote:
-------------------------------------------------------
> I'm aware of the paid version, but I don't have a budget for it yet,
> and
> quite frankly this should be a core feature for any caching service.
> Are
> there no viable options for the community release? It's a rather

https://github.com/FRiCKLE/ngx_cache_purge/

Easy to implement (add).
↧

Re: Migrating from Varnish

November 23, 2017, 9:54 am
$
0
0
Hello!

On Thu, Nov 23, 2017 at 10:24:19AM -0600, Andrei wrote:

> > > - Does anyone have any recent working documentation on supported
> > > modules/Lua scripts which can achieve wildcard purges as well as specific
> > > URL purges?
> >
> > Cache purging is available in nginx-plus, see
> > http://nginx.org/r/proxy_cache_purge.
>
> I'm aware of the paid version, but I don't have a budget for it yet, and
> quite frankly this should be a core feature for any caching service. Are
> there no viable options for the community release? It's a rather pertinent
> feature to have in my transition

I'm aware of at least one 3rd party module from Piotr Sikora,
https://github.com/FRiCKLE/ngx_cache_purge. I've never tried to
use it, and AFAIK it doesn't support wildcard purges. It is
mostly known to developers as a hack that starts segfaulting on
unrelated changes in proxy module, so obviously enough I can't
recommend using it.

Note though that I personally think that cache purging is
something that should _not_ be present in any caching service, and
I wouldn't recommend using nginx-plus functionality either.
Proper controlling of cache validity times is something that
should be used instead. This is what happens in browsers anyway,
and trying to "purge" things there won't work.

> > Note well that by default nginx respects what is returned by the
> > backend in various response headers, and proxy_cache_valid time
> > only applies if there are no explicit cache validity time set, see
> > http://nginx.org/r/proxy_ignore_headers.
>
> So to override the ttls set by the backend, I would have to use
> proxy_ignore_headers for all headers which can directly affect the intended
> TTL?

Yes, if you want to ignore what the backend set. In many cases
this might not be a good idea though.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
↧
Viewing all 53287 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>