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:
- repository for topic text, change log.
- globally writeable due to lack of setuid
- general look and feel, links.
- cache for rendered topics. globally writeable.
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/:
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 index.html /cgi-bin/view.pl/FrontPage
Similarly, for .../htdocs/files/, you could include this line in .htaccess:
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 ScriptAlias and mod_rewrite tricks. There, I have a directory structure like this:
- scripts and config
ScriptAlias /wiki/bin/ <...>/wiki/bin/
- file upload area
Alias /wiki <...>/wiki/web
ScriptAlias must precede the base
Alias, so that it takes precedence.
- Templates used to generate pages.
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.
# 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,
$baseUrl could both be simply
/wiki, and mod_rewrite will decide whether to serve content directly from the cache, or call the view script.
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. There is some overhead to this, but it is approximately the same overhead as calling a CGI script.
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