Installing Spinner Wiki

Spinner Wiki

 SourceForge.net Logo

Basic Installation

The basic way to install Spinner Wiki is to copy it into your cgi-bin. If the Wiki is all you'll be serving (e.g. on the Spinner Wiki demonstration site) you can just put it in the root of cgi-bin. This can be done even without administrative priviledges, e.g. on SourceForge. On the demo site I have the following layout:

  • .../text
    • repository for topic text, change log.
    • globally writeable due to lack of setuid
  • .../templates
    • general look and feel, links.
    • read-only
  • .../html
    • cache for rendered topics. globally writeable.
  • .../cgi-bin/
    • scripts and config
  • .../htdocs/images
    • icons
  • .../htdocs/files
    • file upload repository

Although, without administrative access, SourceForge does not allow the use of mod_rewrite to enable nicer URLs (see below), it does allow an .htaccess file to contain Directory Index directives. You can take advantage of this to get a poor man's interal redirect. Here is a simple .htaccess for .../htdocs/:
  DirectoryIndex index.html /cgi-bin/view.pl/FrontPage
This says to show Front Page from the Wiki for this directory (and all directories below, unless they have an index.html or their own .htaccess with DirectoryIndex).

Similarly, for .../htdocs/files/, you could include this line in .htaccess:
  DirectoryIndex /cgi-bin/upload.pl
The default wiki.cfg, included in the spinner-wiki tarball, assumes that something like this has been done.

A little fancier

On another site, I have everything under the /wiki URI. Scripts are under /wiki/bin, files are under /wiki/files, and Wiki topics are right under /wiki. This is supported by some ScriptAliasNew Page and mod_rewrite tricks. There, I have a directory structure like this:

  • .../wiki/bin
    • scripts and config
    • ScriptAlias /wiki/bin/ <...>/wiki/bin/
  • .../wiki/web/images
    • icons
  • .../wiki/web/files
    • file upload area
    • Alias /wiki <...>/wiki/web
    • The ScriptAlias must precede the base Alias, so that it takes precedence.
  • .../wiki/templates
    • Templates used to generate pages.
  • .../wiki/text
    • topic content
  • .../wiki/html
    • rendered topic cache

mod_rewrite rules can be used to reduce the CGI overhead so that calls are not made for most page views; and at the same time present friendlier URLs.

  RewriteEngine on
# For cached pages, just display the cached files
# (this rule knows where the wiki.cfg says the pages are cached)
RewriteCond <...>/wiki/html/$1.htm -f
RewriteRule ^/wiki/([A-Z][^/]*)$ <...>/wiki/html/$1.htm

# For the pages that are not yet cached, use CGI
RewriteRule ^/wiki/([A-Z][^/]*)$ /wiki/bin/view.pl/$1 [R]

By using mod_rewrite as shown above, I am able to have URLs like http://<hostname>/wiki/SpinnerWiki, while improving performance at the same time.

On that configuration with mod_rewrite, I also have DirectoryIndex FrontPage in my <Directory .../wiki/web> section. This works in conjuction with the rewrite rules. On "configuration one", as deployed on the demo site, I can't use mod_rewrite but I do have DirectoryIndex /cgi-bin/view.pl/FrontPage in my top-level .htaccess file, to provide a friendlier starting point. In both cases I have the DirectoryIndex for the files folder pointing at upload.pl.

If you have administrative access but don't want to use mod_rewrite, you could get the some of the same convenience without the performance boost, using Redirect rules.

Once you have decided on a directory structure, you also need to update the config file, to tell it where to look for the files. See wiki.cfg in the same directory with the CGI scripts. This is actually just a Perl script fragment, separated out to make it easier to edit. There are detailed comments for all of the configuration parameters.

If you use mod_rewrite rules like the ones above, $htmlUrl and $baseUrl could both be simply /wiki, and mod_rewrite will decide whether to serve content directly from the cache, or call the view script.

Authentication

Before deciding whether to configure authentication for your Wiki, please remember that a basic principle of Wiki is read / write access for everyone. There are situations where it's appropriate to restrict access to a Wiki (e.g. an internal discussion forum). I see this as just redefining what we mean by "everyone", and I hold to my assertion that, on a Wiki, everyone who can read the topic should have the right to improve upon it. (If you disagree with this opinion, Spinner Wiki can probably support your requirement, but you may need to do some slight restructuring, e.g. moving the edit and save scripts to a subdirectory, with stricter access controls.)

If you set up basic authentication for the URI (e.g. for .../htdocs and .../cgi-bin in example 1 - naming the same realm for each - or for the .../wiki directory in example 2), the user will be prompted for a password before they are granted access. What's more, for authenticated users, the change log will show the authenticated username rather than <unknown user>.

You can also restrict access by IP, e.g. to an Intranet.

See your Apache manual / other web server documentation for information on how to set up authentication.

If you want to experiment with custom authentication schemes, e.g. against a database or whatever, rather than using the standard password file format supported by Apache, take a look at mod_auth_external[1]. There is some overhead to this, but it is approximately the same overhead as calling a CGI script.

mod_perl

I have not attempted to run Spinner Wiki under mod_perl. I would be interested in knowing whether that works / what changes are required to support it. If you try this, please let me know how it turns out.

Related pages: Unclassified

This page last edited on 1 January 2004 at 01:34 GMT