Custom Query (2297 matches)

Не могу никак понять в чем причина.

При запуске сервера не создаются файл логов и файл вывода ошибок в указанном мною месте, зато создается файл /var/log/nginx-error.log с правами доступа root:wheel (сам же сервер стартует с правами www:www).

# ps axwu | grep nginx root 73806 0.0 0.1 127648 9136 ?? Is 7:36AM 0:00.01 nginx: master process /usr/local/sbin/nginx www 73807 0.0 0.2 127648 9984 ?? S 7:36AM 0:00.01 nginx: worker process (nginx) www 73808 0.0 0.2 127648 9980 ?? S 7:36AM 0:00.01 nginx: worker process (nginx) www 73809 0.0 0.2 127648 9980 ?? S 7:36AM 0:00.01 nginx: worker process (nginx) www 73810 0.0 0.2 127648 9980 ?? S 7:36AM 0:00.01 nginx: worker process (nginx) www 73811 0.0 0.2 127648 9980 ?? S 7:36AM 0:00.01 nginx: worker process (nginx)

Nginx запускается без проблем, ставился он из портов Freebsd, запускается командой service nginx start, скрипт запуска изменялся (только изменил расположение PID файла).

# service nginx restart Performing sanity check on nginx configuration: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful Stopping nginx. Waiting for PIDS: 73598. Performing sanity check on nginx configuration: nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful Starting nginx.

Вот то что прописано в rc.conf:

# cat /etc/rc.conf | grep nginx nginx_enable="YES" nginxlimits_enable="YES" nginxlimits_args="-e -U www"

Это католог для файлов конфигурации сервера:

# ls -l /usr/local/etc | grep nginx drwxr-x--- 3 www www 10 Mar 29 03:48 nginx # ls -l /usr/local/etc/nginx total 27 drwxr-x--- 2 www www 11 Mar 27 07:32 dists -rw-r----- 1 www www 2837 Jan 25 18:18 koi-utf -rw-r----- 1 www www 2223 Jan 25 18:18 koi-win -rw-r----- 1 www www 3463 Jan 25 18:18 mime.types -rw-r----- 1 www www 4757 Jan 25 18:18 naxsi_core.rules -rw-r----- 1 www www 1156 Mar 29 07:03 nginx.conf -rw-r----- 1 www www 1662 Mar 29 06:39 servers.conf -rw-r----- 1 www www 3610 Jan 25 18:18 win-utf

Это предполагаемый католог для логов сервера:

# ls -l /var/log | grep nginx drwxr-xr-x 2 www www 2 Mar 27 07:47 nginx

Это часть конфига nginx.conf:

# cat /usr/local/etc/nginx/nginx.conf user www www; worker_processes 5;

error_log /var/log/nginx/error.log debug; <- пути менялись неоднократно pid /var/run/nginx/nginx.pid; <- создается без проблем

# вывод пропущен

http {

# вывод пропущен

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 /var/log/nginx/access.log main; <- пути менялись неоднократно

# вывод пропущен

}

Подобная конфигурация перенесена с Ubuntu 12.10, где логи создавались без проблем.

Можно ли как то разрешить это проблемку? Хотя проблема возможна из-за сборки сервера с патчами которые накладываются портами FreeBSD

С уважением, Дмитрий Слащёв

Hello

The configuration is pretty straightforward - the nginx server verifies clients' certificates and lets them through if they are valid. Now everything works smoothly until we add a revocation list check. After that nginx spits out '400 Bad Request' and refuses to cooperate. Here's the config:

server {
        listen 80;
        rewrite ^ https://$host$request_uri permanent;
}

server {
        listen  443 default_server ssl;
        server_name             xx.xx.se;
        ssl_certificate         /etc/ssl/hdca/hosts/tid.crt;
        ssl_certificate_key     /etc/ssl/hdca/hosts/tid.key;
        ssl_session_cache       shared:SSL:10m;
        ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers             ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;
        ssl_crl                 /etc/ssl/hdca/crl/PersonCA.crl;
#       ssl_trusted_certificate /etc/ssl/hdca/chain/serverchain.pem;
        ssl_verify_client on;
        ssl_client_certificate /etc/ssl/hdca/chain/personchain.pem;
        ssl_verify_depth 2;
        error_log /var/log/nginx/debug.log debug;

        location / {
                proxy_pass      http://111.111.111.111:80;
        }
}

Here's the x509 certificate details:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4720334111655231702 (0x4181fedd7a5e80d6)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=xxx Server CA, O=xxx, C=SE
        Validity
            Not Before: Apr 15 13:44:04 2013 GMT
            Not After : Apr 15 13:44:04 2015 GMT
        Subject: CN=xxx, O=xxx, C=SE
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
       X509v3 extensions:
            Authority Information Access: 
                OCSP - URI:http://xxx.xxx.se

            X509v3 Subject Key Identifier: 
                5D:B1:DE:7E:CE:74:65:8F:5A:82:51:3E:3A:A7:1D:9D:6B:44:D9:1B
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:33:3F:5C:C3:C2:EB:F5:E1:32:B6:85:A1:03:2E:75:EA:76:DA:72:BC

            X509v3 CRL Distribution Points: 

                Full Name:
                  URI:http://valid/and/working.crl

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Subject Alternative Name: 
                DNS:xx.xx.se

And this is the error message I get in the debug log:

2013/04/26 15:46:56 [info] 1695#0: *4 client SSL certificate verify error: (3:unable to get certificate CRL) while reading client request headers, client: 192.168.122.1, server: xxx.xx.se, request: "GET / HTTP/1.1", host: "xxx.xx.se"

Pretty interesting that if I use RootCA CRL list (for testing purposes obviously) - nginx eats up 100% of cpu and stops answering, without logging anything of value.

A similar config works both for apache and pound so there shouldn't be a problem in the certificate. It should also be noted that the certificate is not self-signed but issued by an authority.

Thank you in advance.

Since deploying nginx 1.4.1, we've noticed that $request_time and $upstream_response_time are exactly the same (for requests served with the help of an upstream server). We've observed this situation on hundreds of requests.

I'm seeing this on CentOS 6.4, installing from source.

I've checked a few versions.

The following versions are fine (the times are slightly different): 1.2.7, 1.2.8, 1.2.9, 1.3.10, 1.3.12, 1.3.14

The following versions have the problem (the times are precisely the same): 1.3.15, 1.4.0, 1.4.1

This is my first time reporting a bug here. Please let me know if you want me to clean up my bug report, or if anything's amiss.

Thanks for the awesome work.

Mat