Bug in the nginx-0.7.xx include .../conf.d/*.conf process?

Server NGINX
1

In Debian/Ubuntu systems (also in .rpm based systems?) /conf.d/*.conf
files are used to (automatically) supersede any configuration originally
put in the main .conf file (nginx.conf) by the program
developers/maintainers.

In the file /etc/nginx/nginx.conf (or
/usr/local/nginx/conf/nginx.conf, if installed from source) there is
supposed to that, loading alternative config files: include
/etc/nginx/conf.d/*.conf;

In nginx-0.7.43 creating a file at …/conf.d/my_own.conf with the
contents:
keepalive_timeout 10 10;
gzip on;
gzip_types text/plain text/css application/x-javascript text/xml
application/xml application/xml+rss text/javascript;
gzip_min_length 640;

Will lead, when trying to restart nginx, to a nginx halt with an
error message like:
" [emerg] 9242#0: “keepalive_timeout” directive is duplicate in
/etc/nginx/conf.d/server_specific_parameters.conf:1
"

In the absence of a better opinion, it seems that it would make more
sense if, instead, the new values superseed any already existant
parameters in nginx.conf and nginx give the user a warning message
listing the parameters being superseeded.
Ideally any 20-my_own.conf file would be read after and superseed any
values in a 10-my_own.conf file, wich in turn would be read after and
superseed any values in nginx.conf

Regarding any new parameters not present in any previous *.conf,
nginx would simply read and add them without any further warning.

M.

2

Hello!

On Sun, Mar 22, 2009 at 12:07:42PM +0000, Mark A. wrote:

In nginx-0.7.43 creating a file at …/conf.d/my_own.conf with the
/etc/nginx/conf.d/server_specific_parameters.conf:1
Regarding any new parameters not present in any previous *.conf, nginx
would simply read and add them without any further warning.

This is not bug, it’s by design. And this allows to catch obvious
configuration errors easily - without even breaking working setup,
since nginx master process will refuse to reload configuration
with bugs (and hence old worker processes with correct
configuration will continue to serve requests).

Also I should say that debian default config layout for nginx is
rather bad, since it provokes many configuration bugs. Some of
them are easy to find thanks to duplication checks, but some are
really hard to find.

Maxim D.

3

Maxim D. wrote:

This is not bug, it’s by design. And this allows to catch obvious
configuration errors easily - without even breaking working setup,
since nginx master process will refuse to reload configuration
with bugs (and hence old worker processes with correct
configuration will continue to serve requests).

I do think that the duplication check mechanism is very useful and among
the strongest points of nginx. But I was not talking about that.

nginx could still avoid breaking working setup by doing duplication
checks and catch errors. It could have the best of both worlds by simply
doing duplication check AFTER reading all .conf files, but still
giving precedence to .conf files in the priority directory /conf.d/.

I am thinking of, at least, /etc/php5/conf.d, /etc/apt/apt.conf.d,
/etc/mysql/conf.d, /etc/apache2/conf.d. They all work rather well and
respect /conf.d/*.conf precedence without breaking program’s internal
integrity.

Also I should say that debian default config layout for nginx is
rather bad, since it provokes many configuration bugs.

So, the debian nginx package maintainer is sloppy.
In your opinion what changes should be made to the Debian package to
clean those bugs?

Some of them are easy to find thanks to duplication checks,
but some are really hard to find.

Now, really helpful would be if you could provide us with a known list
of those configuration bugs, in special those hard to find. Or, at
least, point us to a web site were those configuration bugs are clearly
listed for future reference.

M.

4

I sometimes use NginX on Debian and maybe we really need to talk to
Fabio
and Jose (the package maintainers in debian) as I don’t see them post
here
ever.

In my humble opinion there is no reason NginX’s core should change from
a
very useful (in terms of safety, debugging) feature to a less useful
feature
only supporting an incomplete package.

The simplest debian-like nginx.conf is something like this:
(where N and M are appropriate numbers)

user www-data;
worker_processes N;
events {
worker_connections M;
}

http {
include mime.types;
include conf.d/.conf;
include httpd.conf;
include sites-enabled/;
}

5

On Mon, Mar 23, 2009 at 08:27:03PM +0000, Mark A. wrote:

+error_log /var/log/nginx/error.log;
+pid /var/run/nginx.pid;

http {

  • include mime.types;
  • include /etc/nginx/mime.types;
  • #access_log logs/access.log main;

  • access_log /var/log/nginx/access.log;

  • tcp_nodelay on;

“tcp_nodelay on” is default since 0.3.61.

6

Merlin wrote:

The simplest debian-like nginx.conf is something like this:

In Ubuntu/Debian the main differences are:

debian’s web server user (instead of nobody or apache)

-#user nobody;
+user www-data;

debian’s /etc/logrotate.d/nginx writes to /var/log/nginx/*.log

+error_log /var/log/nginx/error.log;
+pid /var/run/nginx.pid;

http {

  • include mime.types;
  • include /etc/nginx/mime.types;
  • #access_log logs/access.log main;

  • access_log /var/log/nginx/access.log;

  • tcp_nodelay on;

  • gzip on;

  • include /etc/nginx/conf.d/*.conf;

  • include /etc/nginx/sites-enabled/*;
    }

I attach bellow the diff file (made using diff -bru /source… /dest…

nginx.patch).

M.

–
patch follows:

— /src/nginx-0.7.43/conf/nginx.conf 2008-11-05 13:26:04.000000000
+0000
+++ /src/nginx_0.6.34-2ubuntu1~intrepid1_i386/data/etc/nginx/nginx.conf
2009-01-28 11:27:29.000000000 +0000
@@ -1,118 +1,28 @@

-#user nobody;
+user www-data;
worker_processes 1;

-#error_log logs/error.log;
-#error_log logs/error.log notice;
-#error_log logs/error.log info;

-#pid logs/nginx.pid;

+error_log /var/log/nginx/error.log;
+pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

  • http {
  • include mime.types;
  • include /etc/nginx/mime.types;
    default_type application/octet-stream;
  • #log_format main '$remote_addr - $remote_user [$time_local]
    “$request” ’

  • '"$status" $body_bytes_sent “$http_referer” ’

  • ‘"$http_user_agent" “$http_x_forwarded_for”’;

  • #access_log logs/access.log main;

  • access_log /var/log/nginx/access.log;

    sendfile on;
    #tcp_nopush on;

    #keepalive_timeout 0;
    keepalive_timeout 65;

  • tcp_nodelay on;

  • #gzip on;
  • server {
  •    listen       80;

  •    server_name  localhost;

  •    #charset koi8-r;

  •    #access_log  logs/host.access.log  main;

  •    location / {

  •        root   html;

  •        index  index.html index.htm;

  •    }

  •    #error_page  404              /404.html;

  •    # redirect server error pages to the static page /50x.html

  •    #

  •    error_page   500 502 503 504  /50x.html;

  •    location = /50x.html {

  •        root   html;

  •    }

  •    # proxy the PHP scripts to Apache listening on 127.0.0.1:80

  •    #

  •    #location ~ \.php$ {

  •    #    proxy_pass   http://127.0.0.1;

  •    #}

  •    # pass the PHP scripts to FastCGI server listening on

127.0.0.1:9000

  •    #

  •    #location ~ \.php$ {

  •    #    root           html;

  •    #    fastcgi_pass   127.0.0.1:9000;

  •    #    fastcgi_index  index.php;

  •    #    fastcgi_param  SCRIPT_FILENAME

/scripts$fastcgi_script_name;

  •    #    include        fastcgi_params;

  •    #}

  •    # deny access to .htaccess files, if Apache's document root

  •    # concurs with nginx's one

  •    #

  •    #location ~ /\.ht {

  •    #    deny  all;

  •    #}
  • }

  • another virtual host using mix of IP-, name-, and port-based

configuration

  • #server {

  • listen 8000;

  • listen somename:8080;

  • server_name somename alias another.alias;

  • location / {

  • root html;

  • index index.html index.htm;

  • }

  • #}

  • HTTPS server

  • #server {

  • listen 443;

  • server_name localhost;

  • ssl on;

  • ssl_certificate cert.pem;

  • ssl_certificate_key cert.key;

  • ssl_session_timeout 5m;

  • ssl_protocols SSLv2 SSLv3 TLSv1;

  • ssl_ciphers

ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;

  • ssl_prefer_server_ciphers on;

  • location / {

  • root html;

  • index index.html index.htm;

  • }

  • #}

  • gzip on;

  • include /etc/nginx/conf.d/*.conf;

  • include /etc/nginx/sites-enabled/*;
    }

7

Igor,

The configuration in debian is pretty much as follows:
configure arguments: --conf-path=/etc/nginx/nginx.conf
–error-log-path=/var/log/nginx/error.log --pid-path=/var/run/nginx.pid
–lock-path=/var/lock/nginx.lock
–http-log-path=/var/log/nginx/access.log
–http-client-body-temp-path=/var/lib/nginx/body
–http-proxy-temp-path=/var/lib/nginx/proxy
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi --with-debug
–with-http_stub_status_module --with-http_flv_module
–with-http_ssl_module
–with-http_dav_module

Mark,

This is a bit out of scope for this list - you need to talk to the
maintainer of the package you use.

That said, Igor is correct in pointing out as I was about it to that
there
is no need for the full path, which is why I wrote the suggested
configuration the way I did. Also in the style of these debian
configurations you would move all the non-include directives into files
in
conf.d or into httpd.conf (the global server configuration file) and NOT
have them in the main nginx block.

  • Merlin

2009/3/23 Igor S. [email protected]

8

On Mon, Mar 23, 2009 at 08:27:03PM +0000, Mark A. wrote:

+error_log /var/log/nginx/error.log;

  • gzip on;

  • include /etc/nginx/conf.d/*.conf;

  • include /etc/nginx/sites-enabled/*;
    }

Probably, it’s better to ./configure --user=, --error_log-path=,
–pid-path=, and --http-log-path= and leave them commented out
in conf file as:

#user www-data;

debian’s /etc/logrotate.d/nginx writes to /var/log/nginx/*.log

#error_log /var/log/nginx/error.log;
#pid /var/run/nginx.pid;