Nerd Talk

If you’re working on nginx configuration and you can’t start or reload it because you’re getting an error like this:

nginx: [emerg] unknown directive "if(-f" in /etc/nginx/nginx.conf:67
nginx: configuration file /etc/nginx/nginx.conf test failed

You need to make sure that the “if” and the “(” are separated with a space:

# will cause syntax error
if(-f $document_root/$uri.php) {
   rewrite ^(.*) $1.php last;
}
 
# this is correct
# notice the space between "if" and "("
if (-f $document_root/$uri.php) {
   rewrite ^(.*) $1.php last;
}

That should fix the issue and you should be able to start/reload nginx successfully.
As a programmer I tend to assume that “if(-f … )” will work because in essence it’s a valid syntax for if statements. For nginx, you should play by its rules because you’ll get a bunch of these errors if you don’t.

Nerd Talk

I remember when we setup an Apache web server to move from Lighttpd, after we installed PHP we just copied over the same php.ini file to use the same settings. During testing I had a problem with sessions not persisting between pages, it was a pain to realize the problem at first. The cause of the issue is with the session.save_path, since we just copied over the old php.ini file, the folder path set to where the session should be saved is, well, not existing. I created the folder, the session folder, set write permissions and sessions are flying across pages!
You can find the session.save_path directive in /etc/php.ini and check out where sessions are saved, ex:

session.save_path = "/var/lib/php/session"

I believe it’s not the best practice to set 0777 (means everyone can read/write) permissions for the sessions folder as other users of the server may be able to hijack session files so be careful on this.

Literally, this is the song that played on my head when things started to work. It’s one of my childhood anime song. Watch and listen to this!

I’m eating bacon and rice for breakfast right now, btw. Just saying ;p

Nerd Talk

I recently fixed an issue in the server that’s related to lighttpd 404 handler. The problem is when a URL is accessed with weird characters lighttpd returns a 404 page. For example, you saw something like this in your page views log and it returned a 404 error:

http://agyuku.net/%C2%A0

The example above results to “http://agyuku.net ” in the browser and returns Page Not Found. Notice the space after .net. The weird character “%C2%A0” is translated by the browser as a space but the server actually sees it as something else. Adding a space after the domain doesn’t really cause the server to react and treat it as a missing page. A solution that should do the work is to add a rewrite rule in lighttpd’s conf file:

"(.+?)(%C2%A0)$" => "$1"

The regular expression matches the weird characters at the end of the URL. When lighttpd receives a page request it will only read the URL without the weird stuff. $1 is a back reference to the regular expression pattern which means use those that matches the first pattern, in this case it’s (.+?). This should actually work but there’s a case due to different server settings, this may not solve the issue as lighttpd doesn’t see “%C2%A0″ as-is when the URL is accessed, it may be something else.

If the above method didn’t work then enabling lighttpd’s debug variables will give a clue to the issue. The debug variables are disabled by default, somewhere in lighttpd.conf set these to be enabled:

debug.log-request-header   = "enable"
debug.log-response-header  = "enable"
debug.log-request-handling = "enable"
debug.log-file-not-found   = "enable"

Once those are set save lighttpd.conf and restart the server. Access the URL with weird characters in the browser to trigger the error and it should write something in the server’s error log. Do a tail to the error log to check the last reported error:

tail -n 150 /path/to/your/error.log

The command above displays the last 150 lines in the error log. Check the displayed errors and there should be something like:

(response.c.221) -- splitting Request-URI
(response.c.222) Request-URI  :  /%C2%A0
(response.c.223) URI-scheme   :  http
(response.c.224) URI-authority:  agyuku.net
(response.c.225) URI-path     :  /%C2%A0
(response.c.226) URI-query    :
(response.c.254) -- sanatising URI
(response.c.255) URI-path     :  /Â
(mod_access.c.135) -- mod_access_uri_handler called
(response.c.391) -- before doc_root
(response.c.392) Doc-Root     : /some/document/root/path
(response.c.393) Rel-Path     : /Â
(response.c.394) Path         :
(response.c.442) -- after doc_root
(response.c.443) Doc-Root     : /some/document/root/path
(response.c.444) Rel-Path     : /Â
(response.c.445) Path         : /some/document/root/path/Â
(response.c.462) -- logical -> physical
(response.c.463) Doc-Root     : /some/document/root/path
(response.c.464) Rel-Path     : /Â
(response.c.465) Path         : /some/document/root/path/Â
(response.c.482) -- handling physical path
(response.c.483) Path         : /some/document/root/path/Â
(response.c.539) -- file not found
(response.c.540) Path         : /some/document/root/path/Â

Notice /%C2%A0 translated as /Â. The browser converts the weird characters as a space but the server treated it differently and converted it to “”. A 404 response is sent by the server because it’s trying to find /some/document/root/path/ which doesn’t exist. We will use the findings above to fix the issue, modify the URL rewrite to something like:

"(.+?)(%C2%A0|Â)$" => "$1"

The pattern now includes the weird character in the URL (just to be sure we handle it as well) and the one that the server see internally (the “”). Save lighttpd and restart the server. Access the URL and it should load up the page without an error.

The above scenario is something I experienced and may be different from issues you may have but I hope it helps someone. And wow, it’s 4 in the morning, I should get some sleep.

More on lighttpd debug variables here.
I used http://agyuku.net an example domain only and it’s not running in lighttpd, it runs in Apache.

Quick Tip

Copy files from an SVN folder to another location and excludes all .svn folders. This copies files from the source to destination recursively, -r.

rsync -r --exclude=.svn /path/to/source /path/to/destination

More about rsync here.

This happened last night while at the office waiting for some uploads to finish I was playing around with my Ubuntu (11.04) box when I got this CRAZY art using Firefox. I remember the old days when I used to get this all the time when using IE6.