You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jon <jo...@3ev.com> on 2003/01/15 14:32:30 UTC
Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
I'm new to mod_perl, and was having fun tinkering with mod_perl-1.99_05-3
on Red Hat 8 (Perl 5.8.0 / Kernel 2.4.18-17.8.0 on an i686 /
Apache/2.0.40), installed from RPM's.
I wanted to get the older Apache:: modules to work, I noted that the ones i
wanted came with mod_perl-1.27, and made the (*very* bad) decision of
trying to install the old version and getting mod_perl2 to work in
'compatibility mode'. So I tried to install 1.27 from the binary which of
course required Apache 1.3, which I had - but not the sources. This
resulted in a broken mod_perl installation and me only having some of the
modules I required, which of course mostly fail anyway due to dependency
issues.
I dont think I can install from mod_perl-1.99_08.tar.gz: I hunted for a
value for MP_AP_PREFIX - it's probably due to me having installed Apache
from an RPM, but there is no path "under which the include/ directory with
Apache C header files can be found" that I can find - something a bit more
concrete to feed into 'slocate' or 'find' might help here.
Apache/2.0.40 Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
[snip]
Also now the RPM is broken:
[root@fooTowers public]# rpm -e --nodeps mod_perl-1.99_05-3.i386.rpm
error: package mod_perl-1.99_05-3.i386.rpm is not installed
[root@fooTowers public]# rpm -ivh mod_perl-1.99_05-3.i386.rpm
Preparing... ########################################### [100%]
package mod_perl-1.99_05-3 is already installed
Niiiiice.
Essentially I just want to get mod_perl 2 working again and forget using
the old Apache:: modules, either using the 1.99_08 binary or the 1.99_05-3
RPM. Any suggestions much appreciated!
TIA,
Jon
Re[2]: Newbie advice required [some further info]
Posted by Seldo <ne...@seldo.com>.
On 06 February 2003, Stas Bekman wrote:
SB> Have you configured your server to run .php files by php?
>From httpd.conf: AddType application/x-httpd-php .php
(which is a yes as far as I'm concerned, but taking no chances...)
SB> Does a request to /bob.php works fine if requested directly (when
SB> you don't have your PerlTransHandler installed?
Yep, it works fine.
SB> Does it work for other handlers? e.g.:
$r->>uri("/perl/bob.pl");
SB> assuming that you have /perl configured to run ModPerl::Registry?
Hmm, that was illuminating -- that works fine too! And PHP is indeed a
filter in 2.0, as you say (unlike perl). So the problem is either
PHP-specific, or a problem with filters... gah. I'm going to bed now,
but at least I have a new line of attack to try in the morning.
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
Bart's Blackboard: "I will not strut around like I own the place."
Re: Newbie advice required [some further info]
Posted by Stas Bekman <st...@stason.org>.
Seldo wrote:
> I mentioned that I don't think there's a way to practically supply
> arbitrary data to Apache that looks like its coming from the
> filesystem. The other way I thought of is this:
>
> $r->uri() can map one URI to another. This means that a request to
> www.mydomain.com/app1/site/page.php
> could be remapped by my module to call app1.exe "/site/page.php" (i.e.
> using the remainder of the path as a parameter to determine what data
> to supply. This works, but it means extension-based handlers like PHP
> probably won't be activated -- how can I get around that, short of
> manually coding support for every requested file type?
Have you configured your server to run .php files by php?
> Also, the following code used as a PerlTransHandler sends the server
> into what looks like an endless loop:
>
> ----
> package Seldo::MaskURI;
> use strict;
> use warnings;
> use Apache::RequestRec ();
> use Apache::Const -compile => qw(DECLINED);
>
> sub handler {
> my $r = shift;
> $r->uri("/bob.php");
>
> return Apache::DECLINED;
> }
> 1;
> ----
>
> The code is supposed to perform the (nonsensical) task of returning
> "bob.php" no matter what URL the server is given. If ".php" is changed
> to ".html" it works, but as I say, having it as .php throws it for
> six. Anybody know why? It's possible there's something really obvious
> wrong -- like I said, I barely know perl, far less mod_perl.
Does it work for other handlers? e.g.:
$r->uri("/perl/bob.pl");
assuming that you have /perl configured to run ModPerl::Registry?
Does a request to /bob.php works fine if requested directly (when you don't
have your PerlTransHandler installed?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re[3]: Newbie advice required [some further info]
Posted by Seldo <ne...@seldo.com>.
I mentioned that I don't think there's a way to practically supply
arbitrary data to Apache that looks like its coming from the
filesystem. The other way I thought of is this:
$r->uri() can map one URI to another. This means that a request to
www.mydomain.com/app1/site/page.php
could be remapped by my module to call app1.exe "/site/page.php" (i.e.
using the remainder of the path as a parameter to determine what data
to supply. This works, but it means extension-based handlers like PHP
probably won't be activated -- how can I get around that, short of
manually coding support for every requested file type?
Also, the following code used as a PerlTransHandler sends the server
into what looks like an endless loop:
----
package Seldo::MaskURI;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::Const -compile => qw(DECLINED);
sub handler {
my $r = shift;
$r->uri("/bob.php");
return Apache::DECLINED;
}
1;
----
The code is supposed to perform the (nonsensical) task of returning
"bob.php" no matter what URL the server is given. If ".php" is changed
to ".html" it works, but as I say, having it as .php throws it for
six. Anybody know why? It's possible there's something really obvious
wrong -- like I said, I barely know perl, far less mod_perl.
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
My friend drowned in a bowl of muesli. He was pulled in by a strong currant.
Re: Newbie advice required
Posted by Honza Pazdziora <ad...@informatics.muni.cz>.
On Wed, Feb 05, 2003 at 11:45:09PM +0000, Seldo wrote:
>
> Ideally, it would be the former. Literally, I want all the files the
> users to come from one or another of a set of applications. The
> applications will return data in response to a URL: that data might
> be flat HTML, it might be PHP, or for some URLs it might be binary
> data. I don't want it to matter: I want the server to handle the
> content *as if it had just come from the filesystem*.
Well, if the data returned do not change as wildly, you might as well
get the output from other application and store it in the filesystem
cache. And then jsut work with ordinary files. Might also give you
some performance boost. Of course, if every request (for the same URI)
gives different result, this approach might not be as prctical, YMMV.
To be honest, I also would be very interested in knowing, if 2.0 can
handle all data sources transparently ...
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
... all of these signs saying sorry but we're closed ...
------------------------------------------------------------------------
Re: Newbie advice required
Posted by Stas Bekman <st...@stason.org>.
Seldo wrote:
> Whoa, quick turnaround! Oof course, it's 11pm here, but only 6pm where
> you are I suppose...
It's actually 11am, on your tomorrow (PDT+11) ;) I'm living in the future ;)
> On 05 February 2003, Stas Bekman wrote:
> SB> You forgot to add to unfortunate facts that both mod_perl 2.0 and
> SB> Apache 2.0 are new and may have bugs ;)
>
>>>From what I could tell, doing this with Apache 1.3 is even more
> daunting, since it didn't really have the concept of filters ironed
> out.
True.
[...]
> SB> Assuming that you have a set of filters which do the work, it's
> SB> easy. e.g. I think php in 2.0 is an output filter, so you should
> SB> just dynamically insert the php filter when you figure out that
> SB> the content is php. HTML/text is easy. SSI is a filter, so covered
> SB> too. What other processors do you need?
>
> That's the thing. This application has to be flexible: I don't want to
> have to explicitly support file types; I simply want to supply the
> server with data that looks like a file and have it treat that data
> exactly as it would any other file.
The simplest way would be to save the extracted data into a file, and set
$r->filename to point to that file, and let the Apache core handle that. If
you want it to be smarter, but more complex, read on.
> However, I have a feeling this might be impractical, so alternate
> suggestions are welcome :-) At this point I feel I should be doing
> some kind of I-am-a-clueless-newbie dance. I am totally out of my
> depth, and this project is due in 3 weeks! *bursts into semi-panicked
> laughter*. Um. Yeah :-)
Well, we are all new to this thing so *you* are the one who has to be the
inventor.
In short, if all possible applications can be invoked as filters you should be
all set.
text/html: just send it out
text/plain: ditto
mod_perl: compile the handler (assuming that the code is coming from the db)
and configure the handler to be modperl/perl-script or set the
PerlResponseHandler to the one you've just compiled
exe: save the data in a file, and set $r->filename to it. Apache will do the rest.
php: though I haven't tried it, the php filter probably accepts its code as an
input to a filter. you have to check that though.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re[2]: Newbie advice required
Posted by Seldo <ne...@seldo.com>.
Whoa, quick turnaround! Oof course, it's 11pm here, but only 6pm where
you are I suppose...
On 05 February 2003, Stas Bekman wrote:
SB> You forgot to add to unfortunate facts that both mod_perl 2.0 and
SB> Apache 2.0 are new and may have bugs ;)
>From what I could tell, doing this with Apache 1.3 is even more
daunting, since it didn't really have the concept of filters ironed
out.
>> I want app1.exe (or whatever) to retrieve a file / run a database
>> query / do some processing and return some output.
SB> Do you say that the actual code resides in the database? So you
SB> want to fool Apache as if the code existed on the filesystem? Or
SB> does your database returns paths to the real files?
Well... to be honest, whichever is easier. I'm not that far along :-)
Ideally, it would be the former. Literally, I want all the files the
users to come from one or another of a set of applications. The
applications will return data in response to a URL: that data might
be flat HTML, it might be PHP, or for some URLs it might be binary
data. I don't want it to matter: I want the server to handle the
content *as if it had just come from the filesystem*.
SB> You mean PerlTransHandler, right? You are on the right track then.
Yes, I mean PerlTransHandler. Yay! Not completely bonkers then...
>> 2. Why would setting $r->uri() to a .php file be any different to
>> the rest of the server than setting it to a .html file?
SB> If you don't have a real file with the content you probably need
SB> to rely on output filters.
>> 3. How to ensure that the server treats the output of an
>> application the same as it does a file, i.e. applying all the
>> necessary handlers etc?
SB> Assuming that you have a set of filters which do the work, it's
SB> easy. e.g. I think php in 2.0 is an output filter, so you should
SB> just dynamically insert the php filter when you figure out that
SB> the content is php. HTML/text is easy. SSI is a filter, so covered
SB> too. What other processors do you need?
That's the thing. This application has to be flexible: I don't want to
have to explicitly support file types; I simply want to supply the
server with data that looks like a file and have it treat that data
exactly as it would any other file.
However, I have a feeling this might be impractical, so alternate
suggestions are welcome :-) At this point I feel I should be doing
some kind of I-am-a-clueless-newbie dance. I am totally out of my
depth, and this project is due in 3 weeks! *bursts into semi-panicked
laughter*. Um. Yeah :-)
Thanks again!
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
If idiots could fly, IRC servers would be airports.
Re: Newbie advice required
Posted by Stas Bekman <st...@stason.org>.
Seldo wrote:
> Hello everyone -
>
> I'm in the unfortunate position of being needing to write an Apache
> 2.0 module using mod_perl 2.0, while being simultaneously new to both
> mod_perl, the Apache API, and perl itself. I guess I'm a glutton for
> punishment, or something. (Did I mention this is all on Win32?)
You forgot to add to unfortunate facts that both mod_perl 2.0 and Apache 2.0
are new and may have bugs ;) But on the other hand you are the fortunate one
to be one of the first to embrace the new platform. What doesn't kill you
makes you stronger ;)
> What I want my module to be able to do is to substitute content from
> various plug-in applications as the response to various URLs. For
> example, if the user requests
> www.mydomain.com/app1/file
> I want app1.exe (or whatever) to retrieve a file / run a database
> query / do some processing and return some output.
Do you say that the actual code resides in the database? So you want to fool
Apache as if the code existed on the filesystem? Or does your database returns
paths to the real files?
> Importantly, I
> *then* want the rest of Apache to treat this file as if it had come
> from the file system, e.g. it it's a .php file I still want PHP to
> handle it, if there are any other handlers assigned I still want them
> to handle it. In short, this substitution has to be completely
> transparent. (This should be possible by returning Apache::DECLINED,
> but it doesn't seem to work like that, see below)
>
> Now, I know it's possible to configure Apache with app1.exe as a
> handler for /app1, etc.. What I'm creating is a single module that
> handles *all* URLs (i.e. handles "/"), and manages the mapping itself.
>
> So far, I think the best way to do this is to create a URI translation
> handler module which will simply use $r->uri() to call the application
> with whatever data and parameters it needs.
You mean PerlTransHandler, right? You are on the right track then.
> First question:
>
> 1. Is this really the best way to supply the server with content that
> comes from elsewhere than simply the file system?
>
> I've written a simple translator which can return .html files, but if
> I set the uri to a .php file the server seems to go into a loop (I've
> been unable to diagnose what's actually happening).
>
> 2. Why would setting $r->uri() to a .php file be any different to the
> rest of the server than setting it to a .html file?
>
> and finally
If you don't have a real file with the content you probably need to rely on
output filters.
> 3. How to ensure that the server treats the output of an application
> the same as it does a file, i.e. applying all the necessary handlers
> etc?
Assuming that you have a set of filters which do the work, it's easy. e.g. I
think php in 2.0 is an output filter, so you should just dynamically insert
the php filter when you figure out that the content is php. HTML/text is easy.
SSI is a filter, so covered too. What other processors do you need?
> Any and all advice appreciated, including "You fool! This already
> exists!" :-)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Newbie advice required
Posted by Seldo <ne...@seldo.com>.
Hello everyone -
I'm in the unfortunate position of being needing to write an Apache
2.0 module using mod_perl 2.0, while being simultaneously new to both
mod_perl, the Apache API, and perl itself. I guess I'm a glutton for
punishment, or something. (Did I mention this is all on Win32?)
What I want my module to be able to do is to substitute content from
various plug-in applications as the response to various URLs. For
example, if the user requests
www.mydomain.com/app1/file
I want app1.exe (or whatever) to retrieve a file / run a database
query / do some processing and return some output. Importantly, I
*then* want the rest of Apache to treat this file as if it had come
from the file system, e.g. it it's a .php file I still want PHP to
handle it, if there are any other handlers assigned I still want them
to handle it. In short, this substitution has to be completely
transparent. (This should be possible by returning Apache::DECLINED,
but it doesn't seem to work like that, see below)
Now, I know it's possible to configure Apache with app1.exe as a
handler for /app1, etc.. What I'm creating is a single module that
handles *all* URLs (i.e. handles "/"), and manages the mapping itself.
So far, I think the best way to do this is to create a URI translation
handler module which will simply use $r->uri() to call the application
with whatever data and parameters it needs. First question:
1. Is this really the best way to supply the server with content that
comes from elsewhere than simply the file system?
I've written a simple translator which can return .html files, but if
I set the uri to a .php file the server seems to go into a loop (I've
been unable to diagnose what's actually happening).
2. Why would setting $r->uri() to a .php file be any different to the
rest of the server than setting it to a .html file?
and finally
3. How to ensure that the server treats the output of an application
the same as it does a file, i.e. applying all the necessary handlers
etc?
Any and all advice appreciated, including "You fool! This already
exists!" :-)
Seldo.
____________________________________________
Seldo Voss: www.seldo.com
ICQ #1172379 or me@seldo.com
--------------------------------------------
To know the road ahead, ask those coming back.
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8
[mp2]
Posted by Jon <jo...@3ev.com>.
(Just an informational post to round off the thread.)
The following worked for me, I now have a working mod_perl 1.99!
At 15:08 15/01/2003 +0100, Jérôme Augé wrote:
>To compile mod_perl-1.99_xx on RedHat 8.0 I used :
>
>$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
>
>First, I removed the original mod_perl-1.99_05 RPMS then I compiled and
>installed the newer one.
Many thanks Jérôme, also Stas, and Paul for the advice on ditching the
RPM's :o)
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
Posted by Stas Bekman <st...@stason.org>.
Jon wrote:
> At 16:34 15/01/2003 +0100, Jérôme Augé wrote:
>
>> You must install the "httpd-devel" package, /usr/sbin/apxs is in this
>> package.
>
>
> OK, I've installed this, but I would like one more go at getting the RPM
> working, so I don't get more problems when the next RPM is released - I
> guess I have to choose one method to follow, but am more used to dealing
> with RPM's.
>
>> > I reinstalled the mod_perl-1.99_05-3 RPM thinking that might give me
>> less
>> > problems, it looked OK but now:
>> >
>> > [Wed Jan 15 14:37:02 2003] [error] failed to resolve handler
>> > `ModPerl::Registry::handler'
>> > [Wed Jan 15 14:43:12 2003] [error] [client 192.168.1.30] Can't locate
>> > ModPerl/Registry/handler.pm in @INC (@INC contains: [snip]
Try with the 99_08 version.
it should be pretty easy to grab the src package for mod_perl-1.99_05-3,
rpm -i it, replace the modperl tar.gz in the SOURCES dir, adjust the spec
file and rebuild a new package.
But I'd go with the build from source. At least to get you going.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
Posted by Paul Simon <wr...@yahoo.com>.
--- Jon <jo...@3ev.com> wrote:
> This RPM was working before, so all my messing
> around has broken something
> I can't find. If the recommendation is to ditch the
> RPM and proceed with
> the new binary then that's fine.
>
> thanks again, jon
>
Red Hat's RPM seems very friendly at first then it
turns into the devil from hell, at least for me :) I
had the same problem as you when installing Perl 5.8
and apache/mod_perl on RH 7.1 using RPM. Everything
was a dependency issue and got F'ed up. I finally
learned how to build from source...
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8
[mp2]
Posted by Jon <jo...@3ev.com>.
At 16:34 15/01/2003 +0100, Jérôme Augé wrote:
>You must install the "httpd-devel" package, /usr/sbin/apxs is in this
>package.
OK, I've installed this, but I would like one more go at getting the RPM
working, so I don't get more problems when the next RPM is released - I
guess I have to choose one method to follow, but am more used to dealing
with RPM's.
> > I reinstalled the mod_perl-1.99_05-3 RPM thinking that might give me less
> > problems, it looked OK but now:
> >
> > [Wed Jan 15 14:37:02 2003] [error] failed to resolve handler
> > `ModPerl::Registry::handler'
> > [Wed Jan 15 14:43:12 2003] [error] [client 192.168.1.30] Can't locate
> > ModPerl/Registry/handler.pm in @INC (@INC contains: [snip]
> >
> > ... this is using the default conf.d/perl.conf that comes with the RPM
> (all
> > I changed was the <Directory ...> location to one which used to work):
> >
> > LoadModule perl_module modules/mod_perl.so
> > # [snip]
> > <Directory /home/httpd/html/mp>
> > SetHandler perl-script
> > PerlHandler ModPerl::Registry::handler
> > PerlOptions +ParseHeaders
> > Options +ExecCGI
> > </Directory>
> >
> > @INC includes /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
> > and I have:
> >
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/ModPerl/Registry.pm
> >
> > .... but this is going into the realms of general Perl questions ...
> >
> > I'm wondering what I need to tweak to get the RPM to work, or a working
> > parameter to pass to Makefile.PL
> >
>
>Did you stopped and restarted httpd after installing the package ?
I did, and the log showed the normal startup messages with no errors.
I also tried creating a handler, as per "Getting Your Feet Wet with
mod_perl" and again it failed to resolve the handler. And again I could
see the path in @INC, the module was chown'ed to the user apache is running
as, and it has wide-open file permissions.
This RPM was working before, so all my messing around has broken something
I can't find. If the recommendation is to ditch the RPM and proceed with
the new binary then that's fine.
thanks again, jon
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
Posted by Jérôme Augé <ja...@club-internet.fr>.
On Wed, Jan 15, 2003 at 03:07:14PM +0000, Jon wrote:
>
> I have now uninstalled the RPM, but unfortunately:
>
> [root@fooTowers mod_perl-1.99_08]# perl Makefile.PL MP_APXS=/usr/sbin/apxs
> Reading Makefile.PL args from @ARGV
> MP_APXS = /usr/sbin/apxs
> !!! Unable to determine server version, aborting.
> !!! Invalid MP_APXS specified?
>
> The only filename containing apxs is in the Apache manual. (I have mod_so
> compiled in to the httpd.)
>
You must install the "httpd-devel" package, /usr/sbin/apxs is in this
package.
> I reinstalled the mod_perl-1.99_05-3 RPM thinking that might give me less
> problems, it looked OK but now:
>
> [Wed Jan 15 14:37:02 2003] [error] failed to resolve handler
> `ModPerl::Registry::handler'
> [Wed Jan 15 14:43:12 2003] [error] [client 192.168.1.30] Can't locate
> ModPerl/Registry/handler.pm in @INC (@INC contains: [snip]
>
> ... this is using the default conf.d/perl.conf that comes with the RPM (all
> I changed was the <Directory ...> location to one which used to work):
>
> LoadModule perl_module modules/mod_perl.so
> # [snip]
> <Directory /home/httpd/html/mp>
> SetHandler perl-script
> PerlHandler ModPerl::Registry::handler
> PerlOptions +ParseHeaders
> Options +ExecCGI
> </Directory>
>
> @INC includes /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
> and I have:
> /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/ModPerl/Registry.pm
>
> .... but this is going into the realms of general Perl questions ...
>
> I'm wondering what I need to tweak to get the RPM to work, or a working
> parameter to pass to Makefile.PL
>
Did you stopped and restarted httpd after installing the package ?
--
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8
[mp2]
Posted by Jon <jo...@3ev.com>.
Many thanks for your reply Jérôme :)
I have now uninstalled the RPM, but unfortunately:
[root@fooTowers mod_perl-1.99_08]# perl Makefile.PL MP_APXS=/usr/sbin/apxs
Reading Makefile.PL args from @ARGV
MP_APXS = /usr/sbin/apxs
!!! Unable to determine server version, aborting.
!!! Invalid MP_APXS specified?
The only filename containing apxs is in the Apache manual. (I have mod_so
compiled in to the httpd.)
I reinstalled the mod_perl-1.99_05-3 RPM thinking that might give me less
problems, it looked OK but now:
[Wed Jan 15 14:37:02 2003] [error] failed to resolve handler
`ModPerl::Registry::handler'
[Wed Jan 15 14:43:12 2003] [error] [client 192.168.1.30] Can't locate
ModPerl/Registry/handler.pm in @INC (@INC contains: [snip]
.. this is using the default conf.d/perl.conf that comes with the RPM (all
I changed was the <Directory ...> location to one which used to work):
LoadModule perl_module modules/mod_perl.so
# [snip]
<Directory /home/httpd/html/mp>
SetHandler perl-script
PerlHandler ModPerl::Registry::handler
PerlOptions +ParseHeaders
Options +ExecCGI
</Directory>
@INC includes /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
and I have:
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/ModPerl/Registry.pm
... but this is going into the realms of general Perl questions ...
I'm wondering what I need to tweak to get the RPM to work, or a working
parameter to pass to Makefile.PL
jon
At 15:08 15/01/2003 +0100, you wrote:
>On Wed, Jan 15, 2003 at 01:32:30PM +0000, Jon wrote:
> >
> > I'm new to mod_perl, and was having fun tinkering with mod_perl-1.99_05-3
> > on Red Hat 8 (Perl 5.8.0 / Kernel 2.4.18-17.8.0 on an i686 /
> > Apache/2.0.40), installed from RPM's.
> >
> > I wanted to get the older Apache:: modules to work, I noted that the
> ones i
> > wanted came with mod_perl-1.27, and made the (*very* bad) decision of
> > trying to install the old version and getting mod_perl2 to work in
> > 'compatibility mode'. So I tried to install 1.27 from the binary which of
> > course required Apache 1.3, which I had - but not the sources. This
> > resulted in a broken mod_perl installation and me only having some of the
> > modules I required, which of course mostly fail anyway due to dependency
> > issues.
> >
> > I dont think I can install from mod_perl-1.99_08.tar.gz: I hunted for a
> > value for MP_AP_PREFIX - it's probably due to me having installed Apache
> > from an RPM, but there is no path "under which the include/ directory with
> > Apache C header files can be found" that I can find - something a bit more
> > concrete to feed into 'slocate' or 'find' might help here.
> >
>
>To compile mod_perl-1.99_xx on RedHat 8.0 I used :
>
>$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
>
>First, I removed the original mod_perl-1.99_05 RPMS then I compiled and
>installed the newer one.
>
> >
> > Also now the RPM is broken:
> >
> > [root@fooTowers public]# rpm -e --nodeps mod_perl-1.99_05-3.i386.rpm
> > error: package mod_perl-1.99_05-3.i386.rpm is not installed
> > [root@fooTowers public]# rpm -ivh mod_perl-1.99_05-3.i386.rpm
> > Preparing... ###########################################
> > [100%]
> > package mod_perl-1.99_05-3 is already installed
> >
>
>The package name is "mod_perl-1.99_05-3" and not
>"mod_perl-1.99_05-3.i386.rpm" (remove the ".i386.rpm" extension).
>So, to remove the package you should use :
>
>$ rpm --erase --nodeps mod_perl-1.99_05-3
>
>--
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
Posted by Jérôme Augé <ja...@club-internet.fr>.
On Wed, Jan 15, 2003 at 01:32:30PM +0000, Jon wrote:
>
> I'm new to mod_perl, and was having fun tinkering with mod_perl-1.99_05-3
> on Red Hat 8 (Perl 5.8.0 / Kernel 2.4.18-17.8.0 on an i686 /
> Apache/2.0.40), installed from RPM's.
>
> I wanted to get the older Apache:: modules to work, I noted that the ones i
> wanted came with mod_perl-1.27, and made the (*very* bad) decision of
> trying to install the old version and getting mod_perl2 to work in
> 'compatibility mode'. So I tried to install 1.27 from the binary which of
> course required Apache 1.3, which I had - but not the sources. This
> resulted in a broken mod_perl installation and me only having some of the
> modules I required, which of course mostly fail anyway due to dependency
> issues.
>
> I dont think I can install from mod_perl-1.99_08.tar.gz: I hunted for a
> value for MP_AP_PREFIX - it's probably due to me having installed Apache
> from an RPM, but there is no path "under which the include/ directory with
> Apache C header files can be found" that I can find - something a bit more
> concrete to feed into 'slocate' or 'find' might help here.
>
To compile mod_perl-1.99_xx on RedHat 8.0 I used :
$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
First, I removed the original mod_perl-1.99_05 RPMS then I compiled and
installed the newer one.
>
> Also now the RPM is broken:
>
> [root@fooTowers public]# rpm -e --nodeps mod_perl-1.99_05-3.i386.rpm
> error: package mod_perl-1.99_05-3.i386.rpm is not installed
> [root@fooTowers public]# rpm -ivh mod_perl-1.99_05-3.i386.rpm
> Preparing... ###########################################
> [100%]
> package mod_perl-1.99_05-3 is already installed
>
The package name is "mod_perl-1.99_05-3" and not
"mod_perl-1.99_05-3.i386.rpm" (remove the ".i386.rpm" extension).
So, to remove the package you should use :
$ rpm --erase --nodeps mod_perl-1.99_05-3
--