Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 554
  • Last Modified:

stuck trying to set up DAV server

I am trying to set up an Apache DAV server with Apache 2.4.10 on Slackware64 14.1 kernel 3.10.17. I've followed the instructions in http://httpd.apache.org/docs/2.2/mod/mod_dav.html. My extras/httpd-dav.conf has the following:
DavLockDB "/var/lock/DavLock"

Alias /calendars "/srv/httpd/htdocs/calendars"

<Directory "/srv/httpd/htdocs/calendars">
    Dav On

    AuthType Basic
    AuthName DAV-upload
    AuthUserFile "/etc/httpd/passwords"

    <RequireAny>
        Require method GET POST OPTIONS
        Require user mark
    </RequireAny>
</Directory>

BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "MS FrontPage" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
BrowserMatch "^WebDAVFS/1.[01234]" redirect-carefully
BrowserMatch "^gnome-vfs/1.0" redirect-carefully
BrowserMatch "^XML Spy" redirect-carefully
BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully
BrowserMatch " Konqueror/4" redirect-carefully

Open in new window

The lock and target folders have the following permissions:
> ls -ld /var/lock/DavLock /srv/httpd/htdocs/calendars
drwxrwxr-x 2 apache apache 4096 2015-02-07 12:01 /srv/httpd/htdocs/calendars/
drwxrwxr-x 2 apache apache 4096 2015-02-07 11:53 /var/lock/DavLock/

Open in new window

When I attempt to connect to the server, I get the login dialog OK, but then I get the message "upload failed". See attached image.

My error_log contains nothing. My access_log has the following:
64.129.23.80 - - [07/Feb/2015:12:19:54 -0500] "PROPFIND /calendars/ HTTP/1.1" 401 381
64.129.23.80 - mark [07/Feb/2015:12:20:07 -0500] "PROPFIND /calendars/ HTTP/1.1" 302 216

Open in new window

I'm stumped. What am I doing wrong?
DAVerror.jpg
0
jmarkfoley
Asked:
jmarkfoley
  • 2
1 Solution
 
jmarkfoleyAuthor Commented:
More info ... I modified my dav config as follows:
DavLockDB "/var/lock/DavLock"

Alias /calendars "/srv/httpd/htdocs/calendars"

<Directory "/calendars">
    Dav On

    AuthType Basic
    AuthName DAV-upload
    AuthUserFile "/etc/httpd/passwords"

        Require user mark
</Directory>

BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "MS FrontPage" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
BrowserMatch "^WebDAVFS/1.[01234]" redirect-carefully
BrowserMatch "^gnome-vfs/1.0" redirect-carefully
BrowserMatch "^XML Spy" redirect-carefully
BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully
BrowserMatch " Konqueror/4" redirect-carefully

Open in new window

When I go to the location via the web, I am prompted for user/pw and get the folder, just fine:
Getting via via webWhen I try from the same host using cadaver I get:
$ cadaver http://phonetree.ohprs.org/calendars/
Could not open collection:
302 Found
dav:/calendars/?

Open in new window

The 302 code means:
302 Found
This is an example of industry practice contradicting the standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[6] but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.[7] However, some Web applications and frameworks use the 302 status code as if it were the 303.[8]

303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using a GET method. When received in response to a POST (or PUT/DELETE), it should be assumed that the server has received the data and the redirect should be issued with a separate GET message.
Does anyone have any idea what's going on?

Note, running the cadaver command from the same host several hours later gives me:
> cadaver http://phonetree.ohprs.org/calendars/
Could not access /calendars/ (not WebDAV-enabled?):
405 Method Not Allowed
Connection to `phonetree.ohprs.org' closed.
dav:!>

Open in new window

With no changes made to the server side. Same results restarting httpd.

Is WebDAV one of those things that just doesn't work in Apache?
0
 
jmarkfoleyAuthor Commented:
Alright, I got it sorted out, but it was painful. Here is my working DAV config:
DavLockDB "/var/lock/DavLock/DaveLockDB"

<Directory "/var/lock/DavLock">
    AllowOverride None
    Options None
    Require all granted
</Directory>

Alias /calendars "/srv/httpd/htdocs/calendars"

<Directory /srv/httpd/htdocs/calendars>
    Options Indexes Multiviews
    AllowOverride None
    Order Allow,deny
    Allow from all
</Directory>


<Location "/calendars">
    Dav On

    AuthType Basic
    AuthName DAV-upload
    AuthUserFile "/etc/httpd/passwords"

        Require method GET POST OPTIONS
        Require user mark
</Location>

BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully
BrowserMatch "MS FrontPage" redirect-carefully
BrowserMatch "^WebDrive" redirect-carefully
BrowserMatch "^WebDAVFS/1.[01234]" redirect-carefully
BrowserMatch "^gnome-vfs/1.0" redirect-carefully
BrowserMatch "^XML Spy" redirect-carefully
BrowserMatch "^Dreamweaver-WebDAV-SCM1" redirect-carefully
BrowserMatch " Konqueror/4" redirect-carefully

Open in new window

Adding the "<Directory /var/www/localhost/htdocs/webdav>" section and changing the "<Directory /calendars>" section to "<Location /calendars>" got the cadaver test working, but I still couldn't publish. I got the error "[dav:error] Could not open the lock database." After some headscratching I speculated that the DavLockDB path was to the complete lock file, not jus the lockfile directory. So I changed that to

DavLockDB "/var/lock/DavLock/DaveLockDB"

and was able to finally publish. This was most confusing since the Apache template contained the instruction "The User/Group specified in httpd.conf needs to have write permissions on the directory where the DavLockDB is placed ...". Well,  /var/lock was already world writable and the template suggested /usr/var directory didn't originally exist, so it seemed to be that the DavLockDB was specifying the lockfile directory, not the full lockfile path. Apache should have made this clearer, though I solved that particular issue quickly.

Not sure if either adding the <Directory /srv/httpd/htdocs/calendars> or changing to <Location /calendars> fixed the main problem, or if both were required -- don't feel like experimenting further.

*Raspberries* to Apache for not supplying a template that actually worked!  >:\ The <Location> setting was published on the web in a couple of places meaning, I suppose, that others had to figure it out on their own as well. Booo! for wasting a whole day of my time.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now