TWiki Mirror [was: Oregon mirror is not up to date]

Jeroen Coumans jeroen at
Fri Jul 9 09:53:56 PDT 2004

Jeremy Huntwork said the following on 09-07-2004 16:56:
> On Thursday 08 July 2004 04:24 am, Jeroen Coumans wrote:
>>But please, if you have the time, then take an extensive look at all
>>other options and see which is easiest to construct and maintain.
> I'm currently looking through the Mirroring options you listed and I'm 
> trying to organize my thoughts here about what I'm seeing.
> It seems that all the options listed on require a TWiki 
> installation on the mirrored host.  This would include any perl modules 
> used, I believe.  Is this acceptable?  Wouldn't this require more than 
> we want out of a mirror?

I'm not sure, but Perl is standard on all Linux systems. We once queried 
the mirrors for PHP, and IIRC only one or two didn't have it. So I don't 
think the requirements are too steep. Not sure about extra Perl modules 
though; I know it requires at least RCS, which is non-standard.

> I suppose we could render the entire web from belgarath into HTML and 
> then sync, but another thing that comes to mind is that we can't rsync 
> periodically the way we currently are.  Imagine this scenario: A user 
> in Europe reads a page from his local mirror.   He then decides to edit 
> the page, and this is done at belgarath as all edits are.  When he 
> saves his page and returns to his mirror he won't see the change, not 
> until the rsync occurs.  In my mind, this is broken.  In order to fix 
> this we would have to be *constantly* synchronizing, actively pushing 
> changes whenever they occur.  Which I suppose wouldn't be too bad if 
> it's a matter of pushing one file at a time when it changes.

Yes, that is possible with rsync; it's very smart and will only 
transfers files which have changed. So if we'd actively push files on 
each edit, we'd better do it with rsync. We could hook it in the "save" 
function of twiki. It's only one file which would have to be 
synchronized each time, so the delay would be minimal unless the load is 

I'm not too keen on exporting to HTML all the time, except if this would 
be less processor-intensive then regular TWiki use.

> If these are things that have already been considered, and I missed them 
> somwhere, my apologies.  In the meantime, I'm going to be thinking 
> through this and researching further possibilities.  So far, to me, the 
> best solution listed is the Clustering option, with one-way syncs via 
> rdist.  Included in this option would be the DataAndCodeSeparation, 
> making syncs via web simpler.

I'm not familiar with rdist, but maybe rsync is better since it's what 
is currently in use too (unless rdist has strong features or advantages 
over rsync). Rdist also doesn't seem to be maintained anymore.

Jeroen Coumans

More information about the website mailing list