2010年8月31日星期二

Re: GEOIP context problem

Hi, syle.

Did you test my changes for www/nginx-devel port?
Does everything works fine for you?

--
Sergey A. Osokin
osa@FreeBSD.ORG
osa@FreeBSD.ORG.ru

On Tue, Aug 31, 2010 at 10:43:38PM -0400, syle wrote:
> Sergey:
>
> I will just do following for now, so maybe overwriting fastcgi_params
> might not be such a bad thing on freebsd since we will always get
> a new copy of anything that changes automatically, i've just thrown the
> geoip values in another include as follows:
>
> location ~ \.php$ {
> #fastcgi_pass 127.0.0.1:9000;
> fastcgi_pass unix:/tmp/cgi2.sock;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> include fastcgi_params;
> include fastcgi_params_geoip;
> }
> location ~ \.pl$ {
> fastcgi_pass unix:/tmp/cgi.sock;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> include fastcgi_params;
> include fastcgi_params_geoip;
> }
>
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125883#msg-125883
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx

--
Sergey A. Osokin,
osa@FreeBSD.ORG.ru
osa@FreeBSD.ORG

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

Nginx as reverse proxy to Hudson-Logout issue.

Hello list,

I have configured nginx as a reverse proxy to our hudson build server as
follows:

[b]server {
listen 80;
server_name koala.proxy.internal;


location /hudson/ {
proxy_pass http://build.example.com/hudson/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $http_host;
proxy_redirect off;
}[/b]

The backend hudson server is configured to authenticate users with
Active Directory using
the hudson active directory plugin.

Everything works fine, except that when I click the logout button,
nothing happens, and
I am still logged in, wheras the expected behaviour is, I should be
logged out and taken
to the login page.

The request and response headers in firebug show these:

Response:

[b]HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Wed, 01 Sep 2010 02:40:57 GMT
Connection: keep-alive
Set-Cookie: ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=""; Path=/hudson
Location: http://koala.proxy.internal/hudson/
Content-Length
: 0
Expires: Thu, 02 Sep 2010 02:40:57 GMT
Cache-Control: max-age=86400[/b]

Request:

[b]GET /hudson/logout HTTP/1.1
Host: koala.proxy.internal
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8)
Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://koala.proxy.internal/hudson/people/
Cookie: screenResolution=1280x720;
JSESSIONID=8957FA425BC89DE784266DAACAD45135[/b]


Below are the headers from the hudson server, when I access it directly
and click the logout
button:

Response:

[b]HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Expires: 0
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 01 Sep 2010 05:00:33 GMT[/b]


Request:

[b]GET /hudson/login?from=%2Fhudson%2F HTTP/1.1
Host: build.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8)
Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://build.example.com/hudson/
Cookie: screenResolution=1280x720;
JSESSIONID=105C0A7031B817E0321336310FC8D6E1[/b]

As I understand from the headers,when I click logout, the GET request
should be for "/hudson/login?from=%2Fhudson%2F"
and not for "/hudson/logout" as is happening through the reverse proxy.

I have tried many things to get it working but to no avail.Would really
appreciate if someone
could guide me here.

Thanks,
Mogaroy

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125909,125909#msg-125909


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

Re: GEOIP context problem

Sergey:

I will just do following for now, so maybe overwriting fastcgi_params
might not be such a bad thing on freebsd since we will always get
a new copy of anything that changes automatically, i've just thrown the
geoip values in another include as follows:

location ~ \.php$ {
#fastcgi_pass 127.0.0.1:9000;
fastcgi_pass unix:/tmp/cgi2.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
include fastcgi_params_geoip;
}
location ~ \.pl$ {
fastcgi_pass unix:/tmp/cgi.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
include fastcgi_params_geoip;
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125883#msg-125883


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

Re: GEOIP context problem

Unfortunately the location directive only works in server context, so
fastcgi_param SCRIPT_FILENAME is always going to loose
any http context defined vars for executing php and perl scripts,
basically where they are needed.

Would be nice to be able to set location in http context for those perl
and php scripts as I have them, making them server wide for vhosts.

I'll take your other suggestion for now and just use another include
file so I stop having this issue with freebsd overwriting that file.

Thank-you.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125881#msg-125881


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

Re: Nginx capping at 320 requests per second

post to subscribe to the thread.. please disregard.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,123754,125870#msg-125870


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

Re: Nginx capping at 320 requests per second

Piotr,

Most workers aren't blocking... they only block when they hit the db,
and we are doing lots of caching. At its peak mysql is registering 140
requests per second. I've added more workers which has had no effect on
the capacity going through nginx.. so either the DB itself is causing
problems (unlikely since it is such a simple schema with no joins) or
something is up with the nginx config.

Thanks for giving this some thought!

David

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,123754,125864#msg-125864


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

Re: Nginx capping at 320 requests per second

Hi,

> Kevin, thanks for your reply.. I've turned off keepalive because the app
> is a mobile app with very simple js and css. There is very little reason
> to have keepalive. I'll try putting it up to test though. Cheers!

That .js and .css are good enough reason to have keepalive turned on.

Regarding your original issue: how much time does it take to generate single
response from Tornado? I'm asking, because you said that you've got 30
blocking workers, which means that if single response takes around 100ms,
then you can handle only about 300req/s.

Best regards,
Piotr Sikora < piotr.sikora@frickle.com >


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

Re: Nginx capping at 320 requests per second

Kevin, thanks for your reply.. I've turned off keepalive because the app
is a mobile app with very simple js and css. There is very little reason
to have keepalive. I'll try putting it up to test though. Cheers!

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,123754,125845#msg-125845


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

Re: GEOIP context problem

Hello!

On Tue, Aug 31, 2010 at 11:38:38AM -0400, syle wrote:

> Actually I'll post one of my server directives so we can see if there is
> any inheritance problems like
> you suggested, i have about 50 server directives the same as this:
> ( I know it seems quite bloated but I didn't read any way I could set
> php and perl/cgi scripts outside of
> server directivesfor all the vhosts)
>
>
> server {
> listen 80;#bind to ipv4
> listen [::]:80; #bind to ipv6
> server_name x.x.x;
> root /xxx/xxx/xxx;
> access_log /usr/nginx_logs/xxx_xxx_log main;
> error_log /usr/nginx_logs/xxx_xxx_error;
> index index.php index.pl index.html;
> error_page 404 /xxx/xxx.pl;
> error_page 500 502 503 504 /xxx/xxx.pl;
> location ~ \.php$ {
> fastcgi_index index.php;
> fastcgi_pass unix:/tmp/cgi2.sock;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> include fastcgi_params;
> }
> location ~ \.pl$ {
> fastcgi_pass unix:/tmp/cgi.sock;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> include fastcgi_params;
> }
> }
>
> ---- i do see params being set in location as you said would not work,
> So are you saying i would have to add all those GEO_IP directives to all
> 50 server directives :( perhaps maybe can suggest a way to move these
> perl and php directives outside server directives into http context to
> work with GEOIP? or I have to hope for a freebsd commit to stop removing
> that file I suppose.

As long as all fastcgi_param's are identical in all locations -
you are free to move all of them to http level.

Alternatively - nothing stops you from using another include file
for these params.

Maxim Dounin

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

Re: FastCGI Authorizers with nginx

Hello!

On Tue, Aug 31, 2010 at 11:15:24AM -0400, iT0m wrote:

> According to the specification FastCGI supports responders, filters and
> authorizers. Nginx surely supports responders. I'm not sure, if it
> supports filters, but it definitely doesn't support authorizers. Is
> there a architectural reason behind it, was it simply forgotten, or
> wasn't it requested?
> We are interested in this feature! Unfortunately we don't have any C
> knowledge. FastCGI authorizers are necessary if you want to use nginx
> together with shibboleth.

FastCGI authorizers aren't supported (as well as filters), only
responders.

You may achieve similar effect by using auth request module, see
here:

http://mdounin.ru/hg/ngx_http_auth_request_module/

Maxim Dounin

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

Re: GEOIP context problem

Hello!

On Tue, Aug 31, 2010 at 10:58:23AM -0400, syle wrote:

> Maxim:
>
> I was doing strictly in http context as module was documented nothing
> else and it was not recogised at all ie:
>
> http {
> #GEOIP, can parse ENV headers now for where they are located :)
> geoip_city /usr/local/share/GeoIP/GeoLiteCity.dat;
>
> fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
> fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
> fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
> fastcgi_param GEOIP_REGION $geoip_region;
> fastcgi_param GEOIP_CITY $geoip_city;
> fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
> fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
> fastcgi_param GEOIP_LATITUDE $geoip_latitude;
> fastcgi_param GEOIP_LONGITUDE $geoip_longitude;
>
> #virtual hosting---all server {} directives
> include /usr/local/etc/nginx/vhosts/*;
> }

And you likely have "include fastcg_params;" in your locations
blocks. This is exactly what I was talked about. You have to
set all fastcgi_param's at the same level.

Maxim Dounin

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

Re: GEOIP context problem

Actually I'll post one of my server directives so we can see if there is
any inheritance problems like
you suggested, i have about 50 server directives the same as this:
( I know it seems quite bloated but I didn't read any way I could set
php and perl/cgi scripts outside of
server directivesfor all the vhosts)


server {
listen 80;#bind to ipv4
listen [::]:80; #bind to ipv6
server_name x.x.x;
root /xxx/xxx/xxx;
access_log /usr/nginx_logs/xxx_xxx_log main;
error_log /usr/nginx_logs/xxx_xxx_error;
index index.php index.pl index.html;
error_page 404 /xxx/xxx.pl;
error_page 500 502 503 504 /xxx/xxx.pl;
location ~ \.php$ {
fastcgi_index index.php;
fastcgi_pass unix:/tmp/cgi2.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ \.pl$ {
fastcgi_pass unix:/tmp/cgi.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
}

---- i do see params being set in location as you said would not work,
So are you saying i would have to add all those GEO_IP directives to all
50 server directives :( perhaps maybe can suggest a way to move these
perl and php directives outside server directives into http context to
work with GEOIP? or I have to hope for a freebsd commit to stop removing
that file I suppose.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125687#msg-125687


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

Re: IMAP Proxy?

> On 31/08/2010 15:24, rainer@ultra-secure.de wrote:
>>> Can nginx be used as a proxy for IMAP, so that multiple users can
>>> connect to nginx but the proxied server only sees one connection? If
>>> so,
>>> how would this be configured?
>>>
>>> Background: We have 20 users who all need access to read/move emails in
>>> a single IMAP mailbox, however our current hosting company is limiting
>>> our connections to one "user" per IP, or around 10 connections (since
>>> most mail clients open multiple connections to the server).
>>
>> IMAP is not designed to handle that, AFAIK.
>> It's a ...not-so-great... idea to begin with.
>> Why do 20 users have to fuzz around a single mailbox?
>
> Customer receive an automated email and respond manually. Our staff need
> to be able to review those emails and act accordingly. Was working fine
> with a smaller team, but we've recently increased the staff due to
> response volumes.


Get a ticketing system.
Like RT3 from bestpractical.com
Totally off-topic, I know - but IMHO, nginx is really the wrong tool for
what you are trying to achieve.
IMAP-proxies are usually used in situations where the client is a
webserver...
I know you want an "easy" solution for your problem - but RT3 is really as
close as you can get.


Rainer


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

FastCGI Authorizers with nginx

According to the specification FastCGI supports responders, filters and
authorizers. Nginx surely supports responders. I'm not sure, if it
supports filters, but it definitely doesn't support authorizers. Is
there a architectural reason behind it, was it simply forgotten, or
wasn't it requested?
We are interested in this feature! Unfortunately we don't have any C
knowledge. FastCGI authorizers are necessary if you want to use nginx
together with shibboleth.

Cheers,
-Tom

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125679,125679#msg-125679


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

GEOIP not honoring REALIP_MODULE

It is assumed when we use REALIP_MODULE and purposely set REMOTE_ADDR to
real ip of our proxies in front
that this is the real client IP that GEOIP should be using.

example:
proxy of nginx in front of a fastcgi nginx.

Proxy config:
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;

Fast cgi config:
real_ip_header X-Real-IP;
set_real_ip_from x.x.x.x;

This ends up setting REMOTE_ADDR correctly for Fastcgi nginx server, but
GEOIP parses information for
proxy connecting IP instead giving false information.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125676,125676#msg-125676


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

Re: GEOIP context problem

Thankyou for repliies, as far as freebsd guy, reading your patch just
suggests not removing fast fastcgi_params file which would be a nice
commit
till this is resolved.

Maxim:

I was doing strictly in http context as module was documented nothing
else and it was not recogised at all ie:

http {
#GEOIP, can parse ENV headers now for where they are located :)
geoip_city /usr/local/share/GeoIP/GeoLiteCity.dat;

fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
fastcgi_param GEOIP_LATITUDE $geoip_latitude;
fastcgi_param GEOIP_LONGITUDE $geoip_longitude;

#virtual hosting---all server {} directives
include /usr/local/etc/nginx/vhosts/*;
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125670#msg-125670


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

Re: IMAP Proxy?

On 31/08/2010 15:24, rainer@ultra-secure.de wrote:
>> Can nginx be used as a proxy for IMAP, so that multiple users can
>> connect to nginx but the proxied server only sees one connection? If so,
>> how would this be configured?
>>
>> Background: We have 20 users who all need access to read/move emails in
>> a single IMAP mailbox, however our current hosting company is limiting
>> our connections to one "user" per IP, or around 10 connections (since
>> most mail clients open multiple connections to the server).
>
> IMAP is not designed to handle that, AFAIK.
> It's a ...not-so-great... idea to begin with.
> Why do 20 users have to fuzz around a single mailbox?

Customer receive an automated email and respond manually. Our staff need
to be able to review those emails and act accordingly. Was working fine
with a smaller team, but we've recently increased the staff due to
response volumes.

--

*Phillip B Oldham*
ActivityHQ
phill@activityhq.com <mailto:phill@theactivitypeople.co.uk>

------------------------------------------------------------------------

*Policies*

This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to anyone.

This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.

------------------------------------------------------------------------

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

Re: IMAP Proxy?

> Can nginx be used as a proxy for IMAP, so that multiple users can
> connect to nginx but the proxied server only sees one connection? If so,
> how would this be configured?
>
> Background: We have 20 users who all need access to read/move emails in
> a single IMAP mailbox, however our current hosting company is limiting
> our connections to one "user" per IP, or around 10 connections (since
> most mail clients open multiple connections to the server).


IMAP is not designed to handle that, AFAIK.
It's a ...not-so-great... idea to begin with.
Why do 20 users have to fuzz around a single mailbox?


Rainer

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

IMAP Proxy?

Can nginx be used as a proxy for IMAP, so that multiple users can
connect to nginx but the proxied server only sees one connection? If so,
how would this be configured?

Background: We have 20 users who all need access to read/move emails in
a single IMAP mailbox, however our current hosting company is limiting
our connections to one "user" per IP, or around 10 connections (since
most mail clients open multiple connections to the server).
--

*Phillip B Oldham*
ActivityHQ
phill@activityhq.com <mailto:phill@theactivitypeople.co.uk>

------------------------------------------------------------------------

*Policies*

This e-mail and its attachments are intended for the above named
recipient(s) only and may be confidential. If they have come to you in
error, please reply to this e-mail and highlight the error. No action
should be taken regarding content, nor must you copy or show them to anyone.

This e-mail has been created in the knowledge that Internet e-mail is
not a 100% secure communications medium, and we have taken steps to
ensure that this e-mail and attachments are free from any virus. We must
advise that in keeping with good computing practice the recipient should
ensure they are completely virus free, and that you understand and
observe the lack of security when e-mailing us.

------------------------------------------------------------------------

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

Re: GEOIP context problem

Hello!

On Tue, Aug 31, 2010 at 12:18:13AM -0400, syle wrote:

> There is a problem with current 0.8.x release of GEOIP although I assume
> it has always not worked, where these variables:
> fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
> fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
> fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
> fastcgi_param GEOIP_REGION $geoip_region;
> fastcgi_param GEOIP_CITY $geoip_city;
> fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
> fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
> fastcgi_param GEOIP_LATITUDE $geoip_latitude;
> fastcgi_param GEOIP_LONGITUDE $geoip_longitude;
>
> do not work except inside the fastcgi_params file. The context is
> suppose to work within http as per module documentation however setting
> these variables
> within http context ends up not setting them at all.

Most likely you attempted to do something like

http {
fastcgi_param ...
...
server {
...
location ... {
fastcgi_param ...
...
}
}
}

This won't work due to inheritance rules for array-type
directives, see here:

http://wiki.nginx.org/NginxHttpFcgiModule#fastcgi_param

"Directives set in current level clear any previously defined
directives for the current level."

You have to define all fastcgi_param directives at the same level,
i.e.

location ... {
fastcgi_param ...
fastcgi_param ...
...
}

or

http {
fastcgi_param ...
fastcgi_param ...
...
}

Maxim Dounin

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

Re: Nginx capping at 320 requests per second

Hard to say.. I am not personally familiar with Tornado but I do know nginx with a very similar config with keepalive's at 5/10 seconds will do much more than that..

It's a very odd situation. I know it sounds dumb but do you have any errors in your 'dmesg' or in the nginx logs? Is it running out of buffered memory or system sockets?

Is reuse connections on in your sysctl's? I would double-check your sysctl config and personally I would run KeepAlive. This would ensure reusing connections and not opening a new connection for every request.

Everyone has their own opinion keepalive with attacks, large volumes of traffic, etc. However, we have found it to perform much better, less resources, and worse case - if you are having a bottleneck from something else then it would likely be more efficient.

-Kevin
------Original Message------
From: dpn
To: nginx@nginx.org
ReplyTo: nginx@nginx.org
Subject: Re: Nginx capping at 320 requests per second
Sent: Aug 31, 2010 1:19 AM

Hello again, we added another machine with 15 workers and are still
getting the 320rps cap from nginx:
http://dl.dropbox.com/u/367355/nginxday.png

I've posted my config earlier... I don't suppose anyone has a suggestion
about what might be causing the issue?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,123754,125474#msg-125474


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

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

Re: cancel upload file

There aren't any way do to this?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125113,125520#msg-125520


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

Re: GEOIP context problem

Index: ports/www/nginx-devel/Makefile
===================================================================
RCS file: /home/pcvs/ports/www/nginx-devel/Makefile,v
retrieving revision 1.338
diff -u -r1.338 Makefile
--- ports/www/nginx-devel/Makefile 18 Aug 2010 09:37:34 -0000 1.338
+++ ports/www/nginx-devel/Makefile 31 Aug 2010 07:34:04 -0000
@@ -7,6 +7,7 @@

PORTNAME= nginx
PORTVERSION= 0.8.49
+PORTREVISION= 1
CATEGORIES= www
MASTER_SITES= http://sysoev.ru/nginx/
MASTER_SITES+= ${MASTER_SITE_LOCAL}
@@ -498,10 +499,10 @@
${MKDIR} ${ETCDIR} ${NGINX_TMPDIR}
${CHOWN} ${WWWOWN}:${WWWGRP} ${NGINX_TMPDIR}
${INSTALL_PROGRAM} ${WRKSRC}/objs/nginx ${PREFIX}/sbin
-.for i in fastcgi_params koi-utf koi-win scgi_params uwsgi_params win-utf
+.for i in koi-utf koi-win win-utf
${INSTALL_DATA} ${WRKSRC}/conf/${i} ${ETCDIR}
.endfor
-.for i in mime.types nginx.conf
+.for i in fastcgi_params mime.types nginx.conf scgi_params uwsgi_params
[ -f ${ETCDIR}/${i} ] || \
${INSTALL_DATA} ${WRKSRC}/conf/${i} ${ETCDIR}
${INSTALL_DATA} ${WRKSRC}/conf/${i} ${ETCDIR}/${i}-dist
Index: ports/www/nginx-devel/pkg-plist
===================================================================
RCS file: /home/pcvs/ports/www/nginx-devel/pkg-plist,v
retrieving revision 1.14
diff -u -r1.14 pkg-plist
--- ports/www/nginx-devel/pkg-plist 14 Jul 2010 12:19:44 -0000 1.14
+++ ports/www/nginx-devel/pkg-plist 31 Aug 2010 07:34:04 -0000
@@ -1,9 +1,15 @@
@comment $FreeBSD: ports/www/nginx-devel/pkg-plist,v 1.14 2010/07/14 12:19:44 osa Exp $
+@unexec if cmp -s %D/%%ETCDIR%%/fastcgi_params-dist %D/%%ETCDIR%%/fastcgi_params; then rm -f %D/%%ETCDIR%%/fastcgi_params; fi
%%ETCDIR%%/fastcgi_params
+@exec if [ ! -f %D/%%ETCDIR%%/fastcgi_params ] ; then cp -p %D/%F %B/fastcgi_params; fi
%%ETCDIR%%/koi-utf
%%ETCDIR%%/koi-win
+@unexec if cmp -s %D/%%ETCDIR%%/scgi_params-dist %D/%%ETCDIR%%/scgi_params; then rm -f %D/%%ETCDIR%%/scgi_params; fi
%%ETCDIR%%/scgi_params
+@exec if [ ! -f %D/%%ETCDIR%%/scgi_params ] ; then cp -p %D/%F %B/scgi_params; fi
+@unexec if cmp -s %D/%%ETCDIR%%/uwsgi_params-dist %D/%%ETCDIR%%/uwsgi_params; then rm -f %D/%%ETCDIR%%/uwsgi_params; fi
%%ETCDIR%%/uwsgi_params
+@exec if [ ! -f %D/%%ETCDIR%%/uwsgi_params ] ; then cp -p %D/%F %B/uwsgi_params; fi
%%ETCDIR%%/win-utf
@unexec if cmp -s %D/%%ETCDIR%%/mime.types-dist %D/%%ETCDIR%%/mime.types; then rm -f %D/%%ETCDIR%%/mime.types; fi
%%ETCDIR%%/mime.types-dist
On Tue, Aug 31, 2010 at 12:18:13AM -0400, syle wrote:
> There is a problem with current 0.8.x release of GEOIP although I assume
> it has always not worked, where these variables:
> fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
> fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
> fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
> fastcgi_param GEOIP_REGION $geoip_region;
> fastcgi_param GEOIP_CITY $geoip_city;
> fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
> fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
> fastcgi_param GEOIP_LATITUDE $geoip_latitude;
> fastcgi_param GEOIP_LONGITUDE $geoip_longitude;
>
> do not work except inside the fastcgi_params file. The context is
> suppose to work within http as per module documentation however setting
> these variables
> within http context ends up not setting them at all.
>
> This is currently a major issue especially in freebsd where an upgrade
> of version from port collections can wipe out fastcgi_params file each
> time, leaving
> any webserver relying on these variables in major trouble if they were
> to forget to replace fastcgi_params file afterwards.

Could you test following patch against current version of
ports/www/nginx-devel ?

Thank you.

--
Sergey A. Osokin,
osa@FreeBSD.ORG.ru
osa@FreeBSD.ORG

2010年8月30日星期一

Re: Nginx capping at 320 requests per second

Hello again, we added another machine with 15 workers and are still
getting the 320rps cap from nginx:
http://dl.dropbox.com/u/367355/nginxday.png

I've posted my config earlier... I don't suppose anyone has a suggestion
about what might be causing the issue?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,123754,125474#msg-125474


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

GEOIP context problem

There is a problem with current 0.8.x release of GEOIP although I assume
it has always not worked, where these variables:
fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
fastcgi_param GEOIP_LATITUDE $geoip_latitude;
fastcgi_param GEOIP_LONGITUDE $geoip_longitude;

do not work except inside the fastcgi_params file. The context is
suppose to work within http as per module documentation however setting
these variables
within http context ends up not setting them at all.

This is currently a major issue especially in freebsd where an upgrade
of version from port collections can wipe out fastcgi_params file each
time, leaving
any webserver relying on these variables in major trouble if they were
to forget to replace fastcgi_params file afterwards.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125449#msg-125449


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

Re: too many open files

Yes, that revealed the cause I think that was set to 1024.


Sent on the Sprint® Now Network from my BlackBerry®

-----Original Message-----
From: Scott Trudeau <scott.trudeau@gmail.com>
Date: Mon, 30 Aug 2010 17:31:38
To: <nginx@nginx.org>
Reply-To: nginx@nginx.org
Subject: Re: too many open files

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

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

Re: too many open files

Ilan,

Try:

ulimit -n

Scott

On Mon, Aug 30, 2010 at 5:17 PM, Ilan Berkner <iberkner@gmail.com> wrote:
Our site is getting busy and we are now getting these errors:

2010/08/30 16:10:47 [alert] 4729#0: accept() failed (24: Too many open files)

I've already looked online in several places but am unclear about how to more clearly diagnose the problem and correct.  Any help as always is greatly appreciated.

Running: cat /proc/sys/fs/file-max

yields: 800669

Running ulimit

yields: unlimited

Top of Nginx configuration looks like this:

worker_processes  5;

events {
    worker_connections  4096;
}

I've looked here:


and here:


Running CentOS




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


too many open files

Our site is getting busy and we are now getting these errors:

2010/08/30 16:10:47 [alert] 4729#0: accept() failed (24: Too many open files)

I've already looked online in several places but am unclear about how to more clearly diagnose the problem and correct.  Any help as always is greatly appreciated.

Running: cat /proc/sys/fs/file-max

yields: 800669

Running ulimit

yields: unlimited

Top of Nginx configuration looks like this:

worker_processes  5;

events {
    worker_connections  4096;
}

I've looked here:


and here:


Running CentOS



Re: Possible widespread PHP configuration issue - security risk

All I'm reading here is reiterations of the previous discussion and
language elites-ism .

This is an extremely old issue, the opinion last time was that this is
not something that should be fixed in Nginx. Nginx is a reverse proxy
and there may be very valid cases where allowing such URIs make sense.

The *real* solution is to fix the php pathinfo setting, it's archaic and
shouldn't be used unless absolutely necessary. That said, I did look
around a bit on the wiki and it wasn't covered overly much, about the
only place was in my Nginx primer post so I'll go ahead and add a
section on the pitfalls page that details the issue.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,124297,125274#msg-125274


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

Read a local variable / http variable from config file in C [dev]

Hello,

I write a new module to nginx, and I have a small problem, because I
don't know how I can read local/http variable (for example from GeoIP
module) from nginx configuration file in my module. Below is a piece of
my code :

my_module.c
-
{ ngx_string("my_language"),

NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF|NGX_HTTP_SIF_CONF|NGX_CONF_TAKE1,
ngx_conf_set_str_slot,
NGX_HTTP_LOC_CONF_OFFSET,
offsetof(ngx_http_my_loc_conf_t, language),
NULL },
-

nginx.conf
-
...
geoip_country_file /usr/local/nginx/GeoIP.dat;
...
my_language $geoip_country_code;
...
-

But in the variable language in ngx_http_my_loc_conf_t struct, I have
string not parsed "$geoip_country_code" not a "US". GeoIP module works,
I checked.

Please for any suggestions,
Thanks in advance.
-

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125270,125270#msg-125270


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

Re: Rewrite lookup via MySQL table

Ah, thanks, that does make sense!

agentzh Wrote:
-------------------------------------------------------
> On Sat, Aug 28, 2010 at 8:54 PM, relix wrote:
> > First of all, this thread contains a lot of
> information! I'm in the
> > process of implementing something similar and it
> has helped me a ton.
> >
> > I was just wondering, as long as you're using
> Lua anyway, why not do
> > away with Drizzle completely, and just make Lua
> connect to the database
> > to retrieve the correct URL?
>
> Lua's database library will block the nginx
> process which is
> unacceptable for real world applications.
> ngx_drizzle is served as a
> non-blocking mysql driver component for Lua here
> (of cause, it can
> also work with ngx_http_js_module and others).
>
> > Is it because Drizzle will keep one
> > connection to the database per nginx-instance,
> so there is less
> > overhead,
>
> Actually ngx_drizzle can keep connection pools to
> mysql backends per
> nginx instance. One db connection per process is
> the suboptimal
> PHP/Perl way of doing things and it can waste a
> lot of database
> resources.
>
> > compared to Lua which would have to connect and
> disconnect to
> > the database for every request?
> >
>
> MUCH more than just that ;)
>
> Cheers,
> -agentzh
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,122977,125201#msg-125201


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

Re: Rewrite lookup via MySQL table

I am new to nginx,
but, as far as I know,
nginx is known to be a fast light webserver.

So, having each rewrite to be looked up in a mysql table seems
something very slow idea.
rewrite is something to be done on the fly, as fast as possible. and
putting a mysql layer in this process seems not a good idea.

On Mon, Aug 30, 2010 at 1:31 PM, bvidinli <bvidinli@gmail.com> wrote:
> I am new to nginx,
> bug, as far as I know,
> nginx is known to be a fast light webserver.
>
> So, having each rewrite to be looked up in a mysql table seems
> something very slow idea.
> rewrite is something to be done on the fly, as fast as possible. and
> putting a mysql layer in this process seems not a good idea.
>
>
> On Mon, Aug 30, 2010 at 6:20 AM, agentzh <agentzh@gmail.com> wrote:
>> On Sat, Aug 28, 2010 at 8:54 PM, relix <nginx-forum@nginx.us> wrote:
>>> First of all, this thread contains a lot of information! I'm in the
>>> process of implementing something similar and it has helped me a ton.
>>>
>>> I was just wondering, as long as you're using Lua anyway, why not do
>>> away with Drizzle completely, and just make Lua connect to the database
>>> to retrieve the correct URL?
>>
>> Lua's database library will block the nginx process which is
>> unacceptable for real world applications. ngx_drizzle is served as a
>> non-blocking mysql driver component for Lua here (of cause, it can
>> also work with ngx_http_js_module and others).
>>
>>> Is it because Drizzle will keep one
>>> connection to the database per nginx-instance, so there is less
>>> overhead,
>>
>> Actually ngx_drizzle can keep connection pools to mysql backends per
>> nginx instance. One db connection per process is the suboptimal
>> PHP/Perl way of doing things and it can waste a lot of database
>> resources.
>>
>>> compared to Lua which would have to connect and disconnect to
>>> the database for every request?
>>>
>>
>> MUCH more than just that ;)
>>
>> Cheers,
>> -agentzh
>>
>> _______________________________________________
>> nginx mailing list
>> nginx@nginx.org
>> http://nginx.org/mailman/listinfo/nginx
>>
>

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

Re: Rewrite lookup via MySQL table

I am new to nginx,
bug, as far as I know,
nginx is known to be a fast light webserver.

So, having each rewrite to be looked up in a mysql table seems
something very slow idea.
rewrite is something to be done on the fly, as fast as possible. and
putting a mysql layer in this process seems not a good idea.


On Mon, Aug 30, 2010 at 6:20 AM, agentzh <agentzh@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 8:54 PM, relix <nginx-forum@nginx.us> wrote:
>> First of all, this thread contains a lot of information! I'm in the
>> process of implementing something similar and it has helped me a ton.
>>
>> I was just wondering, as long as you're using Lua anyway, why not do
>> away with Drizzle completely, and just make Lua connect to the database
>> to retrieve the correct URL?
>
> Lua's database library will block the nginx process which is
> unacceptable for real world applications. ngx_drizzle is served as a
> non-blocking mysql driver component for Lua here (of cause, it can
> also work with ngx_http_js_module and others).
>
>> Is it because Drizzle will keep one
>> connection to the database per nginx-instance, so there is less
>> overhead,
>
> Actually ngx_drizzle can keep connection pools to mysql backends per
> nginx instance. One db connection per process is the suboptimal
> PHP/Perl way of doing things and it can waste a lot of database
> resources.
>
>> compared to Lua which would have to connect and disconnect to
>> the database for every request?
>>
>
> MUCH more than just that ;)
>
> Cheers,
> -agentzh
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx
>

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

cancel upload file

Hi everyone! I'm using Nginx + upload progress module and I have a
question: is there a way to stop the download file?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125113,125113#msg-125113


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

subrequest in range-filter

hi,
 
I want to write a filter, which may create some subrequests.
And all of these subrequests need be supported by range-filter (src/http/modules/ngx_http_range_filter_module.c).
But there is a check in range-header-filter, something like this:
    if(r!=r->main) return ngx_http_next_header_filter(r);
It seem that the range-filter does not support the subrequest.
So I get 2 questions.
1. why dose the range-filter not support the subrequest?
2. If I want to write a filter which create subrequests that need range support, how?
 
 
Thanks,
Wu



您想拥有和网易免费邮箱一样强大的软件吗?

2010年8月29日星期日

Re: Rewrite lookup via MySQL table

On Sat, Aug 28, 2010 at 8:54 PM, relix <nginx-forum@nginx.us> wrote:
> First of all, this thread contains a lot of information! I'm in the
> process of implementing something similar and it has helped me a ton.
>
> I was just wondering, as long as you're using Lua anyway, why not do
> away with Drizzle completely, and just make Lua connect to the database
> to retrieve the correct URL?

Lua's database library will block the nginx process which is
unacceptable for real world applications. ngx_drizzle is served as a
non-blocking mysql driver component for Lua here (of cause, it can
also work with ngx_http_js_module and others).

> Is it because Drizzle will keep one
> connection to the database per nginx-instance, so there is less
> overhead,

Actually ngx_drizzle can keep connection pools to mysql backends per
nginx instance. One db connection per process is the suboptimal
PHP/Perl way of doing things and it can waste a lot of database
resources.

> compared to Lua which would have to connect and disconnect to
> the database for every request?
>

MUCH more than just that ;)

Cheers,
-agentzh

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

How to Rip DVD to AVI/WMV/MP4/MPG/FLV/MOV/DIVX/XVID/MP3/AAC/AC3/WMA/WAV...

How to Rip DVD to
AVI/WMV/MP4/MPG/FLV/MOV/DIVX/XVID/MP3/AAC/AC3/WMA/WAV...How to Rip DVD
to AVI/WMV/MP4/MPG/FLV/MOV/DIVX/XVID/MP3/AAC/AC3/WMA/WAV...How to Rip
DVD to AVI/WMV/MP4/MPG/FLV/MOV/DIVX/XVID/MP3/AAC/AC3/WMA/WAV...How to
Rip DVD to AVI/WMV/MP4/MPG/FLV/MOV/DIVX/XVID/MP3/AAC/AC3/WMA/WAV...

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125048,125048#msg-125048


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

Re: RFC: Feasibility of a "dynamic module loader" built in to nginx?

Hi,

What might work just as well, and wouldn't suffer the API / performance
issues would be making it easier to compile optional modules into the
source without recompiling the whole Nginx source code.

When I'm doing module development, I just build the object code of the
module I'm writing, and combined it with the pre-compiled object files
of all the other parts of Nginx, thereby typically taking less than a
second to compile (I'm assuming most developers do this too).

It would be nice to be able to have an alternative build script that
makes it easier to do this in a customizable way, allowing the reuse of
existing object code if it's available, compiling it if it's not and
forcing re-compiling if so desired.

It could be set up to accept the normal configuration options, then
automatically work out which object files needed to be re-generated and
which ones could use the pre-compiled versions, and could be extended to
include options and 3rd party modules too.

It wouldn't be particularly difficult to do this, but I'm really busy
with other stuff at the moment. If someone wants to write such a script,
I'll add it to the ngx_devel_kit
(http://github.com/simpl-it/ngx_devel_kit). Otherwise I'll write it at
some point later on, but I can't give any timelines as of yet.

Cheers,

Marcus.

On 29/08/2010 23:17, Piotr Sikora wrote:
> Hi,
> I was thinking about this about two weeks, but (as Maxim already
> pointed out) currently there is no ABI, which means that you would
> need to build modules against your target nginx version on your target
> operating system.
>
> This renders this idea viable only for 3 use cases that I can think of
> right now:
> 1) operating system's pre-compiled binary packages,
> 2) corporate environments / clusters with staging server(s),
> 3) closed-source modules.
>
> Having this probably wouldn't hurt, but it won't be useful for as many
> people as you would hope to.
>
> Best regards,
> Piotr Sikora < piotr.sikora@frickle.com >
>
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx


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

test

test

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125021,125021#msg-125021


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

Re: RFC: Feasibility of a "dynamic module loader" built in to nginx?

Hi,
I was thinking about this about two weeks, but (as Maxim already pointed
out) currently there is no ABI, which means that you would need to build
modules against your target nginx version on your target operating system.

This renders this idea viable only for 3 use cases that I can think of right
now:
1) operating system's pre-compiled binary packages,
2) corporate environments / clusters with staging server(s),
3) closed-source modules.

Having this probably wouldn't hurt, but it won't be useful for as many
people as you would hope to.

Best regards,
Piotr Sikora < piotr.sikora@frickle.com >


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

Re: A Control Panel for Nginx?

ehcp (Easy Hosting Control Panel) is going to support nginx as a
webserver, directly inside it.
it is being tested.
you may also test it using http://ehcp.net/ehcp_yeni.tgz
file
download and start install.sh
it will install panel, nginx and all hosting related files.
(note that this is a testing version, may contain bugs.)

On Sun, Aug 29, 2010 at 6:46 PM, Vi Ktor <lists@ruby-forum.com> wrote:
> Webmin/Virtualmin control panel for Nginx
> http://github.com/rrouse/nginx-webmin/
>
> --
> Posted via http://www.ruby-forum.com/.
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx
>

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

Re: A Control Panel for Nginx?

Webmin/Virtualmin control panel for Nginx
http://github.com/rrouse/nginx-webmin/

--
Posted via http://www.ruby-forum.com/.

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

[ANNOUNCE] uWSGI 0.9.6

I am pleased to announce the 0.9.6 release of the uWSGI project

http://projects.unbit.it/uwsgi/wiki

updated documentation:

http://projects.unbit.it/uwsgi/wiki/Doc
http://projects.unbit.it/uwsgi/wiki/Example

direct download:

http://projects.unbit.it/downloads/uwsgi-0.9.6.tar.gz


* Changelog *

- better handling of SCRIPT_NAME
- vacuum option for deleting unix sockets and pidfiles after usage
- advanced XML configuration
- new configuration systems: INI files and LDAP
- embedded HTTP server for development/testing
- better signal handling
- PSGI plugin improved
- usability fixes and new commodities options for root startup
- grunt processes (detached workers)
- preliminary integrated virtualhosting mode
- new option catch-exceptions can redirect python exceptions to your browser
- logging improvements (--logto and --logdate options)
- Full PEP 333 compliant usage of wsgi.file_wrapper
- re-initialize random seed after every fork() [security fix]
- fix Spooler's usage of stdin
- export WSGI environment in uwsgi.env (for doing evil things)
- logsize tracking (uwsgi.logsize) for future embedded log rotation

Special thanks for this release go to

Leonid Borisenko
Riccardo Magliocchetti
Markus Gattol
Jonas Borgström
Damjan Georgievski
Piotr Sikora
Daniel Gerzo

And thanks to all uWSGI users for their support

--
Roberto De Ioris
http://unbit.it
JID: roberto@jabber.unbit.it


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

nginx as a reverse proxy and SOGo

Hi All,

I have successfully installed SOGo and it works fine when accessed
directly from the machine where it is installed. I have now set up
another server which which will run nginx as a reverse proxy for traffic
coming from outside. My problem is that although nginx is working fine
serving web pages from the server where SOGo is installed, I cannot get
it show any pages for SOGo... not even the logon page. Can any please
guide me with the nginx config required to get SOGo working through the
reverse proxy?

TIA

Artie

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,124772,124772#msg-124772


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

2010年8月28日星期六

Re: Encrypt the $remote_addr in log files

Hello!

On Sat, Aug 28, 2010 at 12:39:44PM +0200, Dimitri Roschkowski wrote:

> Hi, I want to give the user of my websites more privacy. Well – I
> just need the logs for debugging and some statistics. So I don't
> need to save the real users IP address, but I need some kind of
> identifier string to separate users (like I do with IP addresses
> now). My idea is to just run md5 on the IP address, so I get a
> unique string for every IP address.
>
> On the http://wiki.nginx.org/NginxHttpLogModule LogModule page in
> the Nginx Wiki I couldn't find all variables, I can use in the log
> files. So is there a build in feature to encrypt the IP address or
> do I have to write my own (small) module to get this feature?

In log files you may use all variables from all modules. But
there is no one with md5 of $remote_addr.

With embedded perl module you may use perl_set to produce
apropriate variable. Though it would be probably better to write
simple module instead if you don't already have embedded perl in
your nginx for other reasons.

Maxim Dounin

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

Re: timer_resolution / $request_time

Hello!

On Fri, Aug 27, 2010 at 02:41:52PM -0400, Arthur Blake wrote:

> Is there anyway to get the request time in microseconds resolution in order
> to emulate Apache's %D log format option?

No.

> It looks like the only option at this time is to just fake it with something
> like "$request_time000" (since 1 millsecond = 1000 microsecond)

${request_time}000

Maxim Dounin

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

Re: Rewrite lookup via MySQL table

First of all, this thread contains a lot of information! I'm in the
process of implementing something similar and it has helped me a ton.

I was just wondering, as long as you're using Lua anyway, why not do
away with Drizzle completely, and just make Lua connect to the database
to retrieve the correct URL? Is it because Drizzle will keep one
connection to the database per nginx-instance, so there is less
overhead, compared to Lua which would have to connect and disconnect to
the database for every request?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,122977,124586#msg-124586


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

Re: Possible widespread PHP configuration issue - security risk

On Sat, Aug 28, 2010 at 3:14 AM, Ed W <lists@wildgooses.com> wrote:

> I will believe you that this works, but it seems incredibly subtle and I for
> one don't quite understand why it's working?
>
> My point is only that we need to document how/why this is the solution or
> users will deviate (innocently) and re-introduce the problem

It is a bit more complex to drop in and not as "straightforward" as
one might hope. At the moment I have this working:

main nginx.conf in a server {} block:

set $fastcgi 127.0.0.1:11000;
include confs/php.conf;

root@local:/etc/nginx# cat confs/php.conf
location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
fastcgi_buffers 16 8k;
fastcgi_buffer_size 8k;
fastcgi_busy_buffers_size 16k;
fastcgi_ignore_client_abort on;
fastcgi_index index.php;
fastcgi_intercept_errors on;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param PATH_INFO $path_info;
fastcgi_param REDIRECT_STATUS 200;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param SCRIPT_FILENAME $document_root$script;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_NAME $http_host;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;
fastcgi_pass $fastcgi;
}

Now, it looks like $_SERVER['PATH_INFO'] is never filled in unless you
have /foo.php/somethingafterit

With cgi.fix_pathinfo=1, PATH_INFO = "/foo.php/somethingafterit"
With cgi.fix_pathinfo=0, PATH_INFO = "/somethingafterit"

Otherwise, PATH_INFO is empty if there is nothing after the .php.

PHP_SELF is empty using the new style approach to the nginx config block.

Using the old style, $_SERVER['PHP_SELF'] works; I tried setting a
fastcgi_param for it, but it did not take. It seems like this is
derived internally in PHP and not able to be overridden.

A lot of things reference PHP_SELF, so this could introduce an issue.
It's late, but my quick tests show a glaring caveat with that.

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

Re: Encrypt the $remote_addr in log files

On Sat, Aug 28, 2010 at 2:39 PM, Dimitri Roschkowski <dr@rootix.de> wrote:
> Hi, I want to give the user of my websites more privacy. Well – I just need
> the logs for debugging and some statistics. So I don't need to save the real
> users IP address, but I need some kind of identifier string to separate
> users (like I do with IP addresses now). My idea is to just run md5 on the
> IP address, so I get a unique string for every IP address.
>
> On the http://wiki.nginx.org/NginxHttpLogModule LogModule page in the Nginx
> Wiki I couldn't find all variables, I can use in the log files. So is there
> a build in feature to encrypt the IP address or do I have to write my own
> (small) module to get this feature?
You can use built-in perl to hash variables.

--
Boris Dolgov.

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

Encrypt the $remote_addr in log files

Hi, I want to give the user of my websites more privacy. Well – I just
need the logs for debugging and some statistics. So I don't need to save
the real users IP address, but I need some kind of identifier string to
separate users (like I do with IP addresses now). My idea is to just run
md5 on the IP address, so I get a unique string for every IP address.

On the http://wiki.nginx.org/NginxHttpLogModule LogModule page in the
Nginx Wiki I couldn't find all variables, I can use in the log files. So
is there a build in feature to encrypt the IP address or do I have to
write my own (small) module to get this feature?

-- Dimitri


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

Re: Possible widespread PHP configuration issue - security risk

On 27/08/2010 16:45, Jim Ohlstein wrote:
> On 8/27/10 11:22 AM, Ed W wrote:
>>
>> Create a test file test.jpg as follows:
>> # echo -e "\xff\xd8\xff\xe0\n<?php echo 'hello'; ?>" > test.jpg
>> # file test.jpg
>> test.jpg: JPEG image data
>>
>> Now try and upload this test.jpg file to your server. If it succeeds
>> then probably turn off the server until you fix the issue...
>
> It doesn't work on the apps I mentioned. It simply won't upload.


The apps you mentioned were vBulletin and IPB. I have done a little
more research on this and I believe I can smuggle in the PHP using jpeg
comments. The resulting file should pass all tests as a valid JPG, but
still be executable to the PHP interpreter...

The point is: my expectation is that with a bit of wriggling it should
be possible to find something which should get past your image upload
checks, but your PHP interpreter will still happily process it. If your
server is misconfigured to allow accidental execution of such files then
I think you have a gaping hole in your security... Bottom line is to
*completely disable* execution of all untrusted files (variety of ways
to do that of course)

Personally I don't believe in trusting *only* to the upload filtering to
secure a web application. There is simply too much subtlety here that a
well crafted file should eventually be able to bypass...

Ed W

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

Re: Possible widespread PHP configuration issue - security risk

On 27/08/2010 20:06, Michael Shadle wrote:
Initial testing shows:  cgi.fix_pathinfo = 0  and Igor's suggestion:  location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {     fastcgi_pass 127.0.0.1:11000;     fastcgi_param   SCRIPT_FILENAME  $document_root$script;     fastcgi_param   PATH_INFO        $path_info;     include fastcgi_params; }  To be working properly. I need to check out PATH_INFO using old style and new style, make sure it still reports the expected behavior for PHP scripts (PATH_INFO, PHP_SELF, all that jazz) 


I will believe you that this works, but it seems incredibly subtle and I for one don't quite understand why it's working? 

My point is only that we need to document how/why this is the solution or users will deviate (innocently) and re-introduce the problem


Please, please also lets have the final solution also include an example of how to efficiently *exclude* a certain directory. A good proportion of apps that I have seen, ship with example Apache configurations that do exactly this. 

The suggestion was adding an excluded location:

    location ^~ /images/ {         # just handle as static, don't consult regexps     } 
However, the issue I see here is that the user then needs to specifically configure how that location should be handled, rather than it being an *exclusion* to the original location

Can we work excluded locations into the regexp (negative lookahead supported?):

	location ~ ^(?!/images/)(?<script>.+\.php)(?<path_info>.*)$ { 

The justification for excluding specific locations from the PHP interpretor is that *most* applications don't encourage uploaded executable cgi scripts and better apps are going to ship with a recommendation to disable script execution in the upload directory.  Actually the situation is worse on Apache because there are so many ways to trick the interpreter to run files.  However, it's seems to be such standard practice on Apache that it seems prudent to include it in our standardised solution?

Lots of justifications for this via google:
    http://www.google.co.uk/search?hl=en&q=disable+php+script+execution+upload

Someone argued that this might be *wanted* by the application... (Some apps *wants* users to upload .php files which should then be executable...??!!).  I claim that it will be a serious minority of applications desire this, and the vast majority will want uploaded files to be non executable (regardless of extension)

Can we please, please, please try and make sure the recommended configuration includes examples of specifically *excluding* locations not expected to contain executable scripts...  My proposal above...

Ed W

2010年8月27日星期五

Re: Is directive alias incompatible with module FastCGI?

On Sat, Aug 28, 2010 at 7:27 AM, IPB_Refugee <nginx-forum@nginx.us> wrote:
> Hello,
>
> I hope it is allowed to bump a topic after 10 days without an answer.
>
> I think it's simply a bug within nginx. And I hope, it will be resolved
> at some time.
>

move the

location ~ ^/test/(.+\.php)$ { ... }

above

location ~ /test/ { ... }

(and make it "location /test/ { ... }"

--
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

Re: Is directive alias incompatible with module FastCGI?

Hello,

I hope it is allowed to bump a topic after 10 days without an answer.

I think it's simply a bug within nginx. And I hope, it will be resolved
at some time.

Thanks for reading and have a nice weekend
Wolfgang

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,120664,124489#msg-124489


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

Re: error in nginx-0.8.42: [emerg]: mkdir() "/usr/local/nginx/uwsgi_temp" failed

serepo Wrote:
-------------------------------------------------------
> In addition to Jean hughes:
>
> I also installed from the ppa in ubuntu lucid, and
> created /usr/local/nginx
> Then I made the user (& group) www-data, who
> apparently is created by the nginx install
> package, owner of /usr/local/nginx/ with read &
> write access.
> Start nginx with /etc.init.d/nginx start and
> youŕe ready to go.
>
> Cheers Sebastiaan

It looks like that PPA has had some problems for the last 12 days.

On 8/12/2010 it built a package successfully but did not include those
two temp paths.
Build log:
http://launchpadlibrarian.net/53535379/buildlog_ubuntu-lucid-i386.nginx_0.8.49-1ppa1_FULLYBUILT.txt.gz

But then again on 8/12/2010 it tried to rebuild with the needed
options:
--http-scgi-temp-path=/var/lib/nginx/scgi \
--http-uwsgi-temp-path=/var/lib/nginx/uwsgi \
but failed to build.
Build log:
http://launchpadlibrarian.net/53565334/buildlog_ubuntu-lucid-i386.nginx_0.8.49%2Btime~lucid1_FAILEDTOBUILD.txt.gz

Looks like a naming problem. Package name changed and it applied that
to the source path and then it couldn't find the upstream-fair module
and died.

Please contact the maintainer of the PPA.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,102597,124478#msg-124478


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

Re: error in nginx-0.8.42: [emerg]: mkdir() "/usr/local/nginx/uwsgi_temp" failed

In addition to Jean hughes:

I also installed from the ppa in ubuntu lucid, and created
/usr/local/nginx
Then I made the user (& group) www-data, who apparently is created by
the nginx install package, owner of /usr/local/nginx/ with read & write
access.
Start nginx with /etc.init.d/nginx start and youŕe ready to go.

Cheers Sebastiaan

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,102597,124470#msg-124470


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

Re: timer_resolution / $request_time

that doesn't actually work:

[emerg]: unknown "request_time000" variable

any ideas?

On Fri, Aug 27, 2010 at 2:41 PM, Arthur Blake <arthur.blake@gmail.com> wrote:
Is there anyway to get the request time in microseconds resolution in order to emulate Apache's %D log format option?
It looks like the only option at this time is to just fake it with something like "$request_time000" (since 1 millsecond = 1000 microsecond)


On Thu, Aug 26, 2010 at 6:59 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
Hello!

On Thu, Aug 26, 2010 at 11:23:47PM +0200, Xavier Martin wrote:

> Hello,
>
> I've been using this settings for a while:
> timer_resolution 100ms;
> log_format combined_time '$remote_addr - $remote_user [$time_local]  '
>                    '"$request" $status $body_bytes_sent '
>                    '"$http_referer" "$http_user_agent"'
>                    ' $request_time';
> access_log /var/log/access.log combined_time;
>
> Right now i'm needing more precise timestamp in logs
> => finding requests that took less than 50ms to complete.
>
> I would like to know what are the drawbacks of using a lower number
> (i.e 10ms, 0ms or not setting at all timer_resolution) and overhead that would cause (if any).

With timer_resolution unset (set to 0, default) nginx will call
gettimeofday() on every event loop iteration.  With
timer_resolution set nginx will schedule
gettimeofday() calls at specified interval.

Obviously changing it from 100ms to 10ms would cause 10 times
more gettimeofday() calls.  But most likely you won't notice.

But actually I would recommend using the default (i.e. unset).
It's not really different from 10ms on loaded servers and wouldn't
cause extra work on otherwise idle servers.

Maxim Dounin

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


Re: Possible widespread PHP configuration issue - security risk

Initial testing shows:

cgi.fix_pathinfo = 0

and Igor's suggestion:

location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
   fastcgi_pass 127.0.0.1:11000;
   fastcgi_param   SCRIPT_FILENAME  $document_root$script;
   fastcgi_param   PATH_INFO        $path_info;
   include fastcgi_params;
}

To be working properly. I need to check out PATH_INFO using old style
and new style, make sure it still reports the expected behavior for
PHP scripts (PATH_INFO, PHP_SELF, all that jazz)

The one thing I don't like is now I have to hardcode that into each
place, unless I defined the fastcgi_pass location, and then just had a
php.conf - then all of this could be done with a single line of config
code.

set $fastcgi_pass = '127.0.0.1:11000';
include php.conf;

php.conf would have this:

location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
   fastcgi_pass $fastcgi_pass;
   fastcgi_param   SCRIPT_FILENAME  $document_root$script;
   fastcgi_param   PATH_INFO        $path_info;
   include fastcgi_params;
}

Would that be a workable solution Igor? Prior to this new style of PHP
handling I used to only need two lines:

fastcgi_pass 127.0.0.1:11000;
include fastcgi_params;

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

Re: Possible widespread PHP configuration issue - security risk

On Fri, Aug 27, 2010 at 11:41:38AM -0700, Michael Shadle wrote:

> On Fri, Aug 27, 2010 at 11:39 AM, Igor Sysoev <igor@sysoev.ru> wrote:
>
> >  location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
> >    fastcgi_pass 127.0.0.1:11000;
> >    fastcgi_param   SCRIPT_FILENAME  $script;
>
> Doesn't this typically have the $document_root$fastcgi_script_name -
> so the full system path?

You are right:

   fastcgi_param   SCRIPT_FILENAME  /path/to/files$script;

or

   fastcgi_param   SCRIPT_FILENAME  $document_root$script;

> Thanks for the pointers, though.
>
> I will begin adopting this style once I check it quick and pushing it
> on everyone I know...

This way saves one regex execution.
BTW, it's better for perfomance and configuration maintenance reasons
to isolate regex locaitons inside static ones as Maxim has shown:

location / {
  location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
...
}
...
}

location /dir1/ {
...
}

location /dir2/ {
  location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
...
}
...
}


--
Igor Sysoev
http://sysoev.ru/en/

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

Re: timer_resolution / $request_time

Is there anyway to get the request time in microseconds resolution in order to emulate Apache's %D log format option?
It looks like the only option at this time is to just fake it with something like "$request_time000" (since 1 millsecond = 1000 microsecond)

On Thu, Aug 26, 2010 at 6:59 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
Hello!

On Thu, Aug 26, 2010 at 11:23:47PM +0200, Xavier Martin wrote:

> Hello,
>
> I've been using this settings for a while:
> timer_resolution 100ms;
> log_format combined_time '$remote_addr - $remote_user [$time_local]  '
>                    '"$request" $status $body_bytes_sent '
>                    '"$http_referer" "$http_user_agent"'
>                    ' $request_time';
> access_log /var/log/access.log combined_time;
>
> Right now i'm needing more precise timestamp in logs
> => finding requests that took less than 50ms to complete.
>
> I would like to know what are the drawbacks of using a lower number
> (i.e 10ms, 0ms or not setting at all timer_resolution) and overhead that would cause (if any).

With timer_resolution unset (set to 0, default) nginx will call
gettimeofday() on every event loop iteration.  With
timer_resolution set nginx will schedule
gettimeofday() calls at specified interval.

Obviously changing it from 100ms to 10ms would cause 10 times
more gettimeofday() calls.  But most likely you won't notice.

But actually I would recommend using the default (i.e. unset).
It's not really different from 10ms on loaded servers and wouldn't
cause extra work on otherwise idle servers.

Maxim Dounin

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

Re: Possible widespread PHP configuration issue - security risk

On Fri, Aug 27, 2010 at 11:39 AM, Igor Sysoev <igor@sysoev.ru> wrote:

>  location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
>    fastcgi_pass 127.0.0.1:11000;
>    fastcgi_param   SCRIPT_FILENAME  $script;

Doesn't this typically have the $document_root$fastcgi_script_name -
so the full system path?

Thanks for the pointers, though.

I will begin adopting this style once I check it quick and pushing it
on everyone I know...

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

Re: Possible widespread PHP configuration issue - security risk

On Fri, 2010-08-27 at 11:15 -0700, Michael Shadle wrote:
> On Fri, Aug 27, 2010 at 11:13 AM, Cliff Wells <cliff@develix.com> wrote:
>
> > It is subtle, but all fixes are, because the underlying vulnerability is
> > quite subtle. What user isn't going to look at that and say to
> > themselves "why do I need this if statement?". Just use the try_files
> > and add a comment to its purpose.
>
> The caveat with try_files is it means nginx has filesystem access to
> check the existence of the file and an additional stat call (or more)
> - it can be in the open file cache, modern systems it's not a huge
> deal, etc, etc.
>
> But it won't help if you're fastcgi_pass to a remote server that nginx
> does not have the same path to the file (or have access to the php
> file) at all.

Good point. I do prefer your more general fix, although I'd like
confirmation that it does fully address the issue (the whole split_path
thing is too weird for me to want to try to understand).

Regards,
Cliff

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

Re: Possible widespread PHP configuration issue - security risk

On Fri, Aug 27, 2010 at 11:06:00AM -0700, Michael Shadle wrote:

> Let's stop debating and start with a clean fix. It sounds like this is
> all that is needed. Anyone want to verify?
>
> php config:
> cgi.fix_pathinfo=0
>
> then just make sure nginx splits the path info for you in case your
> app needs it with fastcgi_split_path_info:
> location ~ \.php$ {
> fastcgi_pass 127.0.0.1:11000;
> include fastcgi_params;
> fastcgi_split_path_info ^(.+\.php)(.*)$; # just throw this in
> fastcgi_params too, then!
> }
>
> Is this the right solution? Yes or no?

- location ~ \.php$ {
+ location ~ \.php {

BTW, in 0.8.x you may use

location ~ ^(?<script>.+\.php)(?<path_info>.*)$ {
fastcgi_pass 127.0.0.1:11000;
fastcgi_param SCRIPT_FILENAME $script;
fastcgi_param PATH_INFO $path_info;
include fastcgi_params;
}


--
Igor Sysoev
http://sysoev.ru/en/

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

Full Filename Directory Listing

I have a nginx server setup and everything is working fine. I have a
virtual server setup which allows directory listing (autoindex on;).

It appears to truncate the file names at around 50 characters.

Is it possible to disable this so that it will show the entire filename?
Or is there a way to increase it to say 100 or 150 characters?

Thanks!

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,124400,124400#msg-124400


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

Re: Possible widespread PHP configuration issue - security risk

On Fri, Aug 27, 2010 at 11:13 AM, Cliff Wells <cliff@develix.com> wrote:

> It is subtle, but all fixes are, because the underlying vulnerability is
> quite subtle.  What user isn't going to look at that and say to
> themselves "why do I need this if statement?".   Just use the try_files
> and add a comment to its purpose.

The caveat with try_files is it means nginx has filesystem access to
check the existence of the file and an additional stat call (or more)
- it can be in the open file cache, modern systems it's not a huge
deal, etc, etc.

But it won't help if you're fastcgi_pass to a remote server that nginx
does not have the same path to the file (or have access to the php
file) at all.

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

Re: Possible widespread PHP configuration issue - security risk

On Fri, 2010-08-27 at 18:48 +0100, Ed W wrote:
> On 27/08/2010 18:05, Cliff Wells wrote:
> > Nevertheless, I've updated the MediaWiki entry.
>
> I'm still having problems getting to the wiki - no .js files are loading
> which is causing some wierd stuff to happen.

I do not see any issues... does anyone else have a problem?

> However, my opinion is that just adding try_files is only a partial
> fix. If some way is found to upload .php files (bad wikipedia config)

I don't think we should try to overcome people's intentional
configuration. Not only is it completely their fault if they go
through the difficulty of enabling a feature that is off by default, but
now we are attempting to impose our will on a user who has made a
specific decision. This is always a bad road in software.

> or some other exploit is found that can bypass the try_files then we
> still have an issue.

Not going to worry about such speculative future issues. If such an
issue arises it will need to be addressed as an Nginx patch, not a
configuration option.

>
> My mediawiki config does this:
>
> location ~ .*.php$ {
> include /etc/nginx/fastcgi_params;
> if ( $uri !~ "^/images/") {
> fastcgi_pass localhost:9000;
> }
> }
>
> Others have already pointed out that we can do better than my IF.
> However, your try_files, plus the explicit exclusion of the /images/ dir
> go a long way to secure mediawiki. Also I think the specific exclusion
> of the /images/ dir becomes quite self-documenting, whereas the
> try_files is quite a subtle fix?

It is subtle, but all fixes are, because the underlying vulnerability is
quite subtle. What user isn't going to look at that and say to
themselves "why do I need this if statement?". Just use the try_files
and add a comment to its purpose.

Cliff


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