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.


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. Under Passenger 5.0.x, you need to be running 5.0.7 or later. Earlier version of Passenger 5 had troubles with Instiki.

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 5.0.7 (and Ruby 2.1). The configuration consisted of adding

LoadModule passenger_module /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.7/buildout/apache2/
PassengerRoot /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.7
PassengerDataBufferDir /tmp
PassengerInstanceRegistryDir /tmp
PassengerUserSwitching on
PassengerMinInstances 2
PassengerMaxInstancesPerApp 6
PassengerMaxPoolSize  12
AllowEncodedSlashes On
PassengerBaseURI /wiki

PassengerDefaultRuby /path/to/ruby21

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
   PassengerAllowEncodedSlashes on

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.


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/ --user $USER --group $GROUP -d -p 80"

for the previous value, and replace the

 runuser $USER -c "$PROC"

line with one that says, simply,


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.