I have never been forced to create a patch. However, its certainly a good skill to have and would have likely helped me when I submitted a bug to Vsftpd’s maintainer. Tonight I needed to create a patch and google provided the answer.

$ diff -Naur olddir newdir > new-patch
- or -
$ diff -Naur oldfile newfile >new-patch

Here is a quick example I cooked up:

$ mkdir prepatch
$ nano -w prepatch/test
$ cat prepatch/test
BASH
Cancer
$ cp -R prepatch/ postpatch
$ nano -w postpatch/test
$ diff -Naur prepatch/ postpatch/ > patch
$ cat patch
diff -Naur prepatch/test postpatch/test
--- prepatch/test       2008-02-11 23:15:46.000000000 -0600
+++ postpatch/test      2008-02-11 23:16:15.000000000 -0600
@@ -1,2 +1,3 @@
 BASH
+Cures
 Cancer
$ cp -R prepatch/ testpatch
$ cd testpatch/
$ patch -p1 < ../patch
patching file test
$ cat test
BASH
Cures
Cancer

If your interested on why I had to create a patch, read on. Otherwise you may be interested in an older post 10 Steps to Beautiful Shell Scripts.

I consult for Idologic on the weekends. Idologic like many website hosting companies use suPHP to run client’s php scripts as the user who owns the file. Meaning if user A owns a virtual host php scripts executed as user A. When using mod_php, the script is executed as the user running the web server, i.e. nobody.

suPHP is a good solution. However, there is a cost as it creates a new process for every php page request. In order to help reduce this cost, Telena Internet Services wrote a patch for Apache 2, called the Peruser MPM, which creates a httpd process and performs a setuid() to the configured user. This then handles the current request and afterwards is available to process future requests. After a certain configurable period of inactivity, the process is killed. For busy sites, this significantly reduces the number of process the web server has to create, which can improve performance, if configured correctly.

Beyond performance, suPHP is separate from Apache and must be built and configured correctly, creating extra work.

I am a member of the mailing list and admin’s using this patch have complained of intermittent segmentation faults. As with any new patch there are problems. The easiest way to troubleshoot this is to turn on core dumping. The Apache directive CoreDumpDirectory does exactly this. (The kernel by default disables core dumps after setuid() operations, “echo 1 > /proc/sys/fs/suid_dumpable” enables them by default.)

However, after the peruser’s setuid sys call, the CoreDumpDirectory directive was not being respected. I decided to fix this:

The modified patch for a vanilla 2.2.3 and as such includes the peruser 0.3.0 patch.

The patch against a patched version of 2.2.3.