r43 - 31 Jan 2003 - 07:15:25 - PeterThoeny?You are here: TWiki >  TWiki Web  > TWikiDocumentation

TWiki Reference Manual (TWiki-4.0.5, Tue, 24 Oct 2006, build 11822)

This page contains all documentation topics as one long, complete reference sheet.
Doubleclick anywhere to return to the top of the page.

Note: Read the most up to date version of this document at http://TWiki.org/cgi-bin/view/TWiki/TWikiDocumentation

Related Topics: TWikiSite, TWikiHistory, TWikiPlannedFeatures, TWikiEnhancementRequests


1 TWiki System Requirements

Server and client requirements

Low client and server base requirements are core features that keep TWiki widely deployable, particularly across a range of browser platforms and versions. Many Plugins and contrib modules exist which enhance and expand TWiki's capabilities; they may have additional requirements.

Server Requirements

TWiki is written in Perl 5, uses a number of shell commands, and requires RCS (Revision Control System), a GNU Free Software package. TWiki is developed in a basic Linux/Apache environment. It also works with Microsoft Windows, and should have no problem on any other platform that meets the requirements.

Resource Required Server Environment *
Perl 5.005_03 or higher (5.8.4 or higher is recommended)
RCS 5.7 or higher (including GNU diff)
Optional, TWiki includes a pure perl implementation of RCS that can be used instead (although it's slower)
GNU diff GNU diff 2.7 or higher is required when not using the all-Perl RcsLite.
Install on PATH if not included with RCS (check version with diff -v)
Must be the version used by RCS, to avoid problems with binary attachments - RCS may have hard-coded path to diff
GNU patch For upgrades only: GNU patch is required when using the TWiki:Codev.UpgradeTWiki script
Other external programs fgrep, egrep
Cron/scheduler • Unix: cron
• Windows: cron equivalents
Web server Apache is well supported; see TWiki:TWiki.InstallingTWiki#OtherWebServers for other servers

Required CPAN Modules

The following Perl modules are used by TWiki:
Module Preferred version
Algorithm::Diff (included)  
CGI::Carp >=1.26
Config >=0
Cwd >=3.05
Data::Dumper >=2.121
Error (included)  
File::Copy >=2.06
File::Find >=1.05
File::Spec >=3.05
File::Temp (included with perl 5.6 and later)
FileHandle >=2.01
IO::File >=1.10
Text::Diff (included)  
Time::Local >=1.11

Optional CPAN Modules

The following Perl modules may be used by TWiki:
Module Preferred version Description
CGI::Cookie >=1.24 Used for session support
CGI::Session >=3.95 Used for session support
Digest::base    
Digest::SHA1    
Jcode   Used for I18N support with perl 5.6
Locale::Maketext::Lexicon >=0 Used for I18N support
Net::SMTP >=2.29 Used for sending mail
Unicode::Map   Used for I18N support with perl 5.6
Unicode::Map8   Used for I18N support with perl 5.6
Unicode::MapUTF8   Used for I18N support with perl 5.6
Unicode::String   Used for I18N support with perl 5.6
URI   Used for configure

Most of them will probably already be available in your installation. You can check version numbers with the configure script, or if you're still trying to get to that point, check from the command line like this:

perl -e 'use FileHandle; print $FileHandle::VERSION."\n"'

Client Requirements

The TWiki standard installation has relatively low browser requirements:

  • HTML 3.2 compliant
  • Cookies, if persistent sessions are required

CSS and Javascript are used in most skins, although there is a low-fat skin (Classic skin) available that minimises these requirements. Some skins will require more recent releases of browsers. The default skin (Pattern) is tested on IE 6, Safari, and Mozilla 5.0 based browsers (such as Firefox).

You can easily select a balance of browser capability versus look and feel. Try the installed skins at TWikiSkinBrowser and more at TWiki:Plugins.SkinPackage.

Important note about TWiki Plugins

  • Plugins can require just about anything - browser-specific functions, stylesheets (CSS), Java applets, cookies, specific Perl modules,... - check the individual Plugin specs.
    • TIP Note: Plugins included in the TWiki distribution do not add requirements, except for the CommentPlugin which requires Perl 5.6.1.

Related Topics: AdminDocumentationCategory


2 TWiki Installation Guide

Installation instructions for the TWiki 4.0 production release.

If you are upgrading from a previous version of TWiki, you probably want to read TWikiUpgradeGuide instead.

TWiki should be fine with any web server and OS that meet the system requirements. The following installation instructions are written for experienced system administrators; please review the AdminSkillsAssumptions before you install TWiki. If you need help, ask a question in the TWiki:Support web or on TWiki:Codev.TWikiIRC (irc.freenode.net, channel #twiki)

HELP Hint: TWiki:TWiki.InstallingTWiki on TWiki.org has supplemental documentation that help you install TWiki on different platforms, environments and web hosting sites.

Basic Installation

  1. Download the TWiki distribution from http://TWiki.org/download.html.
  2. Make a directory for the installation and unpack the distribution in it.
  3. Make sure the user that runs CGI scripts on your system can read and write all files in the distribution.
    Detailed instructions on file permissions are beyond the scope of this guide, but in general:
    • During installation and configuration, the CGI user needs to be able to read and write everything in the distribution,
    • Once installation and configuration is complete, the CGI user needs write access to everything under the data and pub directories and to lib/LocalSite.cfg. Everything else should be read-only.
    • Everybody else should be denied access to everything, always.
  4. Make sure Perl 5 and the Perl CGI library are installed on your system.
    The default location of Perl is /usr/bin/perl. If it's somewhere else, change the path to Perl in the first line of each script in the twiki/bin directory.
    HELP Some systems require a special extension on perl scripts (e.g. .cgi or .pl). If necessary, rename all files in twiki/bin (i.e. rename view to view.pl etc). If you do this, make sure you set the ScriptSuffix option in configure (Step 6).
  5. Create the file /twiki/bin/LocalLib.cfg.
    There is a template for this file in /twiki/bin/LocalLib.cfg.txt.
    The file must contain a setting for $twikiLibPath, which must point to the absolute file path of your twiki/lib e.g. /home/httpd/twiki/lib.
    HELP If you need to install additional CPAN modules, but can't update the main Perl installation files on the server, you can set $CPANBASE to point to your personal CPAN install. Don't forget that the webserver user has to be able to read those files as well.
  6. Configure the webserver so you can execute the bin/configure script from your browser.
    • Explicit instructions for doing this are beyond the scope of this document, though there is a lot of advice on TWiki.org covering different configurations of webserver. To help you out, there's an example Apache httpd.conf file in twiki_httpd_conf.txt at the root of the package. This file also contains advice on securing your installation. There's also a script called tools/rewriteshebang.pl to help you in fixing up the shebang lines in your CGI scripts.
  7. Run the configure script from your browser, and resolve any errors or warnings it tells you about.
You now have a basic, unauthenticated installation running. At this point you can just point your Web browser at http://yourdomain.com/twiki/bin/view and start TWiki-ing away!

Next Steps

Once you have your TWiki running, you can move on to customise it for your users.

Troubleshooting

  • The first step is to re-run the configure script and make sure you have resolved all errors, and are happy that you understand any warnings.
  • TWiki:TWiki.InstallingTWiki on TWiki.org has supplemental documentation that help you install TWiki on different platforms, environments and web hosting sites.
  • If you need help, ask a question in the TWiki:Support web or on TWiki:Codev.TWikiIRC (irc.freenode.net, channel #twiki)


Warning: Can't find topic TWiki.WindowsInstallCookbook


3 TWiki Upgrade Guide

Upgrade from the previous TWiki 01-Sep-2004 Prodcution Release to TWiki-4.0.0

Overview

TWiki-4.0.0 is a major new release. You can chose between an automated upgrade using a script or a manual update.

Upgrade Requirements

  • Please review the AdminSkillsAssumptions before you upgrade TWiki
  • Review TWiki:TWiki.TWikiUpgradeTo04x00x00 for latest information and experience notes.
  • To upgrade from a release prior to TWiki Release 01-Sep-2004, start with TWiki:TWiki.UpgradingTWiki on TWiki.org
  • To upgrade from a standard TWiki Release 01-Sep-2004 to the latest TWiki-4.0.0 Production Release, follow the instructions below
  • Once the upgrade has been applied, an existing earlier installation will still be able to read all the topics, but should not be used to write. Make sure you take a backup!
  • Not all Plugins written for TWiki Release 01-Sep-2004 are fully supported with Dakar. Make sure the Plugins you use can be upgraded as well!

Major Changes Compared to TWiki Release 01-Sep-2004

See TWikiReleaseNotes04x00.

Automated Upgrade Procedure

If you would prefer to do things manually, or if you made custom modifications to distributed files (except topics), then skip to the manual upgrade procedure below.

The upgrade script is called "UpgradeTwiki", and is found in the root of the distribution. It can be run by any user, though you will need to make sure you correct the permissions so that the webserver user can write all files in the new installation when you have finished. The upgrade script does not write to your existing installation.

The upgrade script will upgrade the TWiki core only. Plugins will need to be upgraded separately.

Note: To upgrade from a Beta, do not use UpgradeTWiki. Instead follow the steps outlined in Upgrading a Beta, below.

It will:

  • Create a new TWiki installation, placing the files from the distribution there as appropriate
  • Where possible, merge the changes you've made in your existing topics and attachments into the new twiki
  • Where not possible, it will tell you, and you can inspect those differences manually
  • Create new configuration files for the new TWiki based on your existing configuation information
  • Set the permissions in the new TWiki so that it should work straight away
  • Attempt to setup authentication for your new TWiki, if you are using .htaccess in the old one
  • Tell you what else you need to do

To perform the upgrade, you need to:

  • Check first if there is a newer UpgradeTwiki script available, see TWiki:Codev.UpgradeTWiki
  • Create a new directory for your new installation: Let's call this distro/
  • Put the distribution zip file in distro/
  • Unzip it
  • Choose a directory for the new installation. I will call this new_twiki. This directory must not already exist.
  • Change directory to distro/ and run:
    ./UpgradeTwiki <full path to existing_twiki's setlib.cfg> <full path to new_twiki>
  • confirm your system settings by pointing your browser to the configure script

Assuming all goes well, UpgradeTwiki will give you the final instructions.

Visit TWiki:Codev.KnownIssuesOfTWiki04x00x00 and fix known issues that apply to you.

There are a few points worth noting:

  • UpgradeTwiki may not be able to merge all the changes you made in your existing TWiki into the new installation, but it will tell you which ones it couldn't deal with
  • UpgradeTwiki creates the new installation in a new directory tree. It makes a complete copy of all your existing data, so:
    • Clearly you need to point it to a location where there is enough space
    • If you have symlinks under your data/ directory in your existing installation, these are reproduced as actual directories in the new structure. It is up to you to pull these sub-directories out again and re-symlink as needed
  • UpgradeTwiki doesn't deal with custom templates or Plugins, you will have to reinstall these in the new installation.
  • If you are using the Htpasswd login manager, then note that email addresses for users have moved out of user topics and into the password database. There is a script that performs this extra upgrade step for you - see tools/upgrade_emails.pl.

Manual Upgrade Procedure

The following steps are a rough guide to upgrading only. It is impossible to give detailed instructions, as what you have to do may depend on whether you can configure the webserver or not, and how much you have changed distributed files in your current TWiki release.

  1. Follow the installation instructions, and install the new release in a new directory.
  2. Copy your local webs over to the data and pub directories of the new install
    • You could also use softlinks to link the web directories in data and pub to the old installation area
  3. Unlock the rcs files in data and pub directories from the old installation using the following shell commands:
    • find data -name '*,v' -exec rcs -r -u -M '{}' \;
    • find pub -name '*,v' -exec rcs -r -u -M '{}' \;
  4. Examine your old TWiki.cfg, and for each local setting, set the corresponding value in the configure interface for the new install.
    • If you can't use configure, then copy the new TWiki.cfg to LocalSite.cfg, and edit LocalSite.cfg. Remove all the settings that you didn't change in your previous install, and change the remaining settings to the values from your old TWiki.cfg.
  5. Transfer any customized and local settings from TWiki.TWikiPreferences to the topic pointed at by {LocalSitePreferences} (Main.TWikiPreferences). This avoids having to write over files in the distribution.
  6. If you changed any of the topics in the original TWiki distribution, you will have to transfer your changes to the new install manually. There is no simple way to do this, though the following procedure may help:
    1. Install a copy of the original TWiki release you were using in a temporary directory
    2. Use 'diff' to find changed files, and transfer the changes into the new Dakar install.
    3. Install updated plugins into your new area.
  7. Point your webserver at the new install.
  8. Visit TWiki:Codev.KnownIssuesOfTWiki04x00x00 and fix known issues that apply to you.
  9. If you are using the Htpasswd login manager, then note that email addresses for users have moved out of user topics and into the password database. There is a script that performs this extra upgrade step for you - see tools/upgrade_emails.pl.

You are highly recommended not to change any distributed files if you can avoid it, to simplify future upgrades!

Upgrading a Beta

If you followed the recommendations and avoided modifying any distributed files, then this is quite straightforward:
  1. Follow the installation instructions, and install the new release in a new directory.
  2. Copy your local webs over to the data and pub directories of the new install
    • Be careful to copy over the user topics and TWikiUsers?.txt in the Main web
  3. Copy over your bin/LocalLib.cfg and lib/LocalSite.cfg files
  4. Copy over any local files you created (such as .htpasswd and .htaccess files)
  5. Point your webserver at the new install.
If you changed any of the distributed files, you will have to continue from Step 5 above.

Upgrading from Cairo to TWiki4 (additional advice)

Favicon

TWiki4's PatternSkin introduces the use of the favicon feature which most browsers use to show a small icon in front of the URL and for bookmarks.

In TWiki4 it is assumed that each web has a favicon.ico file attached to the WebPreferences topic. When you upgrade from Cairo to TWiki4 you do not have this file and you will get flooded with errors the error log of your web server. There are two solutions to this.

  • Attach a favicon.ico file to WebPreferences in each web.
  • Change the setting of the location of favicon.ico in TWikiPreferences so all webs use the favicon.ico from the TWiki web. This is the fastest and easiest solution.

To change the location of favicon.ico in TWikiPreferences to the TWiki web add this line to TWikiPreferences

   * Set FAVICON = %PUBURLPATH%/%TWIKIWEB%/%WEBPREFSTOPIC%/favicon.ico


4 TWiki User Authentication

TWiki site access control and user activity tracking options

Overview

Authentication, or "login", is the process by which a user lets TWiki know who they are.

Authentication isn't just to do with access control. TWiki uses authentication to identify users, so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of shadows.

TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or only for changes. Authentication is also essential for access control.

Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:

TWiki user authentication is split into three sections; password management, user registration, and login management. Password management deals with how users are recognised (authenticated). Registration deals with how new users are added to the wiki. Login management deals with how users log in.

Once a user is logged on, they are remembered using a "session id" stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.

Please note FileAttachments are not protected by TWiki User Authentication.

TIP Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.

Password Management

As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the configure interface for more details.

New User Registration

New user registration uses the password manager to set and change passwords. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).

The registration process is responsible for creating user topics.

Login Management

Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.

You can select your chosen login through the Security Settings pane in the configure interface.

No Login (select none in configure)

Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.

ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.

Template Login (select TWiki::Client::TemplateLogin in configure)

Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out.

Enabling Template Login

  1. Use the configure interface to
    1. select the TWiki::Client::TemplateLogin login manager (on the Security Settings pane).
    2. select the appropriate password manager for your system, or provide your own.
  2. Register yourself in the TWikiRegistration topic.
    HELP Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  3. Create a new topic to check if authentication works.
  4. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
    ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls.

TWikiAccessControl has more information on setting up access controls.

ALERT! At this time TWikiAccessControls cannot control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up in the webserver to allow open access you may want to add .htaccess files in there to restrict access.

TIP You can create a custom version of the TWikiRegistration form by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.

TIP You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics

Apache Login (select TWiki::Client::ApacheLogin in configure)

Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.

The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules such as mod_auth_ldap or mod_auth_mysql you can just plug in directly to them.

The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.

TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).

The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support. This allows the TWiki registration support to maintain usernames and passwords.

Warning: Do not use the Apache htpasswd program with .htpasswd files generated by TWiki! htpasswd wipes out email addresses that TWiki plants in the info fields of this file.

Enabling Apache Login using mod_auth

You can use any other Apache authentication module that sets REMOTE_USER.
  1. Use configure to select the TWiki::Client::ApacheLogin login manager.
  2. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  3. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
    ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
  4. You can create a custom version of TWikiRegistration by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.
    You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
  5. Register yourself in the TWikiRegistration topic.
    HELP Check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
  6. Create a new topic to check if authentication works.
  7. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
    ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls.
TWikiAccessControl has more information on setting up access controls.

Logons via bin/logon

Any time a user enters a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.

The bin/logon script accomplishes this. The bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. However, once authenticated, it will simply redirect the user to the view URL for the page from which the logon script was linked.

Sessions

TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions using cookies. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address. See How to choose an authentication method for a discussion of the pros and cons of the various authentication methods.

There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.

Getting, Setting, and Clearing Session Variables

You can get, set, and clear session variables from within TWiki web pages or by using script parameters. This allows you to use the session as a personal "persistent memory space" that is not lost until the web browser is closed. Also note that if a session variable has the same name as a TWiki preference, the session variables value takes precedence over the TWiki preference. This allows for per-session preferences.

To make use of these features, use the tags:

%SESSION_VARIABLE{ "varName" }%
%SESSION_VARIABLE{ "varName" set="varValue" }%
%SESSION_VARIABLE{ "varName" clear="" }%

Note that you cannot override access controls preferences this way.

Cookies and Transparent Session IDs

TWiki normally uses cookies to store session information on a client computer. Cookies are a common way to pass session information from client to server. TWiki cookies simply hold a unique session identifier that is used to look up a database of session information on the TWiki server.

For a number of reasons, it may not be possible to use cookies. In this case, TWiki has a fallback mechanism; it will automatically rewrite every internal URL it sees on pages being generated to one that also passes session information.

TWiki Username vs. Login Username

This section applies only if you are using authentication with existing login names (i.e. mapping from login names to WikiNames).

TWiki internally manages two usernames: Login Username and TWiki Username.

  • Login Username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.

  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.

TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.

NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for example Main.WikiUsername or %MAINWEB%.WikiUsername. This points WikiUsername to the Main web, where user home pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic? everywhere but in the Main web.

Changing Passwords

If your {PasswordManager} supports password changing,