Instiki
Run on Port 80

By default, Instiki runs on Port 2500. For many purposes, it’s nice to be able to dispense with the “:2500” appended to the hostname in all of your URLs. That means running on Port 80.

Passenger

Far-and-away the best solution for running on Port 80 is to run Instiki under Passenger. Passenger is easy to install, and most Rails-friendly hosting services have already done so. You’ll need version 2.1.2 or later (2.2.3 or later is preferred, and 2.2.8 or later is required for Ruby 1.9).

The one caveat is that running under Passenger will require you to migrate your database to MySQL. The default SQLite3 database is not really designed for multiple Instiki processes (as happens, when you run under Passenger) accessing the database simultaneously.

This site is running on Passenger 3.0.0 (and Ruby 1.9). The configuration consisted of adding

 LoadModule passenger_module /path/to/gems/1.9.1/gems/passenger-3.0.0/ext/apache2/mod_passenger.so
 PassengerRoot /path/to/gems/1.9.1/gems/passenger-3.0.0
 PassengerRuby /path/to/ruby19
 PassengerUseGlobalQueue on
 RailsBaseURI /wiki
 AllowEncodedSlashes On

to the httpd.conf file and, to enable X-Sendfile support,

 <Location /wiki>
   <IfModule mod_xsendfile.c>
     RequestHeader Set X-Sendfile-Type X-Sendfile
     XSendFile on
     XSendFilePath /path/to/wiki/webs
     XSendFilePath /path/to/wiki/storage
   </IfModule>
   PassengerAllowEncodedSlashes on
 </Location>

The “PassengerAllowEncodedSlashes on” allows one to use characters like ‘+’ in page names, just as one is able to do using Mongrel/WEBrick. It’s not fully compatible with Apache’s mod_rewrite, so you may not want to turn it on globally. The Apache directive, “AllowEncodedSlashes On” is more aptly-named. It (when accompanied by “PassengerAllowEncodedSlashes on”) allows you to also use “/” in page names.

The latter set of directives can be sent in the httpd.conf file (as I did), or in Instiki’s public/.htaccess file, if Apache’s

AllowOverride Options

is set for this location.

On MacOSX 10.6 (but not 10.5), I found that I got an

Unexpected error in mod_passenger: An error occured while
buffering HTTP upload data to a temporary file in ... The
current Apache worker process (which is running as www)
doesn't have permissions to write to this directory. ...

error when uploading files or saving a long wiki page. I gather this happens on other operating systems as well. The solution is to add a

PassengerUploadBufferDir /tmp

directive to the httpd.conf file.

Proxying

The next most flexible solution is to Proxy via Apache or lighttpd. You only get one backend Instiki process this way (so it’s OK to keep using SQLite3).

Listen on Port 80

But if your entire site consists of Instiki, then running a separate webserver and proxying all the connections may seem like overkill.

The more direct approach is simply to have Instiki listen on Port 80 instead of 2500. To do that, you start up Instiki with the “-p 80flag.

There’s a fly in that ointment, though. Port 80 is a privileged port, and if you want Instiki to bind to Port 80, you need to run it as root. That sort of conflicts with my other advice to run Instiki as an unprivileged user. What you need is for Instiki to bind to Port 80, but then “drop privileges”, and run as an unprivileged user, thereafter.

The current Rails/Rack combination is not set up to do that. But Mongrel is capable of it. You just have to bypass Rack, and envoke Mongrel directly. In the Linux startup script that I suggested, you would substitute

 PROC="mongrel_rails start -c $DIR -e production -P $DIR/tmp/pids/server.pid --user $USER --group $GROUP -d -p 80"

for the previous value, and replace the

 runuser $USER -c "$PROC"

line with one that says, simply,

 $PROC

The other drawback is that you can’t use X-Sendfile to offload the handling of uploaded files to the webserver. Instiki has to handle that, itself, delaying the handling of other requests. Still, for a lightly-trafficked site (or one without any uploaded files), that tradeoff may be acceptable.