Apache and Perl togheter
Hello can some help me pelase? i've recently installed Apace 1.3.22...i've configured the CGI directive to work as well but when i try to execute a CGI script written in perl that message appears: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log The CGI script is a stupid test hello world CGI script ... Script written in sh script work. Can someone solve my problem please... Thx to all Alan
Re: Apache and Perl togheter
On Wed, 9 Jan 2002, Alan Civita wrote: More information about this error may be available in the server error log Try reading the text :-) -- !-- Matt -- :-Get a smart net/:-
Re: Apache and Perl togheter
Alan Civita wrote: Hello can some help me pelase? i've recently installed Apace 1.3.22...i've configured the CGI directive to work as well but when i try to execute a CGI script written in perl that message appears: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log have you checked the error log? /Jon The CGI script is a stupid test hello world CGI script ... Script written in sh script work. Can someone solve my problem please... Thx to all Alan
Apache and Perl togheter
is it possible that i have to do something special in compiling apache to activate the perl mode?
Re: Apache and Perl togheter
Alan Civita wrote: is it possible that i have to do something special in compiling apache to activate the perl mode? have you read at perl.apache.org? or about executing cgi's in apache? /Jon
Re: Apache and Perl togheter
Alan Civita wrote: Surely... and I've done all of it... ..have i to use sonme particular option during the configuration and installation of apache in order to use/enable the perl in Apache? thx again Alan, For basic CGI under apache, you will need to make sure your scripts print out the following before sending anything else: Content-type: text/html\n\n If they dont, you will get internal server error. Take a look at the perl CGI module in CPAN. It should get you started with creating some reasonably complex cgi apps. If you have any problems or questions about CGI, direct them to the perl beginners list. Once you've mastered the basics of CGI, check out http://perl.apache.org/guide for an intro to using mod_perl for increased performance and flexibility. Please do take a look at the error_log and if you dont understand what it means, then cut and paste the line you dont understand into Google and hit search. It will usually come up with an email discussion about your exact problem. I have included a hello world script that should work: #!/usr/bin/perl print Content-type: text/html\n\n; print CENTERH1Hello world!/H1/CENTER\n;
Re: Apache and Perl togheter
El Mié 09 Ene 2002 10:00, Alan Civita escribió: Hello can some help me pelase? i've recently installed Apace 1.3.22...i've configured the CGI directive to work as well but when i try to execute a CGI script written in perl that message appears: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log The CGI script is a stupid test hello world CGI script ... Script written in sh script work. Can someone solve my problem please... Thx to all Alan Alan As i understand what you are doing is nothing perl related, what you are using is apache module mod_cgi compiled in by default in apache. You must check if your script compiles and run from the shell: #cd youtscritpsdir #perl -wc myscript.pl #perl myscript.pl #chmod 755 myscript.pl #./myscript .pl If all this works you defionitely must check your error_log Hans Poo
Re: [error] Cannot remove module mod_perl.c: not found in modulelist
On Wed, 9 Jan 2002, cloudor wrote: I get the message shown as [error] Cannot remove module mod_perl.c: not found in module list when i restart apache after installing mod_perl and adding LoadModule perl_module modules/mod_perl.so in the httpd.conf . [ ... ] Do you have a directive ClearModuleList enabled somewhere in your httpd.conf? If so, try commenting it out (as well as any AddModule ... directives) and see if that helps. best regards, randy kobes
BSD::Resource und apache/mod_perl
hi...
I use BSD::Resource to limit the RAM a mod_perl process could get. this
works perfectly right on one machine but on another the process does not
get any RAM at all and is killed immediately. both servers run under
linux and therefor I use RLIMIT_AS as described in the mod_perl guide
from stas bekman:
http://thingy.kcilink.com/modperlguide/performance/OS_Specific_notes.html
The following test script works as it should if it runs from the shell
(means: it runs a while, then it stops with Out of memory error!):
#!/usr/bin/perl
print Content-type: text/html\n\ntest...;
use BSD::Resource;
setrlimit RLIMIT_AS, 3200, 6400;
for($i=0; $i600; $i++)
{
$a.=dsafadsfadsfadfhakdhfkjaf;
}
print ok;
but it stops IMMEDIATELY with out of memory/document contains no
data if called via browser from apache/mod_perl. (it has nothing to do
with forecasting: if the loop iterations are set lower (i.g. to 1) the
script should give test...ok but it stops immediately with out of
memory as well)
has anybody any ideas?
thanx in advance, best regards,
christoph bergmann
Re: BSD::Resource und apache/mod_perl
has anybody any ideas? Apache::Resource.
Re: [ANNOUNCE] Apache::AppCluster 0.2
Gunther Birznieks wrote: Is this a lot different from PlRPC? Perhaps this should be a transport layer that is added to PlRPC rather than creating a brand-new service? Ideally it would be nice if it were architected with mod_perl and HTTP being the default mechanism of transport but that if you wanted to, you could make it into a standalone Perl daemon that forked by itself. The difference is that AppCluster allows you to call multiple remote methods on the server (or on multiple distributed servers) simultaneously. However, I wasn't aware of PlRPC and I really like the interface i.e. the way it creates a copy of the remote object locally and allows you to call methods on it as if it were just another object. I could not do this with AppCluster without sacrificing the concurrency it offers. At present you create a single appcluster object and then register the method calls you would like it to call, one by one. You then call a single method (with a timeout) that calls all registered remote methods simultaneously. (It uses non-blocking IO and so provides concurrency in a single thread of execution) re: allowing the server to be a standalone daemon that forks by itself. This project actually started exactly like that. I grabbed the pre-forking server example from the Cookbook and used that as the basis for the server. I found that performance was horrible though, because forking additional servers took too long and I also was using DBI and I missed Apache::DBI (and all the other great apache::* mods) too much. So I used a good solid server that offers a great Perl persistence engine. I'm not sure why anyone would want to roll their own server in Perl. If there is a reason, then I could change the server class to create a server abstraction layer of some kind. ~mark.
mod_perl : HELP (am I going nuts ?)
The following short test script :
#!/usr/local/bin/perl
use strict;
use Apache;
my $r = shift;
my %params = $r-method eq 'POST' ? $r-content : $r-args;
$r-send_http_header('text/html');
print Name = [, $params{'Name'}, ]br /;
print R = [ , $r, ]br /;
print Mehtod = [, $r-method, ]br /;
print Content = [, $r-content, ]br /;
print Args = [, $r-args, ]br /;
Now lets say I goto http://www.dev.p6m7g8.com/perl-reg/test.pl?Name=p6m7g8
which is the above file
Gives output :
Name = []
R = [Apache=SCALAR(0x80d3aac)]
Mehtod = [GET]
Content = []
Args = []
Comming from CGI.pm, I know you can pass parameters like the Name(above) for
urls, but with mod_perl (aka Apache::*) All I can get at are variables inside
form/form in an html page.
Am I missing something, am I going nuts ?
PLEASE PLEASE TELL ME WHAT I AM NOT DOING RIGHT HERE !
Thanks in advance for all you kind souls out there!
I have read almost all of but most especialy
http://perl.apache.org/guide/snippets.html#CGI_params_in_the_mod_perl_ish_
If I need to read something else please point me there
My System configuration follows:
uname -a
FreeBSD sduwebship.student.umd.edu 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Jan
8 03:41:06 GMT 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/WEBSHIP i386
perl -v
This is perl, v5.6.1 built for i386-freebsd
Apache/1.3.22 (Unix) mod_python/2.7.6 Python/2.1.1 PHP/4.0.6 mod_perl/1.26
mod_ssl/2.8.5 OpenSSL/0.9.6b
httpd.conf [snipped]
PerlRequire /usr/local/www/apache/conf/startup.pl
Location /perl-status
SetHandler perl-script
PerlHandler Apache::Status
order deny,allow
deny from all
allow from .student.umd.edu
/Location
Include conf/vhosts.conf
conf/vhosts.conf [snipped]
# START MOD_PERL #
Alias /perl-reg/ /usr/local/sites/dev/perl-reg/
PerlModule Apache::Registry
Location /perl-reg
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
startup.pl [entirety]
use strict;
# Make sure we are in a sane environment.
$ENV{MOD_PERL} or die not running under mod_perl!;
# For things in the /perl-reg and /perl-run URL
use Apache::Status ();
use Apache::Registry;
use Apache::PerlRun;
# Load Perl modules of your choice here
# This code is interpreted *once* when the server starts
use LWP::UserAgent ();
use Apache::Status ();
use Apache::DBI ();
use DBI ();
$Apache::DBI::DEBUG = 2;
# Tell me more about warnings
use Carp ();
$SIG{__WARN__} = \Carp::cluck;
# Load CGI.pm and call its compile() method to precompile
# (but not to import) its autoloaded methods.
use CGI ();
CGI-compile(':all');
Apache::DBI-connect_on_init
(DBI:mysql:database=test;host=localhost,
test,,
{
PrintError = 1, # warn() on errors
RaiseError = 1, # die on error
AutoCommit = 1, # commit executes immediately
Taint = 1 # Taint Checking on
}
);
1;
--
Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118
Science, Discovery, the Universe (UMCP)
Webmaster Webship Teacher
URL: http://www.sdu.umd.edu
EJPress.com
Database/PERL Programmer System Admin
URL : http://www.ejournalpress.com
Resume : http://www.p6m7g8.com/resume.txt
Re: Apache::Util segfaulting
[EMAIL PROTECTED] wrote: Hi all, I'm having an odd problem with a particular registry script. This script causes a segmentation fault at the first usage of Apache::Util::escape_uri(), This same script also uses Apache::Util::escape_html() with no problems at all. Other scripts on this same server use Apache::Util::escape_uri() without any problems. I've tried to get a core dump with httpd -X but it won't leave one. This is apache 1.3.14 with mod_perl/1.24_01 and php/3.0.17 both built against the same mysql libraries. Any ideas? To get the core dumped, you need to tell the shell to allow core dumps and set the allowed size of the core file. The simplest is to set it to unlimited. In bash do: ulimit -c unlimited; httpd -X _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [ANNOUNCE] Apache::AppCluster 0.2
On Wed, 9 Jan 2002, Mark Maunder wrote: The difference is that AppCluster allows you to call multiple remote methods on the server (or on multiple distributed servers) simultaneously. However, I wasn't aware of PlRPC and I really like the interface i.e. the way it creates a copy of the remote object locally and allows you to call methods on it as if it were just another object. would it require too much surgery and api change if you added the concurrency support to PlRPC?
Re: [ANNOUNCE] Apache::AppCluster 0.2
brian moseley wrote: On Wed, 9 Jan 2002, Mark Maunder wrote: The difference is that AppCluster allows you to call multiple remote methods on the server (or on multiple distributed servers) simultaneously. However, I wasn't aware of PlRPC and I really like the interface i.e. the way it creates a copy of the remote object locally and allows you to call methods on it as if it were just another object. would it require too much surgery and api change if you added the concurrency support to PlRPC? Well, I guess two methods could be added to the client object. One to add a concurrent request to be called (register_request()) and one to send all registered requests concurrently. I'm not the author though, so you'll have to chat to Jochen about that. The server and transport would have to be rewritten pretty much from scratch I think. The transport needs to be HTTP POST requests and responses. The server needs to be set up as a mod_perl handler that takes advantage of everything mod_perl has to offer. From my point of view, it's easier to duplicate Jochen's work in AppCluster by adding the same type of interface i.e. creating a copy of a remote object locally and calling methods on that object as per normal while the actual method call is submitted via a POST to a remote mod_perl app server. I dont really mind whether we incorporate this stuff into PlClient or AppCluster or both, but I do think that both the concurrency in AppCluster and tied object API in PlRPC are really useful and would be even better with the remote app server being mod_perl. An idea might be to incorporate both the AppCluster concurrency and PlRPC style api into an Apache::* module that gives us the best of both worlds with mod_perl performance (etc.) on the server side. (and then get rid of AppCluster since it will be redundant) Let me know if that sounds like a good idea and I'll start work on it. Perhaps we could call it Apache::PlRPC (now with added concurrency!) ~mark
Re: [ANNOUNCE] Apache::AppCluster 0.2
On Wed, 9 Jan 2002, Mark Maunder wrote: Well, I guess two methods could be added to the client object. One to add a concurrent request to be called (register_request()) and one to send all registered requests concurrently. I'm not the author though, so you'll have to chat to Jochen about that. couldn't you just subclass RPC::PlClient? The server and transport would have to be rewritten pretty much from scratch I think. The transport needs to be HTTP POST requests and responses. The server needs to be set up as a mod_perl handler that takes advantage of everything mod_perl has to offer. why needs? i'm sure lots of people would rather run a very lightweight non-http/apache-based server. I dont really mind whether we incorporate this stuff into PlClient or AppCluster or both, but I do think that both the concurrency in AppCluster and tied object API in PlRPC are really useful and would be even better with the remote app server being mod_perl. seems like the ideal api gives you the best functionality from both original apis and abstracts away the choice of transport and server. An idea might be to incorporate both the AppCluster concurrency and PlRPC style api into an Apache::* module that gives us the best of both worlds with mod_perl performance (etc.) on the server side. (and then get rid of AppCluster since it will be redundant) perhaps i misunderstand, but you're suggesting making the client an Apache module? why? i like the idea of being able to write client code that uses the same rpc api no matter whether i choose to use soap, xml-rpc, a more specific http post, plrpc's transport (whatever that might be), or whatever as the transport. not all of the drivers would have to support the same feature set (i think your mechanism supports arbitrarily deep data structures?). that rpc api is one of the things p5ee is looking for, i believe.
mod_perl framework + code reuse question
Background:
I'm working on a site that is a mix of php (which I'm gradually converting to
mod_perl) and mod_perl (running under Apache::Registry and using Template Toolkit
(TT2)) using an apache configuration like this:
Directory /
[...]
Files *.par
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
/Files
/Directory
I took the Files approach because, at the time, it seemed like the easiest way to
have *.php and *.par files coexist during the conversion.
Problem:
There are many *.par pages (estimate: 70-100 when conversion is complete), and they
all contain the following code with minor variations that could be made consistent
(like what constants are imported, what modules are used, etc.). I'd like to find a
way to prevent having that code (below) show up over and over again so I can eliminate
a potential maintenance headache, but I'm not sure of what's a good way to bundle it
up for reuse.
One idea I had was to write a handler that acts as a sort of minimal application
framework that contains the code below and determines what perl module should be
required and executed based on $apache-path_info and $apache-uri. This sounds
like a substantial effort, but would provide a centralized framework where I could add
features that apply to all pages by only editing code in one place. Is this a
reasonable approach? Are there other simpler approaches?
I'd appreciate any input on how other people are structuring similar type applications
in mod_perl, where the output is generated by Template Toolkit based on data obtained
via SQL queries using parameters received mostly in the URL.
#--- BEGIN SAMPLE PAGE testpage.par ---
#!/usr/local/bin/perl -wT
#
BEGIN {
require $MyCompany::Basepath-{sitename}/MyCompany/ProjectName/Config/Startup.pl;
}
use Apache ();
use Apache::Constants qw(:common SERVER_ERROR REDIRECT);
use Apache::DBI;
use strict;
our $apache = Apache-request;
### I realize that I should be handling header_only requests a little differently, but
code not updated yet.
$apache-content_type('text/html');
if ($apache-header_only) {
$apache-send_http_header;
return OK;
};
my $parm = {$apache-args, $apache-content};
my $dbi = $MyCompany::ProjectName::Config::dbi;
my $dbh = DBI-connect($dbi-{dsn}, $dbi-{user}, $dbi-{password},
{RaiseError = 1});
# template object is built in apache startup.perl file (before fork)
my $out = dispatch($apache, $parm, $dbh, $MyCompany::ProjectName::template);
$apache-send_http_header;
print $out;
return OK;
sub dispatch {
my ($apache, $parm, $dbh, $tpl) = @_;
my $template_data;
### [... fill $template_data with something meaningful here ...] ###
my $output = ;
$tpl-process('viewsurveyusers.tpl', $template_data, \$output)
or die Error processing template: .$tpl-error;
return $output;
}
#--- END SAMPLE PAGE testpage.par ---
Relevant piece of startup.perl:
# BEGIN ---
use Template;
$MyCompany::ProjectName::template = Template-new(INCLUDE_PATH = tt,
PRE_PROCESS = config.tpl,
PRE_CHOMP = 1,
);
#--- END ---
Matthew Pressly
Altering ENV from a PerlFixupHandler
I'm trying to set a way of passing some environnement variables from my
front-end server to my back-end so that my Registry or PerlRun script run
unchanged. What I've done is that I've modified my frontend to add, with
mod_rewrite, the environnement data I need (REFERER and REMOTE_ADDR), and I
tried, on the backend server, to add the value I received in the
environnement, like that :
$ENV{$key} = $args{$key};
or also like that :
$r-subprocess_env($key, $new_value);
My problem is that my change are erased before I get to the Response phase,
no matter how I set the environnement.
Where did i go wrong? Do I need to add a PerlPassEnv in my httpd.conf? And,
then, one more place to edit if I want to pass a new Environnnement variables?
And, is that a good way to acheive that?
Benoit Caron
Analyste-Programmeur
Netgraphe - Webfin.com - Le Web Financier
[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - -
The number of Unix installations has grown to 10,
with more expected.
-- The Unix Programmer's Manual, 2nd edition, June '72
Re: [ANNOUNCE] Apache::AppCluster 0.2
brian moseley wrote: On Wed, 9 Jan 2002, Mark Maunder wrote: Well, I guess two methods could be added to the client object. One to add a concurrent request to be called (register_request()) and one to send all registered requests concurrently. I'm not the author though, so you'll have to chat to Jochen about that. couldn't you just subclass RPC::PlClient? The transport is different (HTTP/POST) and I dont think I can easily just drop in another (alternative) transport - I may as well rewrite. The server and transport would have to be rewritten pretty much from scratch I think. The transport needs to be HTTP POST requests and responses. The server needs to be set up as a mod_perl handler that takes advantage of everything mod_perl has to offer. why needs? i'm sure lots of people would rather run a very lightweight non-http/apache-based server. Agreed. Are there any more besides a standalone pure perl daemon and mod_perl/apache? I dont really mind whether we incorporate this stuff into PlClient or AppCluster or both, but I do think that both the concurrency in AppCluster and tied object API in PlRPC are really useful and would be even better with the remote app server being mod_perl. seems like the ideal api gives you the best functionality from both original apis and abstracts away the choice of transport and server. yeah - agreed. An idea might be to incorporate both the AppCluster concurrency and PlRPC style api into an Apache::* module that gives us the best of both worlds with mod_perl performance (etc.) on the server side. (and then get rid of AppCluster since it will be redundant) perhaps i misunderstand, but you're suggesting making the client an Apache module? why? Well, the server component (at present) is a mod_perl handler, and I wanted to bundle both together so I stuck in in the Apache namespace (pending any objections of course). Seems like RPC might make more sense if it becomes platform/server neutral, since Apache::* binds the server platform to mod_perl. i like the idea of being able to write client code that uses the same rpc api no matter whether i choose to use soap, xml-rpc, a more specific http post, plrpc's transport (whatever that might be), or whatever as the transport. not all of the drivers would have to support the same feature set (i think your mechanism supports arbitrarily deep data structures?). that rpc api is one of the things p5ee is looking for, i believe. It seems like you're asking a bit much here (the holy grail of RPC?). SOAP and xml-rpc are their own client/server system. Are we going to integrate this with both of them and support standalone perl daemons etc.? I considered writing a soap client that allows for concurrent requests, but I found SOAP::Lite to be slow under mod_perl so opted for rolling my own instead. Also SOAP is platform neutral and I'm not sure, but I think it wont allow for perl data structures as complex as Storable does. I think you should probably distinguish between transport and encoding. Transports could be http, https or a plain old socket (if we're talking to a perl daemon) and an encrypted socket connection using CBC. Encodings we've chatted about are Storable's freeze/thaw and SOAP's XML, and then xml-rpc (which I assume has it's own encoding of method name and params etc in xml - although I dont know it at all). I think having various transports is fine. But I'm not sure what the motivation is for varying the encodings, unless we want our client to talk to SOAP and xml-rpc servers, or vice versa. Perhaps integrating PlRPC and AppCluster's client API's and allowing for either standalone daemon or mod_perl server is a good start? We can use HTTP, HTTPS, direct sockets and encrypted sockets as the first transports. The client can have two modes - concurrent remote procedure calls, or creating a copy of the remote object PlRPC style. ~mark.
Re: BSD::Resource und apache/mod_perl
Thanx, but that leads to the same result. In the first place I used: PerlModule Apache::Resource PerlSetEnv PERL_RLIMIT_AS 32:64 PerlChildInitHandler Apache::Resource in httpd.conf, but Apache::Resource uses BSD::Resource in the end and thus its the same as use BSD::Resource; setrlimit RLIMIT_AS, 3200, 6400; at top of the test script. I use setrlimit directly so I could test if BSD::Resource works at all - and it DOES if run from the shell - but it does NOT if run from Apache/mod_perl. What could cause the different behaviour?? Best regards, Christoph Bergmann Perrin Harkins wrote: has anybody any ideas? Apache::Resource.
Re: BSD::Resource und apache/mod_perl
PerlModule Apache::Resource PerlSetEnv PERL_RLIMIT_AS 32:64 PerlChildInitHandler Apache::Resource in httpd.conf, but Apache::Resource uses BSD::Resource in the end and thus its the same as use BSD::Resource; setrlimit RLIMIT_AS, 3200, 6400; The difference is that Apache::Resource should apply this limit to each new child process. When you do this from the shell, you are limiting the parent Apache process, which isn't very useful. Are you sure you're using the right units (bytes vs. megabytes)? Could your server be immediately going higher than the limit you set for it? - Perrin
Re: mod_perl framework + code reuse question
There are many *.par pages (estimate: 70-100 when conversion is complete), and they all contain the following code with minor variations that could be made consistent (like what constants are imported, what modules are used, etc.). I'd like to find a way to prevent having that code (below) show up over and over again so I can eliminate a potential maintenance headache, but I'm not sure of what's a good way to bundle it up for reuse. Normal Perl rules apply. Modules are good for sharing code. You could stuff the shared parts into a sub in a module that every script would call. Or you could use an OO approach, with a base class that holds all of the boiler-plate stuff. One idea I had was to write a handler that acts as a sort of minimal application framework that contains the code below and determines what perl module should be required and executed based on $apache-path_info and $apache-uri. That's a good way to go too. Moving from Apache::Registry to handlers can be empowering. This sounds like a substantial effort Only if your code currently depends on the CGI emulation features of Apache::Registry. If it's clean code, you should be able to convert it without much trouble. You could also try subclassing Apache::RegistryNG and adding your setup code to the beginning of each request there. I'd appreciate any input on how other people are structuring similar type applications in mod_perl, where the output is generated by Template Toolkit based on data obtained via SQL queries using parameters received mostly in the URL. I use handlers, with a model-view-controller design. The approach is documented in my Perl.com article about the eToys design. I keep all the common setup stuff in a base class that the other controllers inherit from. - Perrin
Re: Re: [error] Cannot remove module mod_perl.c: not found in modulelist
Yeah, it helps. Thank you! Best Regards, Cloudor Pu [EMAIL PROTECTED] 2002-01-10 Randy Kobes wrote a letter at 2002-01-09 09:14:00 £º On Wed, 9 Jan 2002, cloudor wrote: I get the message shown as [error] Cannot remove module mod_perl.c: not found in module list when i restart apache after installing mod_perl and adding LoadModule perl_module modules/mod_perl.so in the httpd.conf . [ ... ] Do you have a directive ClearModuleList enabled somewhere in your httpd.conf? If so, try commenting it out (as well as any AddModule ... directives) and see if that helps. best regards, randy kobes = = = = = = = = = = = = = = = = = = = = = =
