Archive for the ‘Nginx’ category

My Nginx Configuration

March 14th, 2010

I’m creating this page on popular request, as I’ve had to paste my configuration for people a number of times especially on IRC. Below is an example configuration of how kbeezie.com is setup with some comments.

My primary nginx.conf file located in /conf

worker_processes     4;
 
events {
    worker_connections  1024;
}
 
http {
    # General Settings
    gzip  on;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay off;
    server_tokens off;
    include mime.types;
    keepalive_timeout 5;
    default_type  application/octet-stream;
 
    # If we set index here, we won't have to anywhere else
    index index.php index.html index.htm;
 
    # I prefer nginx to show the errors than "No Input Files Specified"
    # If you're using wordpress you want to turn this off so Wordpress
    # Shows the error. You can turn it off at the server or location level.
    # ONLY works if the server block has error pages defined for 4xx/5xx
    fastcgi_intercept_errors on;
 
    # We don't want someone to visit a default site via IP
    # So we catch all non-defined Hosts or blank hosts here
    server {
	server_name _;
	return 444; 
    }
    include sites-enabled/*;
}

A site configuration located inside the /conf/sites_enabled folder

# Wordpress Example
server {
	# The usual names, starting with the base, then www., subdomains or *. wild cards.
	server_name kbeezie.com www.kbeezie.com;
 
	# Keep a root path in the server level, this will help automatically fill
	# Information for stuff like FastCGI Parameters
	root html/kbeezie.com;
 
	# You can set access and error logs at http, server and location level
	# Likewise means you turn them off at specific locations
	access_log logs/kbeezie.access.log;
	error_log logs/kbeezie.error.log;
 
	# For my wordpress configuration, I prefer try_files
	# It will try for static file, folder, then falls back to index.php
	# The wordpress index.php is capable of parsing the URI automatically
	location / { try_files $uri $uri/ /index.php; }
 
	# Where I turned off intercept errors for WordPress
	fastcgi_intercept_errors off;
 
	# Includes my PHP location block and parameters
	include php;
 
	# My all in one settings to hide stuff like .invisible files
	# or turn off access/error logs to favicon/robots.txt
	include drop;
}
 
# Proxy_Pass example (backend server, or in my case Python App)
# For Python WSGI or Ruby/Rails you can check out 
# http://kbeezie.com/view/using-python-nginx-passenger/
 
server {
	# You can choose to turn remove this if you wish to
	# See requested URIs
	access_log off;
 
	# If your application returns any erorrs it can be logged by nginx
	# However if the application fails, or is not stated you'll see
	# 502 BAD GATEWAY
	error_log logs/python.error.log;
 
	# I usually run my apps from base domains or subdomains rather than
	# folders, though it is possible. 
	server_name apps.mydomain.com;
 
	# a root definition where you can store static files
	# if not served by the application
	root html/python-static/;
 
	# Since we have a static root defined, we can check
	# for static files there, otherwise goes to the backend
	location / { try_files $uri $uri/ @backend; }
 
	# The backend for either backend servers or apps
	location @backend {
		# Lets the app/backend know the visitor's IP
		# otherwise shows 127.0.0.1
		proxy_set_header  X-Real-IP  $remote_addr;
 
		# example on how to connect to a unix socket
		proxy_pass	http://unix:/opt/apps/ipn/ipn.sock:/;
 
		# Example via TCP location of the backend server
		# proxy_pass http://127.0.0.1:8008;
	}
 
	# you could copy drop into drop_deny to outright deny favicon and robots.txt for apps
	include drop;
}

A single file called php located in the /conf folder, using this method makes it easy to enable
php on a per-server basis.

# If you need PATH_INFO or PATH_TRANSLATED remove $ from end of ~ \.php$
location ~ \.php$ {
	fastcgi_split_path_info ^(.+\.php)(/.+)$;
 
	fastcgi_param  QUERY_STRING       $query_string;
	fastcgi_param  REQUEST_METHOD     $request_method;
	fastcgi_param  CONTENT_TYPE       $content_type;
	fastcgi_param  CONTENT_LENGTH     $content_length;
 
	fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
	fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
	fastcgi_param  REQUEST_URI        $request_uri;
	fastcgi_param  DOCUMENT_URI       $document_uri;
	fastcgi_param  DOCUMENT_ROOT      $document_root;
	fastcgi_param  SERVER_PROTOCOL    $server_protocol;
	fastcgi_param  PATH_INFO          $fastcgi_path_info;
	fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_path_info;
 
	fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
	fastcgi_param  SERVER_SOFTWARE    nginx;
 
	fastcgi_param  REMOTE_ADDR        $remote_addr;
	fastcgi_param  REMOTE_PORT        $remote_port;
	fastcgi_param  SERVER_ADDR        $server_addr;
	fastcgi_param  SERVER_PORT        $server_port;
	fastcgi_param  SERVER_NAME        $server_name;
 
	# I use a socket for php, tends to be faster
	# for TCP just use 127.0.0.1:port#
	fastcgi_pass   unix:/opt/php-fpm.sock;
 
	# Not normally needed for wordpress since you are
	# sending everything to index.php in try_files
	# this tells it to use index.php when the url
	# ends in a trailing slash such as domain.com/
	fastcgi_index  index.php;
}

A file called drop in the /conf folder, including this into your server configuration will drop/block
common files you do not wish to be exposed to the web.

# Most sites won't have configured favicon or robots.txt
# and since its always grabbed, turn it off in access log
# and turn off it's not-found error in the error log
location = /favicon.ico { access_log off; log_not_found off; }	
location = /robots.txt { access_log off; log_not_found off; }
 
# Rather than just denying .ht* in the config, why not deny
# access to all .invisible files 
location ~ /\. { deny  all; access_log off; log_not_found off; }

Further comments will be appended here.

Configuring SNI with NginX

December 28th, 2009

Traditionally for every SSL certificate issued, you needed a separate and unique IP address. However if you compile OpenSSL and NginX with TLS SNI (Server Name Identification) support you can install multiple SSL certificates without having to bind a domain name to a specific IP address or require each certificate to have its own unique IP.

First thing we need to do is actually compile OpenSSL with TLS SNI support. We’ll start by downloading the latest source and unpacking it into a temporary directory. For this article I keep all sources in ~/src.

$ cd ~/src
$ wget http://www.openssl.org/source/openssl-0.9.8l.tar.gz
$ tar zxvf ./openssl-0.9.8l.tar.gz
$ cd ./openssl-0.9.8l

We’ll then configure with TLS support:

$ ./config enable-tlsext
$ make
$ make install
$ cd ..

Assuming the Nginx source also resides in ~/src you can add the following option to your configure statement when compiling Nginx from source (you can also instead use an absolute path such as /root/src/openssl-0.9.8l/).

--with-openssl=../openssl-0.9.8l/

Once compiled and installed you can check to see if TLS SNI is enabled:

[root@host src]# nginx -V
nginx version: nginx/0.8.31
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-46)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx 
--add-module=/usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/ext/nginx 
--pid-path=/usr/local/nginx/logs/nginx.pid --sbin-path=/usr/local/sbin/nginx 
--with-md5=/usr/lib --with-sha1=/usr/lib --with-http_ssl_module 
--with-http_realip_module --with-http_gzip_static_module 
--with-openssl=/root/src/openssl-0.9.8l/

From there you will no longer be required to have an SSL enabled server block on it’s own unique IP. You won’t even have to have the block listening to a specific IP either since now OpenSSL will handle the certificate validation based on the server name.

Path_Info & PHP_SELF woes [NginX]

December 12th, 2009

Over the last couple of years I’ve been constantly researching for a way to get the PHP environment variables to show up correctly. My latest pains were with PATH_INFO and PHP_SELF, which are now finally solved.

My current configuration are PHP-FPM (5.2.10) and NginX (0.8.29) on a CentOS 5.4 x64 VPS.

Traditionally you would use a PHP configuration such as this:

	server {
		server_name  your-domain.com www.your-domain.com;
 
		location / {
			root html/default;
		}
 
		location ~ \.php$ {
			include fastcgi_params;
			fastcgi_param  SCRIPT_FILENAME  /usr/local/nginx/html/default$fastcgi_script_name;
			fastcgi_pass  127.0.0.1:9000;
		}
	}

Within fastcgi_params would be something like this:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
 
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
 
fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;
 
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;
 
# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

While the above method may seem to work at first, you’ll quickly notice problems when it comes to using $_SERVER['PATH_INFO'] and $_PATH['PATH_TRANSLATED'], and often enough $_SERVER['PHP_SELF'] ends up being set incorrectly when you try to adjust for the two environment variables.

Here is a setup I’ve come to prefer, especially when it comes to having multiple virtual hosts that use PHP. Notable tips are commented below the line.

Simple Nginx configuration file with a single virtual host

worker_processes  1;
pid        logs/nginx.pid;
events { worker_connections  1024; }
http {
	include       mime.types;
	default_type  application/octet-stream;
	sendfile        on;
	keepalive_timeout  65;
 
	index index.html index.htm index.php;
	# Identical to Apache's DirectoryIndex, setting it in
	# the http block set it as a default for all server blocks within
 
	server {
		listen	80; 
		# since port 80 is set by default, you do not actually need
		# to set this, unless of course you are binding to a specific
		# address such as listen server-ip-address:80 or alternate port; 
 
		server_name  gyn0.com www.gyn0.com;
 
		root   html/default;
		# You will want to set your root here, since otherwise
		# $document_root within the php block will not work
		# if you set it in the location block you would also have 
		# to set the php block within that location as well
 
		location / {
			# Below are some wordpress-friendly rewrite rules
			if (-f $request_filename) {
				expires 30d;
				break;
			}
 
			if (!-e $request_filename) {   			
				rewrite ^/.+/?(/wp-.*) $1 last;
				rewrite ^/.+/?(/.*\.php)$ $1 last;
				rewrite ^/(.+)$ /index.php?q=$1 last;
			}
		}
 
		location = /favicon.ico { access_log off; log_not_found off; }
		# If you haven't created a favicon for your site, you can keep
		# your access and error logs clean by turning off the logs
		# when a browser requests the fav icon (its also a good way
		# to keep your logs from filling with useless information)
 
		include php;
		# I prefer to keep my php settings in one file, so I can simply
		# paste this single line for each of my virtual hosts
	}
}

Now the php file (which I’ve created in the /conf folder with nginx.conf)

fastcgi_intercept_errors on;
# this will allow Nginx to intercept 4xx/5xx error codes
# Nginx will only intercept if there are error page rules defined
# -- This is better placed in the http {} block as a default
# -- so that in the case of wordpress, you can turn it off specifically
# -- in that virtual host's server block
 
location ~ \.php {
	fastcgi_split_path_info ^(.+\.php)(/.+)$;
	# A handy function that became available in 0.7.31 that breaks down 
	# The path information based on the provided regex expression
	# This is handy for requests such as file.php/some/paths/here/ 
 
	include fastcgi_params;
	# Includes the modified fastcgi parameter file (see below)
 
	fastcgi_pass   127.0.0.1:9000;
	fastcgi_index  index.php;
}

The new modified fastcgi_params:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;
 
fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
#SCRIPT_NAME needs to remain without the document_root on front
#Otherwise PHP_SELF breaks, the interpreter will still find the file
#because of the added SCRIPT_FILENAME parameter below
 
fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
#This one was added right into the file, since with root moved, and path_info split
#It should no longer need to be set manually for each virtual host
 
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
 
#the two lines below are possible now because of the fastcgi_split_path_info function
fastcgi_param  PATH_INFO          $fastcgi_path_info;
fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_path_info;
 
fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;
# I removed the version, as not to give away too much information
 
fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;
 
#PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

There you have it, PHP should now have correct environment variables. For example http://www.kbeezie.com/php.php/a/path/string/?var=foo would render the following results (the url above doesn’t actually work, sorry :P ):

$_SERVER["QUERY_STRING"] -> var=foo
$_SERVER["SCRIPT_NAME"] -> /php.php
$_SERVER["SCRIPT_FILENAME"] -> /usr/local/nginx/html/default/php.php
$_SERVER["REQUEST_URI"] -> /php.php/a/path/string/?var=foo
$_SERVER["DOCUMENT_URI"] -> /php.php/a/path/string/
$_SERVER["DOCUMENT_ROOT"] -> /usr/local/nginx/html/default
$_SERVER["PATH_INFO"] -> /a/path/string/
$_SERVER["PATH_TRANSLATED"] -> /usr/local/nginx/html/default/a/path/string
$_SERVER["PHP_SELF"] -> /php.php/a/path/string/

So there you have it. A simple php block that will correctly assign the path environment variables, without having to use multiple blocks and patterns. And quite easy to simply assign to a new virtual host by simply pasting the include php; line.

Using Namecheap’s Free SSL with Nginx

November 21st, 2009

Most of my domains are registered with Namecheap, and powered by Nginx. The site you are viewing now is one such example. Currently with Namecheap, domain registrations, hosting, transfers and WhoIS protection come with a free PositiveSSL subscription (course even if they eventually stop that special, 9.95/year is still a good price for a PositiveSSL certificate). This section will show you how to generate a certificate request with OpenSSL and how to install the provided certificate into Nginx.

Most hosting providers that allow you to install a SSL certificate will normally be using a Cpanel/WHM setup with the Apache Webserver. In which case SSL installation can be quite and visually straight forward, as its pretty much cut and paste back an forth. While you don’t get this luxery with Nginx, its not that difficult to configure.

What you will need on the server:

A unique IP address. The domain you are getting the certificate for does not have the be the only domain served on the chosen IP address. However Nginx will only serve one certificate per IP. An attempt to install two certificates on the same IP will result in the latter domain serving the previous domain’s certificate.

SSH access. Otherwise known as ’shell access’, would be required to perform most of the tasks yourself. If you have installed Nginx onto a remote server yourself, then chances are you have shell access. Also if you’re running Nginx you’re not likely using shared hosting, which is normally void of shell access.

OpenSSL In order to actually generate a request and serve the certificate you will need OpenSSL installed. Using a repository such as yum on CentOS you can install this with the package openssl and openssl-devel (depending on the repository the package names could vary).

Nginx webserver configured with SSL. In order for Nginx to serve SSL certificates, Nginx must be built with the option –with-http_ssl_module. To verify you can run nginx -V from the terminal to see all the options your current release was built with. If you installed Nginx from a repository, you may need to see if there exists a SSL variation. KBeezie.com is currently running on Nginx 0.8 and hosted by KnownHost.

Assuming you have all the above in place, we can start by creating private key followed by the CSR file otherwise known as a Certificate Signing Request.

Nginx and Django

September 14th, 2009

In a previous guide I showed how to use Passenger (aka mod_rails) to work with Python (WSGI) scripts. While this proved effective for simple wsgi applications, a framework such as Django required a bit more love. This guide assume you already have everything installed from the previous guide, and that Python has already been configured with Django and other modules.

Aside from having the usual setup, you will need the original Django source files. One way of going about this is downloading the latest source from the Django Project. The next couple of steps assume you have nginx installed at the /usr/local/nginx/ location, and already have a src folder under your home folder.

# cd ~/src
# wget http://www.djangoproject.com/download/
# tar zxvf Django-1.1.tar.gz
# cd Django-1.1
# mv ./django /usr/local/nginx/html

I should note, my /html/ folder isn’t publicly accessible because all my sites are subfolders under that location. I use it primarily to store resources for the folders beneath it. You can change where you save the source, just remember where you put it and that the webserver has access to it.

Open up your nginx configuration where you have already setup a passenger app from the previous guide. Should look something like this.

server {
	server_name project.domain.com;
	root /usr/local/nginx/html/project.domain.com/public/;
	passenger_enabled on;
}

The first thing you have to do to set this up for Django (at the very least), is to modify the server block above to something more like this:

server {
	server_name project.domain.com;
 
	location / {
		root /usr/local/nginx/html/project.domain.com/public/;
		passenger_enabled on;
	}
 
	location /media {
		alias /usr/local/nginx/html/django/contrib/admin/media;
	}
}

Now you have either create or move your django application into the site folder. For example, if your site is defined as /usr/local/nginx/html/project.domain.com like above, and your django application is called mytest , you will end up having it located in /usr/local/nginx/html/project.domain.com/mytest. In the end you should have a folder structure similar to this (based off the Django tutorials).

Directory Structure

Now open up the passenger_wsgi.py from the previous guide which may look something like this:

import sys
import os
 
def application(environ, start_response):
	start_response("200 OK", [])
	ret = ["%s: %s\n" % (key, value)
		for key, value in environ.iteritems()]
	return ret

We’re going to turn this into a WSGI initializer for the Django application like so:

import os, sys
 
#automatically finds application's current path
nginx_configuration= os.path.dirname(__file__)
project = os.path.dirname(nginx_configuration)
workspace = os.path.dirname(project)
sys.path.append(workspace) 
 
os.environ['DJANGO_SETTINGS_MODULE'] = 'testapp.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

After saving, should restart the nginx server, then load up the site in a browser. If this is a new Django application you’ll be greeted with a “Welcome to Django” page, otherwise the application you had already created.

Static content can be access by creating additional Aliases in Nginx, or by using django.views.static.serve method in your applications url settings.

Using Python with Nginx via Passenger

September 14th, 2009

Since Nginx 0.6.* I been looking for an effective way to run Python (WSGI) applications thru the Nginx Webserver. A couple of options were available at the time:

Apache + mod_wsgi
One possible solution was to run Apache as a backend server listening on 127.0.0.1:8080 (or a port of your choice), which could also be easily used to serve up other dynamic content such as php. Many have used this setup for a great deal of internal load balancing, letting Nginx serve strictly static content, and Apache to handle the dynamic content.

In the sense of a WSGI Python application, you would have a server block like this in Nginx:

server {
	#server_name is what nginx responds to
	server_name  mydomain.com www.mydomain.com;
 
	location / {
		#setting a Host header is handy if you have apache
		#setup with name-based virtual hosts
		proxy_set_header Host mydomain.com;
 
		#requires nginx to be compiled with --with-http_realip_module
		proxy_set_header X-Real-IP $remote_addr;
 
		#This can also be the IP address of another server
		proxy_pass http://127.0.0.1:8080;
	}
}

With the above method you could go with the easy route of having mod_wsgi (as of this writing, mod_wsgi is available at 2.5 supporting Python 2.6) installed via Apache. However doubling up the number of webservers run, might defeat the purpose of running Nginx for some of us, especially for those less familiar with Apache configuration.

Nginx WSGI Module

There was a port of Apache’s mod_wsgi over to Nginx by Manlio Perillo. However this module had only been tested on Nginx 0.5.34, and patched for 0.6.*.

However even when patched, the module remained quite buggy. Implementing this module went something like this:

In the http { } block

    wsgi_python_optimize 0;
    wsgi_enable_subinterpreters on;

In your server { } block

server {
	listen 80;
	server_name yourdomain.com;
 
        location / {
            wsgi_pass  /var/www/username/domain/application.wsgi;
 
            include wsgi_vars;
 
            wsgi_var  SCRIPT_NAME         /var/www/username/domain/application.wsgi;
            wsgi_var  DOCUMENT_ROOT       /var/www/username/domain;
 
            wsgi_pass_authorization off;
            wsgi_script_reloading on;
            wsgi_use_main_interpreter on;
        }
}

This module is no longer maintained and is does not to build on modern versions of Nginx (0.7/0.8), and was barely compatible with 0.6 by using a patch. The creator of the Apache mod_wsgi, Graham Dumpleton commented on his blog regarding the Nginx implementation:


The nginx version of mod_wsgi borrows some code from my original Apache version, but obviously since the internals of Apache and nginx are very different, the main parts of the code which interface with the web server are unique. Although I condoned use of the source code, I do wish I had insisted from the outset that it not be called mod_wsgi due to the confusion that has at times arisen.

Although development on the nginx version of mod_wsgi appears to no longer be happening, this isn’t stopping people from using it and many are quite happy with it. The question is whether they really understand anything about how nginx works and the shortcomings in how nginx and mod_wsgi work together.

Admittedly the author of the mod_wsgi module for nginx has been up front in pointing out that because nginx is asynchronous, and with WSGI not designed for such a system, that once the WSGI application is entered all other activity by the web server is blocked. The recommendation resulting from this is that static files should not be served from the same web server. Use of multiple nginx worker processes is also suggested as a way of mitigating the problem.

Source: Graham Dumpleton: Blocking requests and nginx version of mod_wsgi

There is however a far more practical solution fit for production use, especially for those using modern versions of Nginx.