You can make changes to this topic using the edit box below. If you decide that you want to quit without saving your changes then use the back button on your browser.
=== Basic Installation === The basic way to install SpinnerWiki is to copy it into your cgi-bin. If the Wiki is all you'll be serving (e.g. on the SpinnerWiki 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 DirectoryIndex 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 FrontPage 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 ScriptAlias 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, SpinnerWiki 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 SpinnerWiki 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% ---- [1: http://www.unixpapa.com/mod_auth_external.html]