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. 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
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> PassengerAllowEncodedSlashes on </Location>
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
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
directive to the
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).
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,
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.