[PROPOSAL] TWiki and mirroring

Anderson Lizardo 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 
instructions on 
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
...
done

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 :)

-- 
Anderson Lizardo
lizardo at linuxfromscratch.org
http://www.linuxfromscratch.org/



More information about the website mailing list