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 preferred).

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 2.2.5. The configuration consisted of adding

 LoadModule passenger_module /path/to/gems/1.8/gems/passenger-2.2.5/ext/apache2/mod_passenger.so
 PassengerRoot /path/to/gems/1.8/gems/passenger-2.2.5
 PassengerRuby /path/to/ruby1.8
 RailsBaseURI /wiki

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
     XSendFileAllowAbove on
   </IfModule>
 </Location>

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 80” flag.

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.