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

[Adrian Irving-Beer]

On Thu, Sep 09, 2004 at 11:39:05PM +0200, Matthieu Moy wrote:

> > 1. Are you using ssl and the standard arch client?
>
> This is disabled by default for license reasons. Some people
> reported they managed to have it work, but I didn't :-(

I'm one of those people who thought I was oh-so-clever for simply
forcing WITH_SSL=yes in the makefile, but then discovering it was
broken. :(

I do everything over a dynamically-routed VPN, so I generally don't
mind passwords and data being sent in the 'clear', since the network
handles all that for me.

> > 2. were you able to use make-archive?
>
> I were. Actually, I use several archives that are on a machine on
> which the only access I have is WebDAV, and it works.

I've never had any problem here, either.

> > How do you fix the umask?
>
> Normally, you shouldn't have to : The process reading and writting
> your files is Apache itself. And the Apache server has off course
> access to the files it writes.

Right, this is correct for any situation except the crazy one I had,
where I actually did have to have an independent user reading (but not
writing to) the files I was spitting out.

This is all from memory, mind you, but I seemed to get into reading
issues since I think the DAV module imposes at least a 007 extra
umask, regardless of what you set in your shell.


On Thu, Sep 09, 2004 at 05:11:26PM -0400, James Blackwell wrote:

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

Actually, in my case, my biggest need for DAV arch is that I'm storing
a basic user configuration in arch -- scripts, shell rcfiles, config
files, mutt profiles, etc.  So I wanted some machines (particularly my
laptop) to be able to write, but most to just read (for safety).

It's marginal safety, but it's how I responded to the need to store
the password in the clear on every single machine in our network --
they store a less sensitive password.

This is for my 'private' archive.  For my 'public' archive, I just use
a private login on the DAV server plus a public login on my public
server (arch.wisq.net).

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

No HTTPS, so, no.  You could figure out all the write-access methods
(e.g. PUT) and list them in a <Limit>, with 'SSLRequireSSL' inside
      there, but that leaves the door open to any methods you missed.

You could probably set a variable in the main block to a true
value, set it inside the 'read access' block to a false value, and
then use 'SSLRequire' on that variable to selectively require SSL.
Just a thought.

If you're not looking to *limit* writes to SSL, you're in better luck.
I've run SSL ports alongside regular ones for standard HTTP/HTTPS.

Presumably, as long as anyone who was going to write specified 'https'
and the SSL port as the arch URL on the client side, they'd be side.

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

Exactly like normal URLs, but with a username and password.  E.g.

        http://username:address@hidden:port/directory

That's the standard spec for a URL with a login embedded.  You can do
e.g. ftp URLs the same, too.

signature.asc
Description: Digital signature