Stas,

I downloaded the most current CVS on Sunday night. I still encountered
the same problem, so I decided to examine my configuration further.

I found that the httpd rpm installed on my RH9 was 2.40.xx, not 2.45 as
I had thought. That explains some of the findings of my automated
vulnerability assessment. This machine was a "fresh" RH9 install as of a
few months ago, so the Apache installation was structured "all over the
place" because that's the RH installer default. 

My initial post probably stated that I had 2.45.xx installed. As best I
can tell from some archeology on my install, I had configured but not
installed 45. I recall discovering that the software was installed after
running ./configure - just not where I expected it from my older
RH6/SPARC experience. Obviously I failed to realize that the Apache was
an older version that came with RH9. Being new to RH9 at that point,
it's clear in retrospect that I didn't see the problem. I never did have
2.45 installed at all. As the earlier RH release that I'd worked with
didn't include Apache, I mistakenly concluded that my install had
worked. I proceeded with setup when I should have validated my install
instead.

In order to diagnose the mod_perl version issue, I used my other RH9 box
that's not yet in production. I installed the "official" .47 source.
Same problem, as expected, because both were fresh RH9 installs. Then I
removed all rpms that depended on httpd.2.40.xx, and that rpm as well.
When I reran configure/make/make install for the official 2.47 release,
no problem at all. As the rpm uninstall process removes all files and
renames the config files, there was nothing left to cause version
conflicts.

Your assessment is correct, that the make was picking up files from the
earlier .40 install. My relatively older version of httpd explains why
the mod_perls were so out of sync.

As I didn't want the "all over the place" install that came with RH (my
prior experience with older Apache versions involved install in
/usr/local/apache, as with .47's default), I uninstalled .40 on my
production web box in order to install .47 properly.

Thus I did not do a thorough test of your fix. Apologies. I needed to
get my web box upgraded to close several security issues, thus could not
continue chasing down the details of my install problem.

It may be worth adding a few notes in the INSTALL file for RH9 that RH's
installer distributes its included version of Apache to /etc,
/usr/local/bin, etc., which can create version conflicts when installing
newer versions of httpd in the default directory (/usr/local/apache2).
(The same problem may occur under earlier versions of RH as well. Others
more familiar with RH 7 & 8 need to be consulted.) Uninstallation is
recommended in order to avoid make picking up wrong libraries; and to
locate the entire Apache install under a single directory in /usr/local
for ease of administration. Having used the RH style of installation, I
recommend converting to the Apache default (all in one directory) even
on fresh new RH installs. It is worth the small effort, and saves much
tail chasing for those (like myself) who are not expert enough to
identify why they are causing their own problems!!

Thanks much for all of your assist on this!

Robert Shelton


-----Original Message-----
From: Stas Bekman [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 08, 2003 7:37 PM
Cc: Robert E. Shelton; mod_perl Mailing List
Subject: Re: mod_perl.c version for httpd 2.0.47


Stas Bekman wrote:

>> 2. Having completed the first step of the build (perl Makefile.pl...)

>> I am back to the second error as reported in my original post. It 
>> occurs in the test cycle of the make && make test phase, as follows:
>>
>>
>> /usr/local/apache2/bin/httpd  -d /root/modperl-2.0/t -f 
>> /root/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS 
>> using Apache/2.0.47 (prefork MPM)
>>  
>> waiting for server to start: .Syntax error on line 11 of
>> /root/modperl-2.0/t/conf/httpd.conf:
>> module access_module is built-in and can't be loaded
>> !!!
>> server has died with status 255 (t/logs/error_log wasn't created, 
>> start the server in the debug mode)
>> make: *** [run_tests] Error 143
>> [EMAIL PROTECTED] modperl-2.0]#
>>
>> Before I start hacking at files used to generate the test conf, I 
>> need to understand what's up. Prior to running the make, I stopped my

>> .45 version of httpd and removed the earlier mod_perl library. Am I 
>> running in to other modules that I need to remove before running 
>> make?
> 
> 
> What happens is that Apache::Test tries to inherit the configuration
> from the system-wide httpd.conf. So if you have any LoadModule 
> directives, it'll move them to t/conf/httpd.conf that it generates.
> 
> I think what happened in your case is that you previously has built
> httpd with  shared objects (one of them was mod_access.c), so it
created 
> the global httpd.conf with directive 'LoadModule access_module 
> mod_access.so', next you probably built httpd again but this time has 
> compiled mod_access statically. However when you run 'make install', 
> apache build system won't overwrite the existing httpd.conf file, so
you 
> have left with invalid directives in the file.
> 
> I'm pretty sure that if you try to start httpd normally (without
> mod_perl) it'll fail with the same error. If that's the case, just
nuke 
> that global httpd.conf and run 'make install' from the httpd-2.0.47 
> directory again. then return to run 'make test' in the mod_perl
directory.
> 
> Meanwhile I'll patch Apache::Test to put LoadModule directives inside
> <IfModule ...> so this problem affect Apache::Test.

The current cvs should now handle this "user" problem transparently

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Reply via email to