Yet Another Personal Homepage

Navigation

Yet Another Personal Homepage - nginx and textpattern - All noise, no signal

nginx and textpattern

2010-02-21 , Technical , R. Lonstein

I run a lean combination of os, webserver and cms on my VPS- NetBSD, Nginx and Textpattern- and it seems to be a fairly uncommon one, judging from the few results in google. That’s not a bad thing, but it does mean rolling your own.

To get a current build of ngix, it’s necessary to build it yourself or out of pkgsrc/wip. Since nginx keeps cgi and php at arms length, I use spawn-fastcgi to run a pool of php interpreters. This is also trivial to build. I slapped together a basic spawn-fcgi rc file and start both nginx and the pool like any other service.

My core nginx.conf looks like this:

user   nginx  nginx;
worker_processes  2;
events {
    worker_connections  512;
}
http {
    include       /usr/pkg/etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    error_log   /var/log/nginx/error.log notice;
    rewrite_log on; # rewrite shows up in error.log at level 'notice',
                    # turn this off unless debugging to avoid bloated logs

    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     off;

    keepalive_timeout  45 20;
    keepalive_requests 25;

    gzip               on;
    gzip_http_version  1.0;
    gzip_comp_level    2;
    gzip_min_length    1100;
    gzip_buffers       4 8k;
    # gzip always compresses "text/html", others that benefit...
    gzip_types         text/plain text/xml text/css text/javascript
                       application/x-javascript application/xml application/xml+rss;

    server {
        listen       80;
        server_name  localhost;
        location / {
            root   share/examples/nginx/html;
            index  index.html index.htm;
        }
    }

    include /usr/pkg/etc/nginx/virtual-othersite.conf;
}

Configuration of nginx is straight-forward if you accept “messy” urls (i.e. http://www.example.com/foo/index.php) but everyone prefers “clean” urls and that gets into rewrite rules. I haven’t found any for Textpattern (that work with clean urls, anyway) so I came up with my own. The virtual site configuration contains these rewrite rules for textpattern and the fastcgi handling:

server {
    listen 80;
    server_name www.othersite.com;
    root /var/www/othersite.com;
    index index.html index.php;

    location / {
        # rewrite all requests to the maint page
        # if it exists...
        #
        if (-f $document_root/maintenance.html) {
            rewrite  ^(.*)$  /maintenance.html last;
            break;
        }

        # rewrites for textpattern locations... somewhat brittle, relies
        # on knowledge of the args
        #
        if (!-e $request_filename) {
            rewrite ^/(favicon.ico|robots.txt) @404 break;
            rewrite ^/archive(.*)$             /index.php?s=archive$1 last;
            rewrite ^/about.*$                 /index.php?s=about last;
           # enable the next rule during setup, then disable...
           # rewrite ^/textpattern/setup/(.*)$  /textpattern/setup/index.php$1 last;
            rewrite ^/textpattern(.*)$         /textpattern/index.php$1 last;
            rewrite ^/                         /index.php;
        }
    }

    location ~ \.php$ {
        try_files $uri @404;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }

    location @404 {
        return 404;
        break;
    }

    # cache static files
    location ~ ^/(images|javascript|stylesheet)/ {
        expires 1d;
    }
}

These rules appear to work with the exception of in-line commenting, which redirects to the article. Pop-up comments, since they use a full url, work as expected. The 404 handling is to short-circuit having the fastcgi processes handle common known bad requests.

Comment