[PROPOSAL] TWiki and mirroring
lizardo at linuxfromscratch.org
Mon Aug 2 12:28:01 PDT 2004
On Monday 02 August 2004 09:18, Jeremy Huntwork wrote:
> On Sun, 2004-08-01 at 15:52 -0400, Anderson Lizardo wrote:
> > - mirror the static data using the pushing method suggested by J.
> > Huntwork. Even if we have to continue to use a non-CMS solution, I think
> > we should move to push rsync'ing as it resolves another long-standing
> > problem (mirrors being constantly outdated).
> Jeroen mentioned making this first priority. So, you mean doing that
> now for our current setup? That's fine with me, but that means we need
> to inform the mirrors, right?
Right, but can we test it first with your server? I'll shortly send a new mail
explaining how things are going to be done. Basically, I can take care of the
necessary script changes (there will be some). Regarding the rsync setup and
the actual rsync command line to sync only the files changed (that we'll put
on a post-commit hook script for SVN), you should handle it as you are
certainly more familiar with rsync than me ;)
After we have this minimal one-mirror setup, we can write the instructions on
what steps the mirrors need to follow to enable pushing (basically the same
http://test.linuxfromscratch.org/twiki/bin/view/Main/WebsiteMirrors, but with
the TWiki specific setup stripped). I don't expect all mirrors to enable
rsync push at the same time, so the SVN hook will have some thing like
for mirror in <list of mirrors with push enabled>; do
to contact only the servers with push already enabled. The others will
continue running the cron job while they don't switch to this setup.
> > - Move from our current CGI/Apache authentication method to https, as
> > suggested by Jeroen. I have my doubts if the current method will work
> > well with these cross-site redirections from "edit mode" to "view mode"
> > and vice-versa.
> Actually, if I was understanding the original "theory" correctly, on a
> mirror no authentication would take place, all viewers are anonymous.
> When 'edit' is clicked, a user is redirected to the edit url of the same
> page on belgarath, which will in turn trigger TWiki's authentication
> process. So the user is only authenticated on belgarath. That should
> uncomplicate the authentication process a bit, right?
That was my idea of how the authentication would work, too.
> Also, we wouldn't be using https as authentication, just a secure
> encrypted connection so that passwords sent over the connection can't be
> read, right? If we did it that way, no current structure in the
> authentication method needs to change, with the exception of moving the
> TWiki method of encrypting passwords from crypt() to SHA1.
That was the actual Jeroen's suggestion (as he clarified me on the other
message): no HTTPS authentication, just "tunelling". But I thought that if we
were going to enable HTTPS on the server, why not use its secure
authentication feature? I'm ignoring possible complications on this approach,
though. If you guys think using HTTPS for authentication is overkill for our
purposes, let me know :)
lizardo at linuxfromscratch.org
More information about the website