[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Using webdav for writes
From: |
Adrian Irving-Beer |
Subject: |
Re: [Gnu-arch-users] Using webdav for writes |
Date: |
Thu, 9 Sep 2004 16:42:22 -0400 |
User-agent: |
Mutt/1.5.6+20040818i |
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.
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
* 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.
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.
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.
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.
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.
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.
signature.asc
Description: Digital signature