www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From R.P.C.(\"Rick\") Rodgers <rodg...@nlm.nih.gov>
Subject general/6172: problems installing apache and mod_dav
Date Fri, 09 Jun 2000 18:52:10 GMT

>Number:         6172
>Category:       general
>Synopsis:       problems installing apache and mod_dav
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Fri Jun 09 12:00:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     rodgers@nlm.nih.gov
>Release:        1.3.12
>Organization:
apache
>Environment:
Solaris 5.6 Generic_105181-04 sun4u sparc SUNW,Ultra-2
gcc 2.95.2
>Description:
Summary of Problems installing mod_dav 0.9.17-1.3.6 with Apache 1.3.12

We installed mod_dav 0.9.17-1.3.6 with Apache 1.3.12 under Solaris 2.6.
We installed mod_ssl prior to mod_dave, so patches from both are present
in our Apache code set.  We realize this may not be a bug the Apache team
will want to follow up on, but thought we should report it.

We also want to be able to use mod-dav in conjunction with PHP 4.0.0
(though that is not addressed here, and there is conflicting information
in the PHP developer's mail lists as to whether this will work or not;
we will post this to the appropriate lists/reporting engines for Apache,
mod_dav and PHP).

According to the installation instructions, there are two ways to install
mod_dav with Apache:

1) As a dynamically loaded module using the "apxs" tool.
2) As a statically linked part of the Apache executable.

(We can provide *fully detailed* installation instructions for anyone who
would find them helpful).  Here is a summary of our results with both methods:

DYNAMICALLY LOADABLE MODULE

For the case of building a dynamically loaded module, we installed Apache
1.3.12 first, and then used:
 
   ./configure --with-apxs=/site/subsys/www/apache/bin/apxs \
               --with-expat=/site/subsys/www/expat_1.1
 
to configure, built the system, and installed it.  After the libdav file
was copied into apache/libexec and httpd.conf was updated, we edited the
httpd.conf file as instructed, adding the following lines to enable DAV,
lock the database, and set the lock timeout minmum:
 
   DAVLockDB /site/subsys/www/apache_1.3.12/var/DAVLock
      DAVMinTimeout 600

      <Location /site/subsys/www/apache_1.3.12/htdocs/dav>
          DAV On
      </Location>

When we installed it the first several times, we would start the script with:

   apachectl startssl

and (on some trials) with

   apachectl start

but the script would fail with an error message complaining about not
recognizing "DAVLockDB".

In our most recent installation, apache starts (this is a deep mystery, as
we did nothing different!).  Since we have no way to test WEBDAV itself,
we do not know whether it really works.

STATICALLY LINKED

When building a statically linked version, before installing Apache 1.3.12,
we configured mod_dav:

   sh ./configure \
      --with-apache=/site5/SOURCE/INSTALL/web_kit_1.0/apache_1.3.12 \
      --with-expat=/site/subsys/www/expat_1.1

then we built and installed the package, which copied some necessary files into
the [...]/apache_1.3.12/src/module/dav directory.

When we configured the Apache package, we added an extra line to the configure
command:

      --activate-module=src/modules/dav/libdav.a

Then we installed the apache package.  The build and install steps went
smoothly.  The apachectl script runs without complaint, but there is no
apache process running moments later.  A pid entry has been created in
[...]/apache_1.3.12/logs/httpd.pid, suggesting that httpd started and then died
without an error message, but the actual process with that pid is not running.

FINAL STATE OF AFFAIRS

We made a final attempt to install mod_dav both ways, following the same
procedure we had earlier, and for some strange reason, both methods worked!

Here then are our current questions:

1) How can one test mod_dav?  It would seem that a simple test of some sort
   ought to be part of the installation instructions.

2) Anyone have thoughts as to why our final installations *worked*?  This is
   deeply mysterious to us.

>How-To-Repeat:
someone would have to reproduce our installation procedure.
>Fix:
No.
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]
 
 


Mime
View raw message