Sharing Install Files Between Sites
I host several sites on the same account in a hosting provider account. I want to share whatever files I can between the installs for many reasons:
- Complexity
- Certainty
- Speed of update
- Minimise diskusage requirements
Sharing mechanisms
- Symlinks (files, directories): lndir
- Configuration files (setlib.cfg)
- point to a new path
- point to a series of paths
Share candidates
- bin/
- CGI files in here can be shared, but .htaccess cannot. That said, these files seldom change now that the bulk of the functionality has been moved to lib/TWiki/UI.
- Experimentation showed that symlinking these does not work
- data/
- TWiki
- Most files in the TWiki web can be shared and made readonly, relieving the admin of having to make updates. However TWikiPreferences can be shared if the Main.TWikiPreferences file is used to override it. See SeparateSiteSpecificTWikiConfiguration
- Probably just symlink this
- TWiki does not yet have a mechanism to put webs in different places
- pub/
- TWiki
- Probably just symlink this
- lib/
- create the lib dir
- lndir the TWiki dir
- Possible to use setlib.cfg to provide a series of paths for lib/TWiki/Plugins, lib/TWiki/Contrib, but TWiki admin instructions make out that you can unzip a TWikiExtension - this assumption would break if a path was used instead
- templates/
As subdirs are used for webs, lndir is probably the least messy.
Don't share candidates
- data/Main, data/People, data/Trash, data/Sandbox,
- pub/Main, pub/People, pub/Trash, pub/Sandbox
- lib/TWiki/Plugins, lib/TWiki/Contrib
- templates/*/*.tmpl
--
MartinCleaver - 20,24 Dec 2004
Questions
Are you interested in sharing install files between sites?
Do you currently successfully share install files between sites?
| Who |
Configuration |
Does it work? |
Improvements wanted |
| MartinCleaver |
|
I get weird errors - see http://mbawiki.com/twiki/bin/view/TWiki |
| LynnwoodBrown |
One domain with full TWiki installation; Other domains have TWiki installations in which the bin, template, lib/TWiki, and lib/Algorithm directories are symlinked. TWiki.cfg and TWiki pm files are distinct for each installation. |
It works OK. |
Making it simplier would be nice. |
| AllenBierbaum |
One "common" directory with current installation. One directory for each domain with pub and data directories. Using SERVER_NAME method (see below). |
It works great |
Making this more integrated would be nice |
A few additional comments on my set-up:
- For a while I even shared the data/Main directory and the htpasswd file. This meant if someone signed up on one site, they were signed up for both. It worked ok but actually confused me so I split them back apart.
- I can't remember why I didn't symlink the TWiki.pm file. Seems like one could.
- I have had trouble remembering which files were real in each installation and which were linked. Documenting my work would help.
A few thoughts on what would help
SharingInstallFilesBetweenSites:
- Having all site-specific config files (i.e. bin/htaccess, TWiki.cfg) separate from directories that could be linked. I don't know how you could do this with the bin directory - maybe have all the scripts in a sub-directory?
- I would love to see some kind of interface that would list which file are linked.
--
LynnwoodBrown - 04 Jan 2005
Here's another promising approach to
SharingInstallFilesBetweenSites:
http://twiki.org/cgi-bin/rdiff/Codev/TWikiOnDebian?rev1=1.91&rev2=1.90
--
LynnwoodBrown - 22 Apr 2005
This untaint is now in TWiki.pm (
SVN 4102).
--
MartinCleaver - 25 Apr 2005
I am very happy that I found this wonderful topic. I have been looking for a way to do this for a very long time. I now have everything setup and running successfully using the approach above with SERVER_NAME.
My TWiki.cfg file now looks like...
$defaultUrlHost = $ENV{SCRIPT_URI};
$defaultUrlHost =~ s/(https?:\/\/[\w\.]*)\/.*/$1/;
$pubDir = "/home/httpd/twiki/" . $ENV{SERVER_NAME} . "/pub";
$templateDir = "/home/httpd/twiki/common/templates";
$dataDir = "/home/httpd/twiki/" . $ENV{SERVER_NAME} . "/data";
$logDir = "$dataDir";
you can see above that I extended the idea a little and used SCRIPT_URI to get the full host URL. I needed this because some of my sites use SSL and some do not (ie. some have https and some just http).
--
AllenBierbaum - 23 Nov 2005
Well, I looked at this page and used part of the above solution as well as a little of my own. I have several different domains which I wanted to be managed by a single instance of TWiki. Previously I had seperate instances of TWiki and this was a maintenance nightmare during upgrades. I even tried symlinking /bin and parts of /lib but that too was a nightmare, also because of upgrades.
From the above, I only used:
$TWiki::cfg{DefaultUrlHost} = 'http://' . $ENV{SERVER_NAME};
leaving everything else the same in
lib/LocalSite.cfg. I decided to try having all my domains use a single TWiki web and Main Web and setting each webs WebPreferences file making each web non-shared.
One of my requirements was that every web viewed via a given domain used a domain specific template. Obviously setting SKIN wouldn't work since that is web specific (or TWiki specific) and not domain specific. So my solution was to edit my Apache httpd.conf file and add the following line to my <VirtualHost ... > specification setting a global environmental variable called
skin using:
SetEnv skin MyTemplateName
So each VirtualHost specifier had its own
skin setting.
Since I'm running TWiki 4.0.4.2, I then edited the file
lib/TWiki.pm and in the subroutine
getSkin I changed the line of:
my $skinpath = $this->{prefs}->getPreferencesValue( 'SKIN' ) || '';
to the following:
my $skinpath = $ENV{skin} || $this->{prefs}->getPreferencesValue( 'SKIN' ) || "";
which looks for the domain specific global environmental variable and uses that if found. Otherwise it uses the normal TWiki mechanism which is to use the skin defined in a webs WebPreferences file or the global TWikiPreferences file.
Of course I then had to create domain specific templates (i.e. create the file
templates/view.MyTemplateName.tmpl).
So far this seems to be working great.
--
TaitCyrus - 27 Jul 2006
Goog approach, Cyrus. And thanks for sharing this. We can/should improve TWiki so that it is easier to share a TWiki among sites. To make it less prone to errors, it is better to give the env variables specific names, such as twikiSKIN or the like.
--
PeterThoeny - 28 Jul 2006
Good suggestion Peter. I went ahead and changed the environmental variable to be
TWikiSKIN. One additional change I had to make was to
lib/LocalSite.cfg. I was getting errors when I nightly ran
mailnotify as a result that
$ENV{SERVER_NAME} was not defined so I added a new line at the very top of
lib/LocalSite.cfg which looks like:
$ENV{SERVER_NAME} = "aDomainName" if (!defined($ENV{SERVER_NAME}));
where
aDomainName was one of the domains managed by the TWiki. Not only does this remove the warning about an undefined variable, it also makes sure that the URLs included in the email about web changes are accurate (without this new line the URLs are invalid as they don't contain the web sites server name).
--
TaitCyrus - 04 Aug 2006