Re: [mp1] Apache::CmdParms->server()
Hi Geoffrey, that looks just fine to me. you shouldn't need it, but try to use Apache::CmdParms; at the top of your script, just in case. Unfortunately that does not work: Compilation works fine until I try to load the Module with PerlModule in httpd.conf: Can't locate Apache/CmdParms.pm in @INC (@INC contains: ... BEGIN failed--compilation aborted at /usr/local/lib/perl/5.8.0/Apache/MIHConfig.pm line 13. Compilation failed in require at /var/www/TO-MIH/src/perl/Apache/MIHAdmin.pm line 10. BEGIN failed--compilation aborted at /var/www/TO-MIH/src/perl/Apache/MIHAdmin.pm line 10. Compilation failed in require at (eval 101) line 3. recipes 7.8, 7.9, and (specfically) 7.10 in the mod_perl developer's cookbook talk about Apache::CmdParms, so that might help. http://www.modperlcookbook.org/chapters/ch07.pdf I'll look at'em. Thanx for the hint. -- [EMAIL PROTECTED] --plan-b.-GmbH--http://www.planb.de/-- --Rueppurrer-Str.-4-T#-49-721-35489964 --76317-Karlsruhe---F#-49-721-388581-- smime.p7s Description: S/MIME Cryptographic Signature
Re: [mp1] Apache::CmdParms->server()
Finally I found the solution: Can't locate object method "server" via package "Apache::CmdParms" at /usr/local/lib/perl/5.8.0/Apache/MIHConfig.pm line 35. You have to 'use Apache::ModuleConfig;' to make this work. -- [EMAIL PROTECTED] --plan-b.-GmbH--http://www.planb.de/-- --Rueppurrer-Str.-4-T#-49-721-35489964 --76317-Karlsruhe---F#-49-721-388581-- smime.p7s Description: S/MIME Cryptographic Signature
Re: Apache::DBI & Oracle Not Reconnecting
Hi, When you reboot the Oracle Database are you rebooting the machine or just restarting the oracle process. If it is the later then you might try restarting the Orcle Listener as well. I have noticed that sometimes the listener keeps open a connection to the now restarted database and this can cause issues as Apache::DBI can not spot it unlessit pings first. Assuming that your ping time is set to 0 then this should be spotted. Hope this helps Paddy PS. Previously I have posted patches to the current Apache::DBI to handle :- Limiting time a connection can be cached. Limiting number of connections that can be cached Correct handling of begin_work and Auto-commit Correct resetting of other attributes LongTruncOk etc. I would be grateful for feedback on these patches. Thanks Paddy On Thu, Oct 09, 2003 at 07:32:39AM -0400, Levon Barker wrote: > Hello, > > Excuse me if there is a better list for this but... > > Every time I reboot my Oracle database, my mod_perl server is not able to > connect to the db until I restart the apache server. > > I am using Oracle 9.12, Apache::DBI 0.92, Apache 1.3.28. > > I get the following entry in the Apache error log: > > DBD::Oracle::st execute failed: ORA-03114: not connected to ORACLE (DBD > ERROR: OCIStmtExecute) [for Statement " > BEGIN > :amt := > RA_TEST.CURRENCY_CONVERT(56, 8, 1, > '31-MAY-03'); > END; > " with ParamValues: :amt=undef] at > /perl_modules/CurrencyManager.pm line 58. > > My understanding is that Apache::DBI is supposed to establish a new > connection if the cached connection is invalid. > > Any thoughts on this would be great. > > Thanks, > Levon Barker >
Re: Apache::DBI & Oracle Not Reconnecting
On Thu, 2003-10-09 at 07:32, Levon Barker wrote: > Every time I reboot my Oracle database, my mod_perl server is not able to > connect to the db until I restart the apache server. Are you opening connections to Oracle before Apache forks (in startup.pl)? I've had problems like this when I did that, even if I closed the connections before forking. - Perrin
[QUESTION] getting wrong MIMEtype in header
Hi,
when using a mod_perl Modul to authenticate users, my apache doesn't seem to lookup
which
MIMEtype to choose and add to it's answer.
Here's my example:
httpd.conf:
PerlAuthenHandler MyIntranet::AuthTEST
PerlOptions +SetupEnv +GlobalRequest
require valid-user
AuthTEST.pm:
package MyIntranet::AuthTEST;
use Apache2;
use warnings FATAL => 'all', NONFATAL => 'redefine';
use Apache::Const -compile => qw(OK FORBIDDEN AUTH_REQUIRED SERVER_ERROR);
use strict;
sub handler {
my $obj = shift;
return Apache::OK;
}
1;
When calling /serv/websites/intranet.local/members/phpMyAdmin/index.php
the MIMEtype is text/plain (=Default Type). Without the Directory-Tag above
(means the whole mod_perl part) , it works fine. .. so Apache's conf-files are ok!
Here's my Reponse-Header:
Connection: close
Date: Fri, 10 Oct 2003 16:18:16 GMT
Accept-Ranges: bytes
ETag: "3bf5f-13e4-bda8c6c0"
Server: Apache/2.0
Content-Length: 5092
Content-Type: text/plain; charset=ISO-8859-1
Last-Modified: Sun, 03 Aug 2003 22:26:11 GMT
Client-Date: Fri, 10 Oct 2003 16:18:16 GMT
Client-Peer: 217.228.134.17:80
Client-Response-Num: 1
Where's the fault? .. config-mistake of mine? .. oder doesn't my mod_perl work
properly?
Some Details on my System:
RH-9 (K: 2.4.21)
Apache/2.0.46
mod_perl-1.99/10
Thank you for help.
Fatih Gey
Re: PATCH porting.pod "First Mystery"
Stas Bekman <[EMAIL PROTECTED]> writes:
> - move the perl4 lib solution to the perl_reference.pod
Will do when I get round to that bit. I still think a mention of it
is needed in porting.pod to warn people away from it. If you disagree
simply delete the offending paragraph.
> - suggest turning a lexical variable declared with my() into a global
> variable declared with our() to avoid the closure, with the following
> "but"s:
>
>o if with my() it wasn't crucial to initialize the variables
> (since my() initialized them to 'undef'), now all variables declared with
> our() must be explicitly initialized.
> [Brian: notice that I prefer *not* to suggest using local() to init
> vars, and rather have users do that explicitly, which is a good
> practice]
Well I disagree with you about it being good a practice. I personally
consider it good practice to work in a way that minimises the number
of things you have to do explicitly (with the exception of
declarations). I can't see why you think relying on the fact that
local() will initialize variables to undef is any worse than relying
on the fact that my() will.
But this is your document so I shall go along with your preferences.
I've tried to keep it brief by moving some of the points (in
particular 'use vars') into comments inside the code examples where
they can be expressed more concisely.
--- porting.pod.origFri Oct 10 18:58:48 2003
+++ porting.pod Fri Oct 10 18:42:27 2003
@@ -88,7 +88,7 @@
print "Content-type: text/plain\r\n\r\n";
- my $counter = 0;
+ my $counter = 0; # Explicit initialization technically redundant
for (1..5) {
increment_counter();
@@ -195,8 +195,8 @@
print "Content-type: text/plain\r\n\r\n";
-my $counter = 0;
-
+my $counter = 0; # Explicit initialization technically redundant
+
for (1..5) {
increment_counter();
}
@@ -228,51 +228,66 @@
It's important to understand that the I effect
happens only with code that C wraps with a
-declaration of the C subroutine. If you put your code into a
-library or module, which the main script require()'s or use()'s, this
-effect doesn't occur.
-
-For example if we move the code from the script into the subroutine
-I, place the subroutines into the I file, save it in
-the same directory as the script itself and require() it, there will
-be no problem at all. (Don't forget the C<1;> at the end of the
-library or the require() might fail.)
-
- mylib.pl:
- -
- my $counter;
- sub run{
-print "Content-type: text/plain\r\n\r\n";
-$counter = 0;
-for (1..5) {
- increment_counter();
-}
+declaration of the C subroutine. If you put all your code
+into modules, which the main script Cs, this effect doesn't
+occur.
+
+Do not use Perl4-style libraries. Subroutines in such libraries will
+only be available to the first script in any given interpreter thread
+to C a library of any given name. This can lead to
+confusing sporadic failures.
+
+The easiest and the fastest way to solve the nested subroutines
+problem is to switch from lexical scope to package scope for all
+variables for which you get the warning. The C subroutines
+are never called re-entrantly and each resides in a package to itself.
+Most of the usual disadvantates of package scoped variables are,
+therefore, not a concern. Note, however, that whereas explicit
+initialization is often redundant for lexical variables it is usually
+not redundant for these package variables as they are reused in
+subsequent executions of the handler.
+
+ counter.pl:
+ --
+ #!/usr/bin/perl -w
+ use strict;
+
+ print "Content-type: text/plain\r\n\r\n";
+
+ # In Perl <5.6 our() did not exist, so:
+ # use vars qw($counter);
+ our $counter = 0; # Explicit initialization now necessary
+
+ for (1..5) {
+increment_counter();
}
+
sub increment_counter{
$counter++;
print "Counter is equal to $counter !\r\n";
}
- 1;
-
- counter.pl:
- --
- use strict;
- require "./mylib.pl";
- run();
-This solution provides the easiest and the fastest way to solve the
-nested subroutines problem, since all you have to do is to move the
-code into a separate file, by first wrapping the initial code into
-some function that you later will call from the script and keeping the
-lexically scoped variables that could cause the problem out of this
-function.
-
-But as a general rule of thumb, unless the script is very short, I
-tend to write all the code in external libraries, and to have only a
-few lines in the main script. Generally the main script simply calls
-the main function of my library. Usually I call it C or
-C. I don't worry about nested subroutine effects anymore
-(unless I create them myself :).
+If the shared variable contains a reference it my hold onto lots of
+unecessary memory (or worse) if the reference is left to hang about
+until the next call to the same handler. For such variables you
+
[mp2]: internal_redirect causes sigsev
hi, we have some troubles with internal_redirect after upgrading to 1.99_10, here's what we try to do: before mp 1.99_09 this line used to work: ---CUT--- $r->internal_redirect( $r->uri ); ---CUT--- after upgrading to 1.99_10, we get the following in error_log: ---CUT--- [Fri Oct 10 18:34:13 2003] [error] [client 213.47.198.91] $r wasn't passed at /usr/bestsolution/httpd/mod_perl/BestApache/DiscussionBoard2/Save.pm line 45. ---CUT--- so we thought, internal_redirect maybe expects new arguments and after reviewing the xs files we tried this version: ---CUT--- $r->internal_redirect( $r, $r->uri ); ---CUT--- this however gives the following error: ---CUT--- [Fri Oct 10 19:00:25 2003] [error] [client 213.47.198.91] Usage: Apache::RequestRec::internal_redirect(r, new_uri) at /usr/bestsolution/httpd/mod_perl/BestApache/DiscussionBoard2/Save.pm line 46. ---CUT--- ... did we miss something or is this a bug? We temporarily worked around the problem by using $r->headers_out, but this cannot be a permanent solution. happy hacking udo -- "Well, if we were to build it idiot proof, someone would build a better idiot." Civilme
Re: [mp2]: internal_redirect causes sigsev
... ah, and sorry, it does not cause sigsev of course, it just complains ... -- "Well, if we were to build it idiot proof, someone would build a better idiot." Civilme
[mp1] segfault with Perl 5.8.1 and mod_perl 1.29
Hi, on my Linux system (Slackware 9.0) Apache segfaults in mod_perl as soon as it receives the first request. This started after I upgraded to Perl 5.8.1 (from 5.6.0). The Apache version is 1.3.28, mod_perl 1.29. I appreciate any help. -Joe gdb backtrace: Starting program: /usr/var/lib/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x0806952d in perl_header_parser (r=0x82d86bc) at mod_perl.c:1015 1015dPPDIR; (gdb) bt #0 0x0806952d in perl_header_parser (r=0x82d86bc) at mod_perl.c:1015 #1 0x080adcad in run_method (r=0x82d86bc, offset=32, run_all=1) at http_config.c:370 #2 0x080adda6 in ap_header_parse (r=0x82d86bc) at http_config.c:407 #3 0x080c26b9 in process_request_internal (r=0x82d86bc) at http_request.c:1261 #4 0x080c2a2d in ap_process_request (r=0x82d86bc) at http_request.c:1340 #5 0x080b9c9e in child_main (child_num_arg=0) at http_main.c:4653 #6 0x080b9e3e in make_child (s=0x820824c, slot=0, now=1065834735) at http_main.c:4768 #7 0x080b9fa4 in startup_children (number_to_start=5) at http_main.c:4850 #8 0x080ba641 in standalone_main (argc=2, argv=0xb754) at http_main.c:5169 #9 0x080bae5f in main (argc=2, argv=0xb754) at http_main.c:5511 #10 0x400a9bb4 in __libc_start_main () from /lib/libc.so.6 perl -V output: Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.21-pre1, archname=i486-linux uname='linux schwitters 2.4.21-pre1 #13 sun aug 3 19:41:24 pdt 2003 i686 unknown ' config_args='-de -Dprefix=/usr -Dcccdlflags=-fPIC -Darchname=i486-linux' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-g', cppflags='-DDEBUGGING -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.2.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.1.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING USE_LARGE_FILES Built under linux Compiled at Oct 10 2003 17:14:25 @INC: /usr/lib/perl5/5.8.1/i486-linux /usr/lib/perl5/5.8.1 /usr/lib/perl5/site_perl/5.8.1/i486-linux /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl .
missing /modules/perl/mod_perl.config??
I am installing apache-1.3.28 with mod_perl-1.28. I'm getting the following error. I have made several attempts, but do not know what to do about it. When I search for mod_perl.config I only find /root/src/mod_perl-1.28/apaci/mod_perl.config.sh [EMAIL PROTECTED] mod_perl-1.28]# perl Makefile.PL USE_APACI=1 EVERYTHING=1 SSL_BASE=/usr/local/ssl APACHE_PREFIX=/usr/apache Will configure via APACI Configure mod_perl with ../apache_1.3.28/src ? [y] y Will run tests as User: 'nobody' Group: 'root' can't open /modules/perl/mod_perl.config No such file or directory at Makefile.PL line 2318.
Re: [mp1] segfault with Perl 5.8.1 and mod_perl 1.29
Joachim Feise wrote: Hi, on my Linux system (Slackware 9.0) Apache segfaults in mod_perl as soon as it receives the first request. This started after I upgraded to Perl 5.8.1 (from 5.6.0). The Apache version is 1.3.28, mod_perl 1.29. I appreciate any help. Joachim, Your report is almost perfect. but you need to send in a *short* script/handler that we can reproduce the problem with. Without it we can't help you. __ Stas BekmanJAm_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
Re: missing /modules/perl/mod_perl.config??
Raymond Norton wrote: I am installing apache-1.3.28 with mod_perl-1.28. I'm getting the following error. I have made several attempts, but do not know what to do about it. When I search for mod_perl.config I only find /root/src/mod_perl-1.28/apaci/mod_perl.config.sh [EMAIL PROTECTED] mod_perl-1.28]# perl Makefile.PL USE_APACI=1 EVERYTHING=1 SSL_BASE=/usr/local/ssl APACHE_PREFIX=/usr/apache missing DO_HTTPD=1? Will configure via APACI Configure mod_perl with ../apache_1.3.28/src ? [y] y Will run tests as User: 'nobody' Group: 'root' can't open /modules/perl/mod_perl.config No such file or directory at Makefile.PL line 2318. -- __ Stas BekmanJAm_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
Re: Apache-AuthenNTLM-2.04
Keven Murphy wrote: On Thu, 2003-10-09 at 10:59, Shannon Eric Peevey wrote: Hi! You are making me dust off the cobwebs!!! ;) Anyways, I think that the problem is not the version of NTLM, but the browser that you are using. Your browser is sending: [13573] AuthenNTLM: Authorization Header Basic When it should be sending something like: [505] AuthenNTLM: Authorization Header NTLM TlRMTVNTUAABB4IAoAB= It looks to me as if you are not using Internet Explorer... What happens when you try it from IE? First off, I appreciate your time in looking at this. I have tried both Netscape 7 and IE 6+. Both did not work. Can you run both again, and send me the logs for both of those two sessions? speeves cws
