Tags:
create new tag
, view all tags

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:

  1. Complexity
  2. Certainty
  3. Speed of update
  4. 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?

Who Response
MartinCleaver Definitely
LynnwoodBrown Dito
JasonHill Yes
WillNorris Yes
DavidBright Yes

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. roll eyes (sarcastic)

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

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2008-08-08 - RafaelAlvarez
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.