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/mod_passenger.so 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 PassengerPreStart https://golem.ph.utexas.edu/wiki/web_list PassengerDefaultRuby /path/to/ruby21
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>
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.
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.