gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Using webdav for writes


From: James Blackwell
Subject: Re: [Gnu-arch-users] Using webdav for writes
Date: Thu, 9 Sep 2004 17:11:26 -0400

> On Thu, Sep 09, 2004 at 03:30:02PM -0400, James Blackwell wrote:
>> I've used webdav for readable archives before. However, I've never
>> tried to use arch on a writable dav archive.
>

Then Adrian (bless his soul) replied with indepth instructions on how to
use webdav for writes

Thanks dude! Just two more questions: 

1. Are you using ssl and the standard arch client? 

2. were you able to use make-archive? 


> I do this all the time, but in a bit of an odd fashion.
>
> The biggest thing, of course, is that the person running the DAV web
> server will be the owner of the files.  So I run mini-Apache instances
> as myself, with

I was counting on this one, actually. :) 

>
>         * the mod-dav module,
>         * IP address limiting,
>         * a very barren, dummy web root,
>         * aliases to the archive locations,
>         * DAV enabled for archive locations only,
>         * a read-only userid and a writable userid.

I assume the read-only id is for "everyone" and the writable userid is
for the person pushing the archive.

Do you have an opinion (depending on your https answer above) on doing
writes with https, and reads for everyone else with http? 

>
> Of particular interest is the separation of read and write:
>
>     In the same block where I say 'DAV On', I make sure I've got all
>     the standard Auth options set (AuthName, AuthType, AuthUserFile,
>     AuthGroupFile) and 'Satisfy all' (so that IP restrictions still
>     apply) plus 'Require group write'.
>
>     Then, I do a <Limit OPTIONS PROPFIND GET HEAD> block with 'Require
>     group read'.  Those are all the DAV operations that (I believe)
>     are non-writing and required by read-only arch.
>
> Be sure to set 'LimitXMLRequestBody' to a very high number, or 0
> (infinite), or else your large changesets (big binaries?) will fail
> mysteriously.

Ok. I'll watch out for that.

>
> Be very careful of header-stripping privacy settings on web proxies.
> Squid in particular is a problem if you prefer to use the 'drop all
> headers but the ones I list' mode, because you can't list most DAV
> stuff without altering the source and recompiling.

Ok.
 
> For read-only DAV, the only extra header required is 'Depth', but
> writable DAV seems to require several more.  Personally, I use a
> wrapper script to ensure that arch never ever uses a proxy server.

Thats actually a pretty good thing to do.

> File umask was a bit of a problem for me.  I have one archive that I
> upload to via DAV that is then publicly accessable via the regular
> Apache server (read-only DAV).  I needed to carefully set up the
> umask, group ID, group write/sticky bits, etc.

How do you fix the umask? 

> I also had one time where tla on a particular machine could not cope
> with a particular password.  If I set the password to anything else,
> the two communicated fine.
>
> Other than that last part, though, all DAV issues I've ever had have
> been a function of Apache/mod_dav rather than arch.
>
> My config files are available on request, albeit with sensitive parts
> censored out.

I'd be really curious as to how the =locations look.

Again, thank you very much, Adrian!

-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400




reply via email to

[Prev in Thread] Current Thread [Next in Thread]