On Wed, Aug 31, 2005 at 06:19:10PM -0400, Geoffrey Young wrote:
> if you can do me the favor of trying a few different configuration scenarios
> (including 1.3, non-apxs, /usr/local/apache, etc) and making sure nothing
> breaks, that would be great. the box where my matrix used to live had a
> har
On Wed, Aug 31, 2005 at 11:54:57AM -0400, Geoffrey Young wrote:
> $self->{httpd_basedir}, which looks to be calculated based on the location
> of the httpd binary. but it looks like it ought to be using HTTPD_ROOT
> instead. at least if it's defined.
>
> try this (completely untested)
Perfect!
On Thu, Aug 25, 2005 at 06:56:57PM -0400, Philip M. Gollucci wrote:
> >From the trace below, you can see that A::T thinks the config file is
> >'/usr/conf/httpd2.conf':
> > [ debug] isolated httpd_defines HTTPD_ROOT = /etc/httpd/2.0
> > [ debug] isolated httpd_defines SERVER_CONFIG_FILE = con
On Thu, Aug 25, 2005 at 06:59:56PM -0400, Philip M. Gollucci wrote:
> To answer your original quesiton,
> you want:
> in A-T source,
Thanks for the reference. Some further investigating showed that calling
t/TEST -clean is when I lose the -httpd_config setting which explains
why `./Build test` is
I was able to get a trace from a failing case after using './Build &&
t/TEST'. Calling just 't/TEST' finds the config file correctly. So it
appears that calling ./Build is where the trouble occurs for me (though
I've never seen this behavior before). From the trace below, you can see
that A::T thin
On Thu, Aug 25, 2005 at 04:04:13PM -0400, Philip M. Gollucci wrote:
> >I've looked through the Apache::TestConfig.pm file to try to find where
> >the problem may be but cannot figure out where that module obtains the
> >configuration file or how to dump out the configuration file it is
> >automatic
Hey folks,
I'm having a bit of a struggle with Apache::Test on a Mandriva Linux
10.1 server. I'm using A::T v1.26 with Apache2.0.50 + mod_perl2.0.1. For
some reason, the configuration process is not finding the global config
file which causes my tests which are working under a Debian workstation
t
On Wed, Jun 08, 2005 at 12:00:01AM +1000, Stas Bekman wrote:
> Great! William, can you please write a new entry for the troubleshooting
> chapter? With a full diagnosis and the solution? Really it should belong
> to the Apache-Test troubleshooting, but as at the moment it doesn't exist,
> we wil
Well, I posted too fast. Scratch that first diff for this version which
has a bit more detail about how the UPLOAD function is working.
William
--
Knowmad Services Inc.
http://www.knowmad.com
--- testing.pod.orig2005-07-06 09:21:53.0 -0400
+++ testing.pod 2005-07-06 15:26:19.000
I've been working with adding upload tests to my script and have a few
additions to make to the testing.pod file which are attached. I've also
updated all the t_cmp() examples to indicate the new format of received,
expected, comment.
Thanks,
William
--
Knowmad Services Inc.
http://www.knowmad.
On Tue, Jun 07, 2005 at 11:40:49PM +1000, Stas Bekman wrote:
> Something is not right here. Your perl is not threaded:
>
> However the segfault shows threads operation:
Yeah, it's bizarre.
> >#0 0x882fa1d7 in kill () from /lib/libc.so.5
> >(gdb) bt
> >#0 0x882fa1d7 in kill () from /lib/libc.s
On Tue, Jun 07, 2005 at 11:35:46PM +1000, Stas Bekman wrote:
> That's OK, William. But you aren't after defined symbols in .so, you are
> after the APR_HAS_THREADS define which should be undef. Moreover, you are
> building a static version so the symbols aren't coming from .so but .a/.la
> archi
-8<-- Start Bug Report 8<--
1. Problem Description:
When using Image::Magick (either 6.1.9.4 or 6.2.3) under mod_perl, the
server segfaults. Used at the command line or under mod_cgi there are no
errors.
A core dump is attached. This is my first attempt at
On Tue, Jun 07, 2005 at 09:34:29AM +1000, Stas Bekman wrote:
> William, as you can see from the source src/modules/perl/modperl_util.h
>
> #if defined(MP_TRACE) && defined(APR_HAS_THREADS)
> #define MP_TRACEf_TID "/tid 0x%lx"
> #define MP_TRACEv_TID (unsigned long)apr_os_thread_current()
>
>
On Sat, Jun 04, 2005 at 09:29:53PM +1000, Stas Bekman wrote:
> >/stubs/usr_local/src/mod_perl-2.0.0/src/modules/perl/modperl_util.c:472:
> >undefined reference to `apr_os_thread_current'
> >*** Error code 1
>
> William, please try:
> http://perl.apache.org/docs/2.0/user/troubleshooting/troublesho
On Thu, Jun 02, 2005 at 03:59:50PM +0100, Johannes Kilian wrote:
> I try to migrate to mod_perl 2.0 from mod_perl 1.99 RC4 (WinXP,
> ActiveState Perl 5.8.6)
>
> Running my old scripts the following error occurs in Module cgi.pm:
> Can't locate Apache/Response.pm in @INC
Did you read the Migrating
-8<-- Start Bug Report 8<--
1. Problem Description:
While trying to track down a segfault that is occurring with
Image::Magick, I went to build a version of mod_perl with debugging
flags. Unfortunately this does not build for me under FreeBSD 5.3. Here
is t
Ken,
Thanks for the explanation. For better or worse, after a rebuild of
mod_perl all of my tests are now working. I don't know what I changed
but I've logged out and back onto the system and rebuilt from scratch.
Everything is running perfectly which is great. Now to see if my
segfault with Image
On Thu, Jun 02, 2005 at 09:37:51AM -0700, Ken Simpson wrote:
> It _may_ (just because I have a gut feeling, not because of actual
> consideration) be a socket options issue that may be related to your
> platform. I had a very similar problem with OpenBSD last summer
> wherein the socket blocking st
-8<-- Start Bug Report 8<--
1. Problem Description:
Following on the heels of my previous post to Stas regarding an old
thread, I've another test failure report. This one is for
t/protocol/pseudo_http.pm. It is failing because the connection to the
server is
s. I'll try to spend
some more time on it later today.
Also, the t/protocol/echo_filter.t test is failing. It runs tests 1 and
2 then keeps running until it fills up the disk space then dumps a
massive core file. I'm just skipping it for now.
William
On Fri, Feb 18, 2005 at 05:32:49PM
On Mon, Apr 25, 2005 at 01:51:23PM -0400, Geoffrey Young wrote:
> that code is essentially right. well, except that the above example sets
> $r->handler instead of comparing it. adding the code at the bottom of this
> mail essentially makes your tests pass, except that I think your last test
> is
On Wed, Apr 13, 2005 at 08:21:46PM -0400, Geoffrey Young wrote:
> hmm. I'm sorry I didn't get back to you today, but I had something
> unexpected come up. I'll be rolling rc5 tomorrow, but if you want to create
> a bug tarball for me I'll look into it with whatever resources I can
> scrounge up.
On Tue, Apr 12, 2005 at 08:33:59PM -0400, Geoffrey Young wrote:
> for a good discussion, and a fixup handler that will likely fix your
> problem. you can also search the archives for the Apache::Dir discussion
> that (IIRC) yielded that document.
Geoff,
I tried using Apache::Dir. The current ver
On Tue, Apr 12, 2005 at 08:33:59PM -0400, Geoffrey Young wrote:
> yes, because mp1 is configured to handle requests of type DIR_MAGIC_TYPE
> whereas mp2 is not. this is a bug or a feature, depending on whether you
> think mp1 was correct or not :)
OK, that makes sense. I was beginning to worry ab
Hi,
This message is probably coming at a bad time with the recent release of
RC5. I'm still in the process of migrating from mp1 to mp2-RC4 at the
moment. I have a directory which is setup to be served via
ModPerl::Registry. When I try to open the path with only the directory
name (e.g., http://lo
On Thu, Mar 31, 2005 at 12:33:21PM +0200, Peter Roosdorp wrote:
> Any ideas? Where can I get help with this?
Hi Peter,
Start with filling out a bug report[1].
William
[1] http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
--
Knowmad Services Inc.
http://www.knowmad.com
On Fri, Mar 18, 2005 at 09:10:11AM +, Andrew Green wrote:
> I fear that the fact that the problem is really very intermittent might
> hamper this, however. I should also probably have pointed out that
> there's a PostReadRequestHandler and a TransHandler in the config as
> well, which I gue
On Tue, Mar 15, 2005 at 05:31:28PM -0500, Perrin Harkins wrote:
> BerkeleyDB, MySQL, or SQLite3, but I don't think BDB works in Win32.
Please don't tell my code that :). It's been using the BerkeleyDB module
on a daily basis for nearly a year with few problems. The module is
available as a PPM on
On Thu, Mar 10, 2005 at 04:15:38PM -0500, Jonathan Vanasco wrote:
> I've been looking mostly at NetBSD, FreeBSD and OpenBSD -- has anyone
> had remarkable success or misfortune with modperl2 under these
> environments in regards to speed or running?
Hi Jonathan,
I've been running mp1 under Free
On Fri, Feb 18, 2005 at 10:15:19AM -0500, William McKee wrote:
> Actually, I suppose that I could try running the nonblock script first
> to see if that works.
I was able to get my hosting provider to run the nonblock program
outside of a jailed process and it works. We've been tryin
On Thu, Feb 17, 2005 at 06:27:15PM -0500, Stas Bekman wrote:
> As for 'Can't open t/conf/perlsection.conf', do
>
> t/TEST -clean
To make a long story short, I had run the make test on the source as
root which caused the t/ directory to have its ownership changed to
nobody. So when I went to run m
On Fri, Feb 18, 2005 at 01:40:44PM +, Joe Orton wrote:
> That confirms that the problem: you got a connect() failure when the
> configure test program attempted to a listener bound to 0.0.0.0
OK.
> You can try the standalone test program here to reproduce the failure:
Yes, that seems to be
On Thu, Feb 17, 2005 at 04:53:45PM +, Joe Orton wrote:
> Check for the result of the:
>
> "checking if O_NONBLOCK setting is inherited from listening sockets"
>
> test when you run the configure script.
I wasn't sure if you were referring to the mod_perl or Apache configure
script. When I ra
On Wed, Feb 16, 2005 at 10:40:52PM -0500, Stas Bekman wrote:
> I wonder if it'd be a good idea to make CGI.pm libapreq aware. Most people
> use CGI.pm since it parses input and generates the output, so empowering
> CGI.pm with libapreq speed would be really cool.
Actually, I thought[1] the goal
On Wed, Feb 16, 2005 at 10:52:06PM -0500, Stas Bekman wrote:
> Thanks, William. I've committed an extended version of your patch but at
> the beginning of that section. Please let me know if it needs more work.
Looks good. That explains it the way I now understand it to work.
> I believe the er
On Thu, Feb 17, 2005 at 10:39:46AM +, Joe Orton wrote:
> That was all the non-blocking-vs-blocking stuff. First I'd ask whether
> or not this fails in a non-chroot environment. A chroot will screw up
> all kinds of stuff (e.g. the resolver libraries) unless you set it up
> properly.
Any poin
On Wed, Feb 16, 2005 at 07:12:11PM -0500, Stas Bekman wrote:
> please look at your original report, William, it was failing the same 2
> sub-tests.
That's weird because it's only failing one if I run it by itself. This
obviously wasn't the case earlier when I reported the error. At any
rate, this
On Wed, Feb 16, 2005 at 07:14:24PM -0500, Stas Bekman wrote:
> >Yes, it is (though keep in mind that this is a virtual server running as
> >a jailed process, not a separate machine).
>
> That could be the reason.
But if I open a lynx session and surf over to localhost, my server comes
up fine.
On Wed, Feb 16, 2005 at 04:06:39PM -0500, Stas Bekman wrote:
> whereas Apache-Test sees 127.0.0.1. I suppose 166.70.252.34
> is the external IP of the same machine.
Yes, it is (though keep in mind that this is a virtual server running as
a jailed process, not a separate machine).
> Try to debug
On Wed, Feb 16, 2005 at 04:08:45PM -0500, Stas Bekman wrote:
> see if this patch helps:
Uh-oh, from bad to worse. Now we're failing two tests (instead of only
the last one):
# Running under perl version 5.008006 for freebsd
# Current time local: Wed Feb 16 17:23:47 2005
# Current time GMT:
On Wed, Feb 16, 2005 at 04:12:34PM -0500, Stas Bekman wrote:
> Don't forget that we are talking about APR socket API, not perl socket
> API, which aren't the same.
Oh, right, I hadn't really considered that. Hopefully it's at least
useful to see that the perl sockets are working.
> I've never s
> 2) if you build a static mod_perl, it'll configure and make Apache for you.
Ahh, so I don't even need to configure Apache if I'm building a static
mod_perl. I've amended the install.pod to indicate as much.
> You should not run it *from under /root directory or similar*, but as long
> as you
I didn't get very far with debugging the test (basically the test server
got started and I lost control of the debugger). At any rate, I found
some more information about sockets inside of jailed environments[1].
Section 4.2.2 seems to indicate that the type of socket we are creating
in the followi
Stas (and anyone else using FreeBSD),
I tried searching the archives but didn't find anything that
specifically addressed the errors I'm having. As shown in my original
bug report, I'm using FreeBSD 5.3 in a jailed (chrooted) environment.
I'm willing to dig into the test errors if you can give me
> committed the first part of it (those who know what options to use don't
> need extra explanation, those who don't know won't find the extra
> explanation sufficient).
That's fine. The second part was more for my own edification.
> It's never the case. In the case of DSO it never happens. In
On Tue, Feb 15, 2005 at 06:41:04PM -0500, Stas Bekman wrote:
> I think there were a few similar reports posted here before (check the
> archives). Unfortunately no one running FreeBSD has volunteered to look at
> those. From what we have seen before all test failures seem to be caused
> by some
On Sat, Feb 12, 2005 at 11:12:07AM -0500, John Klassa wrote:
> Am I missing something obvious?
I'm not familiar with this error. Try filing a complete bug report[1]
and you'll have better luck getting some assistance.
William
[1] http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Pro
I finally took the plunge and installed mp2 onto my FreeBSD virtual
server. Here are a few updates to the install.pod which would have made
the installation process a bit easier for me.
I'm not sure about the modification I made at line ~617. I installed a
static mod_perl so presume that the serve
-8<-- Start Bug Report 8<--
1. Problem Description:
While installing mod_perl2 on a FreeBSD 5.3 jail environment, I received
the following test errors:
Failed Test Stat Wstat Total Fail Failed List of Failed
On Tue, Feb 08, 2005 at 08:33:18AM +, gotta go wrote:
> trying to install libapreq2-2.04-dev on freebsd 4.8 results in the
> following error.
> make: don't know how to make all-local. Stop
> *** Error code 1
This looks like a make error. I've not tried to build mp2 under FreeBSD,
but I kno
Hi Perrin,
Thanks for the feedback. I've been meaning to find a better alternative.
I think many programmers writing standard cgi scripts are scared off
from using the Apache::Session modules because of the chosen namespace,
although I understand that it's possible to use them outside of Apache.
M
On Sat, Jan 15, 2005 at 08:15:31AM -0500, Michael Peters wrote:
> CGI::Session does not appear to be well maintained. It's very popular
> and I know many people who have tried to send in patches and fixes but
> the author has been unresponsive.
Which is really ashame since it's listed in the P
On Fri, Dec 31, 2004 at 02:02:59PM -0500, Stas Bekman wrote:
> Thanks William, I've committed that with a few tweaks. Especially the last
> para. Please check that it still makes sense.
Looks fine except for a couple of typos (dangling quote mark and
mispelled 'should'). Also, now that I'm a bit
Thanks for the clear explanation of *.a and *.so files, Stas. I'm
starting to grok how it works together.
I've attached the diff to the install docs to this message which
incorporates some of your notes about .so and .a files. I found this
information hard to find while browsing Google, Perlmonks
On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote:
> >During compilation of mod_perl, I was seeing undefined reference errors
> >which are nicely described on the install page[1]. The prescription
> >suggests rebuilding Perl with dynamic linking; apparently the version
> >that's shipped w
On Thu, Dec 30, 2004 at 07:32:19PM -0500, Stas Bekman wrote:
> >Hmm, that's what I thought too and was creating a symlink from
> >/usr/lib/libperl.so to the newly created one. I was still getting
> >strange behavior though so moved them all out of /usr/lib. Seems a bit
> >better now.
>
> If the ap
On Thu, Dec 30, 2004 at 07:00:36PM -0500, Stas Bekman wrote:
> >I'm guessing that this goes for any libperl.so, e.g. libperl.so.5.6 or
> >libperl.so.5.8. If so then it would explain the weird behavior that I've
> >been getting when compiling mod_perl.
>
> Normally in addition to libperl.so.5.8 the
On Thu, Dec 30, 2004 at 05:57:07PM -0500, Stas Bekman wrote:
> As [2] explains you have more than one libperl.so and the wrong one gets
> loaded. libperl.so should *not* be in /usr/lib or any other globally seen
> loader path if you want to have more than one perl on the same system.
> Unfortuna
Hi folks,
I'm trying to recompile Perl and Apache/mod_perl on a Debian Sarge
system using the following versions:
Perl 5.8.6
Apache 1.3.33
mod_perl 1.29
I am compiling mod_perl statically (using Apachetoolbox) with the
following options:
APACHE_PREFIX=/usr/local/apache
APACHE_SRC=/us
On Thu, Dec 16, 2004 at 11:28:42AM -0500, Stas Bekman wrote:
> Right, because as you've figured out t/conf/apache_test_config.pm is a
> cached version of the the test setup data. So you need to do a cleanup
> before reconfiguring things so that file gets updated. Note that you
> perform things A
On Mon, Nov 08, 2004 at 07:17:21PM +0100, Arne Skjaerholt wrote:
> And, as I think of it, I don't think it'd be terribly useful as
> CGI::Application is intended for use with CGI scripts, not mod_perl
> handlers.
This is not true. Several folks on the C::A list, including myself, are
using it in c
On Wed, Oct 13, 2004 at 12:46:19PM +0100, Martin Moss wrote:
> Hmmm, I'm a little concerned that using DSO does have
> a performance hit for no real benefit for what we wish
> to do. Hmm, now just need to find instructions on
> building apache with mod_ssl, mod_perl and mod_php?
> without using DSO
On Tue, Oct 12, 2004 at 05:06:18PM +0100, Martin Moss wrote:
> Most information I find on the web to do this uses
> DSO. Performance is absolutely critical for this
> machine, it's going to be handling millions of web
> 'hits' per day.
>
> My question is, should we use DSO or not?
> My second que
Hi Pierre,
You're in the right place. I run Apache with Debian and have had
troubles in the past with compiling mod_perl due to having two copies of
libperl.so[1]; I think this would more likely be the case if you have
compiled Perl yourself.
William
[1] http://mathforum.org/epigone/modperl/pe
On Mon, Sep 06, 2004 at 03:31:51PM -0700, Ben Hopkins wrote:
> Here's the error log entries:
> [Mon Sep 6 15:21:44 2004] [error] [client 4.42.113.186] File does not
> exist: /usr/local/apache/htdocs/server-status
> [Mon Sep 6 15:22:03 2004] [error] [client 4.42.113.186] File does not
> exist: /
On Sat, Sep 04, 2004 at 12:56:26PM -0700, Ben Hopkins wrote:
> I got FORBIDDEN errors until I put my IP addr (I'm working on a remote
> server). Then I got 404s.
The directives look similar to mine. Is there no message in the Apache
error logs that gives you a hint of what's wrong with your syst
On Fri, Sep 03, 2004 at 10:47:37PM -0700, Ben Hopkins wrote:
> THAT DID IT! I commented perl's LoadModule, restarted, and VIOLA,
> every thing's back to normal.
Hey Ben,
I'm glad that Rici was able to help you.
> The very odd thing is that there are no errors in the build, or in
> apach
On Thu, Sep 02, 2004 at 08:51:15PM -0700, Ben Hopkins wrote:
> Nope. There are two copies of libperl.so: one in the apache source
> tree, and one in libexec.
>
> BUT that link said to use ldd to see what libperl.so is referenced in
> the httpd executable. I did that and found NO reference to
Hi Brett,
This question appears to have nothing to do with modperl. I'd suggest
you try the beginners mailing list. You can sign up at
http://learn.perl.org.
William
--
Knowmad Services Inc.
http://www.knowmad.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.a
On Thu, Sep 02, 2004 at 08:03:01AM -0400, Geoffrey Young wrote:
> you could do both - test-driven development. personally, I don't know how I
> ever got along without Apache-Test, for both development and debugging. how
> I wrote applications before seemed insane when compared to using the tools
Hi Ben,
Sorry to hear about the hair loss and damage to your walls. I'm starting
to think that you may be running into a problem that I've hit
before--having an extra libperl.so laying around. Check out this thread
between Stas and myself for more info[1]. I've given you the link to the
last messa
On Tue, Aug 31, 2004 at 08:41:10PM -0700, Ben Hopkins wrote:
> 2: I added /perl-status and got a 404 error, just like I get for
> /server-status, /server-info, and /howdy locations. _It's exactly as if
> mod_perl were not installed!_
>
> Wait a minute! It is exactly as if the "SetHandler" di
On Mon, Aug 30, 2004 at 09:51:14PM -0700, Ben Hopkins wrote:
> I'm running RH 8, apache 1.3.23, mod_perl 1.29.
Hi Ben,
Have you tried compiling with a newer version of Apache? It's up to
release 1.3.31 now. I'm pretty sure that mod_perl 1.29 was released
several months after the release of Apach
Chris,
Randall even has a column about this issue[1] from a couple years ago.
HTH,
William
[1] http://www.stonehenge.com/merlyn/WebTechniques/col64.html
--
Knowmad Services Inc.
http://www.knowmad.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/ma
On Sat, Jul 10, 2004 at 11:33:44AM +0200, [EMAIL PROTECTED] wrote:
> Oops, think I should have told ya something more on why I think DESTROY is not
> handled. Well, that's very easy to say: The lines printed to STDERR from within
> the DESTROY function do not appear in my error_log. Though this:
H
On Tue, Jul 06, 2004 at 01:09:01PM -0400, Geoffrey Young wrote:
> > Geoffrey has also put together a
> > skeleton for testing which I cannot find a link to at present.
>
> http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
>
> while the name indicates it is for bugs, I use it as the
On Fri, Jul 02, 2004 at 05:59:11PM -0400, Perrin Harkins wrote:
> It's on CPAN. Geoffrey Young announced the latest release on this list
> four days ago.
Hi David,
I'd recommend reading Geoffrey's article on perl.com[1] before launching
into the perl.apache.org documentation. Geoffrey has also p
Hi Kemin,
I do not think that your taint problems are related to setgid. My
experience with taint has taught me not to trust the error output. In
this case, you are using ModPerl::Registry which means that your script
could be the one which is supplying tainted data. Are you sure that you
are unta
On Wed, Jun 16, 2004 at 02:03:25PM +0200, Cadman, Andrew (Contractor) wrote:
> Generally, as the scripts were well written few errors were reported and
> these have been dealt with. None of the logs files: - the virtual host log,
> apache general error log or /tmp.db.out (using the Apache::DB in st
On Sun, Jun 13, 2004 at 03:44:22PM -0700, David Arnold wrote:
> When I am working on a cgi-script, sometimes I make a change, then
> "refresh" the script in my browser, only to not see the changes I made in
> the script.
>
> Is there some sort of "caching" going on with Apache?
Hi David,
That ca
On Thu, Apr 22, 2004 at 04:12:51PM -0400, Perrin Harkins wrote:
> Any chance you might be opening the db handle before forking, i.e. in
> your startup.pl? I suspect that would cause problems.
Hi Perrin,
My gut reaction is "Yes, this makes sense." However, I'm scratching my
head trying to underst
Hi Chris,
I sympathize with you. I've been through my share of problems with
BerkeleyDB as well. So far, I haven't had problems using it with
mod_perl. I wrote a stress test tool[1] to prove to myself that
BerkeleyDB was indeed safe to use in concurrent processes. You can set
it to run as many pro
Hi Andy,
I use Apache/mod_perl under FreeBSD. I compile with Apachetoolbox[1]
which is super easy. Here are the custom settings I use:
--suexec-caller=www \
--suexec-docroot=/web \
--disable-rule=EXPAT \
# if using mod_ssl
--enable-rule=EAPI
Otherwise, I let toolbox do the
On Wed, Apr 07, 2004 at 10:37:15AM -0700, Stas Bekman wrote:
> And that's your problem. It picks the wrong perl library. Move it somewhere
> out of /usr/lib and rebuild again, and it'll probably be fine. What is that
> libperl.so?
I didn't consider that route.
> Your real libperl.so if any tha
On Wed, Apr 07, 2004 at 12:39:33AM -0700, Stas Bekman wrote:
> William, why do you check a binary, which is not the one that you get
> the error from? You need to check /usr/local/apache/bin/httpd instead.
> (of course it could be the same binary, but still...)
Because I thought it was the same
Hi List,
I've spent the last several hours trying to figure out the following
error message that I receive with Apache 1.3.29 and mod_perl 1.29:
/usr/local/apache/bin/httpd: relocation error:
/usr/local/apache/bin/httpd: undefined symbol: PL_dowarn
bin/apachectl start: htt
On Tue, Mar 23, 2004 at 12:24:13PM -0600, Brian Clarkson wrote:
> Permissions look OK:
>
> [hostname ] $ ls -al keyfile
> -rw---1 nobody nobody 52 Mar 1 11:22 keyfile
Out of curiosity, have you tried setting the permissions on that keyfile
to 666 to be sure that another pro
On Tue, Mar 23, 2004 at 02:14:44PM -0600, Brian Clarkson wrote:
> I might need to take a look at that patch. The error that shows up is
> from sub authen_ses_key
My patch is attached. I'm not sure it will help much if you're having
problems reading in the key but let me know how it goes.
Hi Brian,
I've had my share of problems with this module as well. I've found the
following two solutions which I submitted to CPAN RT[1]:
1) place the PerlSetVar at the very top of your httpd.conf
2) instead of using PerlModule, use the following:
use Apache::AuthCookie
On Thu, Mar 18, 2004 at 12:27:19PM -0800, Marc Brooks wrote:
> Any suggestions or easy ways to resolve this?
In addition to Ged's suggestion, I'd also recommend reading the
following:
http://perl.apache.org/docs/1.0/guide/porting.html#Sometimes_it_Works__Sometimes_it_Doesn_t
HTH,
William
--
K
On Tue, Mar 16, 2004 at 10:19:33PM -0500, Lehman, Jason (Registrar's Office) wrote:
> My version of MP is 1.99_9-10. I am using a Red Hat Enterprise AS 3.0
> Education Version (so no support) and have been trying to stick with
> their rpm packages because I am new to Linux Administration.
You've
On Tue, Mar 16, 2004 at 04:56:36PM -0500, Lehman, Jason (Registrar's Office) wrote:
> I am getting the error below in my apache logs when someone can't be
> authenticated. If they are authenticated there are no problems.
>
> Can't locate object method "log_reason" via package "Apache::RequestRec"
93 matches
Mail list logo
