Summary
I am considering a service of Foswiki hosting, where I will maintain a single Foswiki installation and each customer has its own set of webs, in a way that each customer would have its own Virtual Host. At every request, depending of the hostname used, would expose a different wiki system. In such a setup we'll have things that we'll want to share between all virtual hosts, and will not want to share other things.
Things you'll want to share between virtual hosts:
- the entire Foswiki infra-structure
- the
System
web
- most of the configuration
Things you won't want to share between virtual hosts:
- users
- webs, except
System
- some configuration
Possible implementations
I tried this one as a proof of concept, and it "works" (not tested throughly, though). It consists of two parts:
1) change in the configuration loading
diff --git a/lib/Foswiki/Configure/Load.pm b/lib/Foswiki/Configure/Load.pm
index a331bb0..7070e51 100644
--- a/lib/Foswiki/Configure/Load.pm
+++ b/lib/Foswiki/Configure/Load.pm
@@ -16,6 +16,26 @@ package Foswiki::Configure::Load;
our $TRUE = 1;
+
+=begin TML
+
+---++ StaticMethod configFiles()
+
+Determines which configuration files Foswiki is going to use.
+
+=cut
+
+sub configFiles {
+ my @config = (
+ 'LocalSite.cfg'
+ );
+
+ my $host = 'localhost'; # <= HERE we should determine which virtual host we are in.
+ push @config, "LocalSite-$host.cfg";
+
+ return @config;
+}
+
=begin TML
---++ StaticMethod readConfig()
@@ -52,14 +72,16 @@ GOLLYGOSH
}
# Read LocalSite.cfg
- unless ( do 'LocalSite.cfg' ) {
- die <<GOLLYGOSH;
+ for my $config (configFiles()) {
+ unless ( do($config) ) {
+ die <<GOLLYGOSH;
Content-type: text/plain
Perl error when reading LocalSite.cfg: $@
Please inform the site admin.
GOLLYGOSH
- exit 1;
+ exit 1;
+ }
}
# If we got this far without definitions for key variables, then
2) custom config file for each virtual host, overriding the settings I need to override for the given virtual host. What I have here is the following in
lib/LocalSite-localhost.cfg
:
# vim: ft=perl
$Foswiki::cfg{PubDir} = '/home/terceiro/src/foswiki/core/vhosts/localhost/pub';
$Foswiki::cfg{DataDir} = '/home/terceiro/src/foswiki/core/vhosts/localhost/data';
$Foswiki::cfg{WorkingDir} = '/home/terceiro/src/foswiki/core/vhosts/localhost/working';
This approach has the drawback of only working with the CGI engine, unless we configure different instances of FastCGI/!ModPerl/HTTP Engine for each virtual host. This would probably going to be overkill, i.e. if I have 10 customers running 10 different Foswiki instances I would block a lot of resources (memory, mainly) that will be idle for most of the time.
Others?
...
--
AntonioTerceiro - 05 Aug 2009
Discussion
I would like to hear from everyone interested on this.
--
AntonioTerceiro - 05 Aug 2009
Sharing
System
might arise some more problems: Some plugin (most of the old ones) have their configuration on the plugin topic in the System web. Some skins can be customized by editing topics in
System
. Your virtual foswikis cannot differ in those aspects.
--
OliverKrueger - 05 Aug 2009
This is a very interesting initiative! Many people face this issue: maintain multiple foswiki setups on the same host. It would be wonderful to make this task easier!
--
GilmarSantosJr - 07 Aug 2009
I have also worked on code to do this, though on
TmWiki - in my code, the users are stored in a database, and they can invite users into their webs, with a quota management system and other bells. unhappily, the
TmWikiNet crap happened and so I stopped work on it.
Wrt shared System web - yes, the topics are shared, but you can enable/disable the plugins on a per-web basis.
I was wondering if we (the Foswiki Community) would like to set up such a system at
fosiki.net
.
--
SvenDowideit - 07 Aug 2009
I like the idea a lot.
Can you explain why your approach fails on fastcgi?
What about plugins? Is there a problem of the sort of harming the stability of
all wiki spaces just by enabling one specific plugin for one client? I guess so.
--
MichaelDaum - 07 Aug 2009
Michael: it would only work with CGI because the configuration is loaded during starup/compilation, and with FastCGI this happens only once, when the
FastCGI process starts; what we need in such a case is to have a different configuration for each request depending on the hostname that is being accessed.
--
AntonioTerceiro - 07 Aug 2009
Oh I see. So loading the site-specific settings must be moved from compile time to execution time somewhere early in the code. Worth refactoring it as
FastCGI or any other persistent perl mode is pretty essential for modern web apps.
--
MichaelDaum - 10 Aug 2009
There's another problem not mentioned yet: Foswiki generates too many full URLs instead of URL
paths. If that gets cached (using the new PageCache), users will experience to suddenly have shifted the domain. One of the causes of the problem is
Foswiki::Func::getScriptUrl
. This generates a full URL. There is also a
Foswiki::Func::getScriptUrlPath
but that function is deprecated since 28 Nov 2008 for no good reason.
--
MichaelDaum - 12 Aug 2009
Michael, I don't see why the full paths would be a problem: what we want here is to be able to serve different sets of webs from different domains, so this issue should not have negative impact (AFAICT). Could you elaborate?
--
AntonioTerceiro - 16 Aug 2009
Never mind, Antonio. I solved the problem by adding server_name and server_port to the keys of a cached page in the
FoswikiCache. That way a topic computed via one domain and thus has got full urls in its markup will never be fetched from cache when the same topic is requested from another domain. That would be the case if part of the webs like the System web is shared among domains.
--
MichaelDaum - 17 Aug 2009
How can I sign up for this service?
Or become a tester etc?
--
SimonHardyFrancis - 29 Nov 2009
Hello all,
I've just uploaded the first release of
VirtualHostingContrib, which implements virtual hosting support for Foswiki.
I'd be happy to receive any feedback about it.
--
AntonioTerceiro - 16 Jul 2010
Yum Yum.
--
MichaelDaum - 20 Jul 2010