Bug 576414 – www-servers/nginx: Saner default configuration

• Product: Gentoo Linux
• Status: IN_PROGRESS ---

[Description Torbjörn Lönnemark 2016-03-04 07:46:30 UTC]

The current default configuration contains a number of directives that are not expected to commonly be changed by users, some of which diverge from the defaults for no evident reason. Removing these would be a good idea.

Quoting nginx.conf-r2, these are:
> log_format main
>        '$remote_addr - $remote_user [$time_local] '
>        '"$request" $status $bytes_sent '
>        '"$http_referer" "$http_user_agent" '
>        '"$gzip_ratio"';
The only difference between this and the builtin 'combined' format[1] is that it includes gzip_ratio, and gzip is disabled by default[2] anyway. Can be removed while additionally replacing 'main' in the access_log directives to 'combined'.

> client_header_timeout 10m;
> client_body_timeout 10m;
> send_timeout 10m;
Most users should have no need to change these, and there seems to be no reason to them from their respective default values (that are all 60s). [3][4][5]

> connection_pool_size 256;
Most users should have no need to change these, and there seems to be no reason to change it from the default value (256 on 32-bit platforms and 512 on 64-bit platforms since nginx 1.9.8) [6]

> output_buffers 1 32k;
This seems to have been a case of needlessly specifying the default, which used to be "1 32k" before nginx 1.9.5, but now is "2 32k". No need to keep it in the default config. [7]

> postpone_output 1460;
Matches the default. Most users will not need to change this. [8]

> keepalive_timeout 75 20;
Arguable whether it should be kept at all, but I see not reason to diverge from the default value (which is just "75"). [9]

> ignore_invalid_headers on;
Mirrors the default value, and most will want to keep it that way. No need to have it in the default config.


[1]: http://nginx.org/en/docs/http/ngx_http_log_module.html#log_format
[2]: Because of https://bugs.gentoo.org/show_bug.cgi?id=560854
[3]: http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout
[4]: http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout
[5]: http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout
[6]: http://nginx.org/en/docs/http/ngx_http_core_module.html#connection_pool_size
[7]: http://nginx.org/en/docs/http/ngx_http_core_module.html#output_buffers
[8]: http://nginx.org/en/docs/http/ngx_http_core_module.html#postpone_output
[9]: http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout
[10]: http://nginx.org/en/docs/http/ngx_http_core_module.html#ignore_invalid_headers

[Comment 1 Johan Bergström 2016-04-05 01:39:15 UTC]

I agree with this. I also think we should incorporate the `sites-{enabled,available}` concept since it seems to be widely accepted by now.

I suggest you post a new default config (I could even see starting off debian's) and we can perhaps do feedback-rounds based on that?

[Comment 2 Thomas Deutschmann (RETIRED) 2016-04-05 16:19:38 UTC]

I agree with Torbjörn in general.

However keep in mind that while gzip is disabled per default, most people using nginx probably have gzip enabled (common use case is web server). If we change a default we are installing for 10 years now [see v1.1 at 1] we will force most people to alter their configuration if they want to keep gzip ratio in their logs.

If we do that, where do we stop?

For example I am already using a setup like Johan is now thinking about:

/etc/nginx/
├── common
│   ├── no-dot-files.conf
│   ├── no-favicon.conf
│   ├── no-robots.txt.conf
├── fastcgi.conf
├── mime.types
├── nginx.conf
├── php
│   ├── example.org-backend-php.conf
│   ├── example.org-default-php.conf
│   └── localhost-default-php.conf
├── sites-available.d
│   ├── 00default
│   ├── example.org
│   └── localhost
└── sites-enabled.d
    ├── 00default -> ../sites-available.d/00default
    ├── example.org -> ../sites-available.d/example.org
    └── localhost -> ../sites-available.d/localhost


As you can see I already got rid of fastcgi_params [2].

But is this suitable for most users? I am undecided if we should follow upstream strictly or introduce a Gentoo way.

When it comes to Debian's configuration I am not sure if we should set tcp_nopush or tcp_nodelay. It can work for you, but this can also be causing problems. At the moment I would prefer to stick with upstream's default. People should alter their configuration on purpose when they know what they are doing.

Setting "worker_process" to "auto" is something we should do (matches Gentoo's default).


[1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-servers/nginx/files/nginx.conf?view=log

[2] https://blog.martinfjordvald.com/2013/04/nginx-config-history-fastcgi_params-versus-fastcgi-conf/

[Comment 3 William Hubbs 2016-05-04 21:56:04 UTC]

(In reply to Thomas Deutschmann from comment #2)
> I agree with Torbjörn in general.
> 
> However keep in mind that while gzip is disabled per default, most people
> using nginx probably have gzip enabled (common use case is web server). If
> we change a default we are installing for 10 years now [see v1.1 at 1] we
> will force most people to alter their configuration if they want to keep
> gzip ratio in their logs.
> 
> If we do that, where do we stop?
> 
> For example I am already using a setup like Johan is now thinking about:
> 
> /etc/nginx/
> ├── common
> │   ├── no-dot-files.conf
> │   ├── no-favicon.conf
> │   ├── no-robots.txt.conf
> ├── fastcgi.conf
> ├── mime.types
> ├── nginx.conf
> ├── php
> │   ├── example.org-backend-php.conf
> │   ├── example.org-default-php.conf
> │   └── localhost-default-php.conf
> ├── sites-available.d
> │   ├── 00default
> │   ├── example.org
> │   └── localhost
> └── sites-enabled.d
>     ├── 00default -> ../sites-available.d/00default
>     ├── example.org -> ../sites-available.d/example.org
>     └── localhost -> ../sites-available.d/localhost
> 
> 
> As you can see I already got rid of fastcgi_params [2].
> 
> But is this suitable for most users? I am undecided if we should follow
> upstream strictly or introduce a Gentoo way.

+ 1 for following upstream strictly.

At first look, if there is an upstream default configuration, I think we should just install that and allow users to adjust things as they need to.