First Question

I am considering setting up TWiki on a server which will serve two different communities. Reading the documentation I gather that I could use a single TWiki installation and make two Wiki Webs. However, will that mean that these two webs will share a common user-base and that I cannot have different users with the same name etc?

I also do not want to end up installing the whole twiki stuff twice if i can avoid it.

Any hints on how to have one Twiki installation run two separate Twiki sites (on the same apache server, potentially with two virtual incarnations) would be appreciated. .

• TWiki version:
• Web server: apache-1.3.26
• Server OS: Linux
• Web browser:
• Client OS:

-- MathiasKoerber - 27 Aug 2002

Second Question

I am also running multiple Wiki's on the same server, and my issue has a slightly different twist. I have 4-5 Wiki's set up (the themes are too varied to permit the use of Webs in a single Wiki), and they have some common users, and some different. Authentication is via a single .htpasswd and single .htgroups, and only those listed in the appropriate groups can gain access to their Wiki's. This works well, but leads to two problems.

Manual addition of new users to groups

Even if the Twiki user registration form is used, I have to manually add the person to the appropriate group. This can be fixed with some perl-foo in the registration form, so it's not a big deal.

Some Wiki's don't have User entries for users

Since a user can register in Wiki A and later be added (via the Apache group file) to Wiki B, they won't have a User page in Wiki B (no preferences, etc.). This is more of a problem, as educating many users on the creation of a personal preferences page from scratch is too much of an admin load.

Second Question Summary

Is there a better way to do this? I'd love to be able to use just Webs in a single Twiki instance, but I can't hide topics from search or certain topics from display depending on which user you are, and I'm unsure of the security within Twiki to keep areas separate. Is there some way to do a "hidden from this user but not that one"? Some guidance would be greatly appreciated.

-- RalphBroom - 01 Sep 2004

First Answer

You can have two whole wiki sites, but you must duplicate the whole twiki stuff But then the user bas will be different.

Note that you cannot even do that if you use mod_perl. Tu use mod_perl, you must have one use mod_perl, and the other either another apache instance, or speedy for fastcgi.

If you do not use mod_perl, then you can have as much TWiki instances as you want, just install them in different dirs.

-- ColasNahaboo - 28 Aug 2002

Here's a TOTALLY UNTESTED script that will set up a second installation based on an existing one using softlinks. I present it here as an illustration of what you probably have to do to create a second installation that shares code with an existing installation. Use it at your own risk. Caveat emptor. If you are able to make it work successfully and reliably, please post your experiences back to the Codev web.

It doesn't set anything up in Apache - that's your problem. Be especially concious of Options Followsymlinks.

#!/bin/sh

ORIGINAL=/home/twiki1
NEW=/home/twiki2

mkdir $NEW

echo "Linking bin directories; assumes .htpasswd will be shared between installations if using basic auth"
ln -s $ORIGINAL/bin $NEW/bin
if [ -d $ORIGINAL/contrib ]; then
   echo "Linking contrib directories"
   ln -s $ORIGINAL/contrib $NEW/contrib
fi
echo "Linking templates; assumes skins are shared"
ln -s $ORIGINAL/templates $NEW/templates

mkdir $NEW/data
mkdir $NEW/pub
echo "Note: Linking TWiki web assumes plugins are shared"
ln -s $ORIGINAL/data/TWiki $NEW/data/TWiki
ln -s $ORIGINAL/pub/TWiki $NEW/pub/TWiki
ln -s $ORIGINAL/data/_default $NEW/data/_default
echo "Note: Assuming Trash and Sandbox are shared"
ln -s $ORIGINAL/data/Trash $NEW/data/Trash
ln -s $ORIGINAL/pub/Trash $NEW/pub/Trash
ln -s $ORIGINAL/data/Sandbox $NEW/data/Sandbox
ln -s $ORIGINAL/pub/Sandbox $NEW/pub/Sandbox
echo "Initialising new TWiki's userbase from old twiki"
cp -R $ORIGINAL/data/Main $NEW/data
cp -R $ORIGINAL/pub/Main $NEW/pub
ln -s $ORIGINAL/pub/icn $NEW/pub/icn
ln -s $ORIGINAL/pub/favicon.ico $NEW/pub/faviocn.ico
ln -s $ORIGINAL/pub/wikiHome.gif $NEW/pub/wikiHome.gif

mkdir $NEW/lib
ln -s $ORIGINAL/lib/TWiki $NEW/lib/TWiki
ln -s $ORIGINAL/lib/Algorithm $NEW/lib/Algorithm
ln -s $ORIGINAL/lib/Text $NEW/lib/Text
ln -s $ORIGINAL/lib/TWiki.pm $NEW/lib/TWiki.pm
echo "Deriving new TWiki.cfg from the old one"
sed -e "s.$ORIGINAL.$NEW.g" $ORIGINAL/lib/TWiki.cfg > $NEW/lib/TWiki.cfg
echo "NOTE: FIX THE URL PATHS IN $NEW/TWiki.cfg"

echo "Now fix your server configuration to point at the derived installation"

I'm about to try out CrawfordCurrie's solution on a FreeBSD box I run. My preference is to install TWiki from /usr/ports/www/twiki/ and I am concerned because that port says that it is Important that one only does an initial installation from the port, and that upgrades be handled manually.

While the issue of upgrading TWiki that is installed via the ports system is beyond the scope of this topic, I am curious about what, if anything, special needs to be done when upgrading a TWiki installation that uses the mechanism described here.

-- HarlanStenn - 21 May 2006