Re: WebDAV locking trouble (yes, DavLockDB is chroot relative)

2006-03-01 Thread Nick Forrette
On 3/1/06, Didier Wiroth [EMAIL PROTECTED] wrote:

 Hi,
 I don't know if this helps you but I thought I let you know. I used to
 run
 into a lot of strange problems running httpd with mod_dav, httpd crashes
 and also
 (as far as I can remember) some db lock problems.

 All my problems were solved by copying the libdav.so into the chroot
 directory:
 /var/www/usr/lib/apache/modules/libdav.so

 You might want to give it a try...


I chouldn't even get httpd to start w/o copying libdav.so in to the chroot.
Thanks for the idea, though.

Nick



Re: WebDAV locking trouble (yes, DavLockDB is chroot relative)

2006-03-01 Thread Nick Forrette
On 2/28/06, Nick Forrette [EMAIL PROTECTED] wrote:

 From: [EMAIL PROTECTED]
 Subject:httpd / mod_dav locking troubles (DavLockDB is
 chrooted
 relative)
 Date:   February 28, 2006 7:21:59 AM PST
 To:   [EMAIL PROTECTED]


 I'm running OpenBSD 3.8 stable with mod_dav 1.0.3p0 installed from
 ports (sparc64 architecture).

 My goal is to get mod_dav working over https. While https is working
 ok, and my DAV client (Mac OS X 10.4.5) can connect and authenticate,
 any time the client attempts to create a file it will hang. Examining
 the error_log shows the following message repeated many thousands of
 time (before I killed httpd and waited for the Mac to timeout):



Last night I recompiled httpd and mod_dav with debugging enabled, and ran
httpd in gdb with arguments -X -DSSL -f /var/www/conf/httpd.conf. I set a
breakpoint in sdbm_store, which was the routing that was failing with errno
= EINVAL. After a little digging, I found the following:

mod_dav constructs a dbm key based (at least in part) on the file name being
locked. However, the file name used to construct the key was always the
empty string. Looks a lot like there is a bug in mod_dav.

I'm relatively new to the DAV and OpenBSD communities, and am wondering if
it makes more sense if I take this up on either the port-bugs or the dav-dev
list.

Thx,
Nick



Re: WebDAV locking trouble (yes, DavLockDB is chroot relative)

2006-03-01 Thread Nick Forrette
 What version of Apache?



The standard pached variant of 1.3.29 that is included with 3.8-stable.



WebDAV locking trouble (yes, DavLockDB is chroot relative)

2006-02-28 Thread Nick Forrette

From: [EMAIL PROTECTED]
	Subject: 	httpd / mod_dav locking troubles (DavLockDB is chrooted  
relative)

Date:   February 28, 2006 7:21:59 AM PST
To:   [EMAIL PROTECTED]


I'm running OpenBSD 3.8 stable with mod_dav 1.0.3p0 installed from  
ports (sparc64 architecture).


My goal is to get mod_dav working over https. While https is working  
ok, and my DAV client (Mac OS X 10.4.5) can connect and authenticate,  
any time the client attempts to create a file it will hang. Examining  
the error_log shows the following message repeated many thousands of  
time (before I killed httpd and waited for the Mac to timeout):


[Sun Feb 26 22:42:47 2006] [error] [client 10.0.254.2] Could not save  
lock information.  [500, #405]
[Sun Feb 26 22:42:47 2006] [error] [client 10.0.254.2] (22)Invalid  
argument: No error.  [500, #0]


I have not found anyone posting a solution to this issue. The best I  
could find was one other person having the same issue, but didn't get  
a response. The URL for the other post is:


http://mailman.lyra.org/pipermail/dav-dev/2005-November/006209.html

We're both running OpenBSD on sparc64 (though he was running 3.7).  
I've tried running apache both chrooted (httpd_flags=-DSSL) and  
unchrooted (http_flags=-u -DSSL). The change had no effect on this  
issue. SSL and authentication have not been a problem. Here's the DAV  
relevant portion of my httpd.conf:



Alias /dav/ /var/www/dav/files/

DavLockDB /dav/lockdb

Directory /var/www/dav/files/
Dav on

AuthType Digest
AuthName DAV
AuthDigestDomain /
AuthDigestFile /var/www/dav/dav_users
AuthGroupFile /var/www/dav/dav_groups

Options none
AllowOverride none

LimitExcept GET HEAD OPTIONS
require valid-user
/LimitExcept

Order allow,deny
Allow from All
/Directory

The owner and permissions on the /var/www/dav/ directory look fine:

drwxrwxr-x  3 www  www  512 Feb 27 21:52 dav/

The lock database is created in /var/www/dav, but I noticed the files  
have a zero size:


-rw-r-  1 www  www0 Feb 27 21:52 lockdb.dir
-rw-r-  1 www  www0 Feb 27 21:52 lockdb.pag

I haven't done anything special with my var partition (on a side  
note, I spaced it install time but /var/www/ will wind up on its own  
partition):


/dev/wd0g on /var type ffs (local, nodev, nosuid)

/var/log/messages doesn't have anything post relevant, just boot  
stuff and a couple syslog restarts.


I re-worked my httpd.conf to only run a single httpd instance  
(StartServers, MinSpare, and MaxSpare all set to 1), restarted httpd,  
and ktraced the httpd child process. Here's the portion of the output  
that deals with the lock db:


29913 httpdCALL  open(0x42d887f0,0x202,0x1b0)
29913 httpdNAMI  /dav/lockdb.pag
29913 httpdRET   open 7
29913 httpdCALL  flock(0x7,0x2)
29913 httpdRET   flock 0
29913 httpdCALL  open(0x42d887e0,0x202,0x1b0)
29913 httpdNAMI  /dav/lockdb.dir
29913 httpdRET   open 8
29913 httpdCALL  fstat(0x8,0xfffbe0a0)
29913 httpdRET   fstat 0
29913 httpdCALL  gettimeofday(0xfffbe960,0)
29913 httpdRET   gettimeofday 0
29913 httpdCALL  stat(0x4f2df090,0xfffbe660)
29913 httpdNAMI  /dav/files/._index copy.html
29913 httpdRET   stat 0
29913 httpdCALL  close(0x8)
29913 httpdRET   close 0
29913 httpdCALL  flock(0x7,0x8)
29913 httpdRET   flock 0
29913 httpdCALL  close(0x7)
29913 httpdRET   close 0

The lockdb.pag file is opened successfully (file descriptor 7) and  
flock reports the exclusive lock was obtained alright (the open and  
flock man pages helped here). However, httpd still seems to be having  
some sort of issue related to locking. I haven't touched systrace  
since I did a fresh install of 3.8 (all I see in /etc/systrace are  
usr_sbin_lpd and usr_sbin_named).


I did some digging in the mod_dav source and found that the Could  
not save lock information is only issued in one place, and that is  
if a call to sdbm_store (via a function pointer) is failing with  
EINVAL (errno value 22 in the above error_log snippet). It's returned  
from sdbm_store because either the database is NULL, or the key data  
pointer is NULL or has a zero size. Searching for various  
combinations of sdbm, DAV, sparc, and OpenBSD didn't find anything  
that looked relevant. If someone has already seen / patched / worked  
around this, I'd rather not waste time creating a debug build of  
httpd / mod_dav (my only sparc box is on the slow side).


Any help or insights appreciated.

Nick