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.
On Tue, Aug 31, 2010 at 12:18:13AM -0400, syle wrote:
fastcgi_param GEOIP_LONGITUDE $geoip_longitude;
to forget to replace fastcgi_params file afterwards.
Could you test following patch against current version of
ports/www/nginx-devel ?
On Tue, Aug 31, 2010 at 12:18:13AM -0400, syle wrote:
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.
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.
On Tue, Aug 31, 2010 at 10:58:23AM -0400, syle wrote:
fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
}
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.
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;
On Tue, Aug 31, 2010 at 11:38:38AM -0400, syle wrote:
listen [::]:80; #bind to ipv6
fastcgi_param SCRIPT_FILENAME
---- 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.
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:
$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;
}
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.
This really sucks. It’d be MUCH better if you could simply inherit the
fastcgi_param. I’ve now come across this a bunch of times with
different projects. It’d be nice for example to pass DEBUG 1 or DEBUG 0
to the fastcgi handler.
The documentation makes sense after you read it a bunch of times, but at
first read, it makes it seem like you can inherit portions of
fastcgi_param.
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
perhaps maybe can suggest a way to move these
perhaps maybe can suggest a way to move these