Re: AxKit configuration question
Robin Berjon wrote: On Saturday 01 September 2001 08:02, Ed Loehr wrote: There's also a note (in AxKit 1.4 change log, I think) that says that problem is fixed in 1.4. Also, from 'perldoc AxKit': If you have a recent mod_perl and use mod_perl's Makefile.PL DO_HTTPD=1 to compile Apache for you, this option will be enabled automatically for you. Other clues? It's supposed to, but sometimes apparently it doesn't (I haven't been able to track down why, and it may be my fault). Have you tried without SSL ? It sometimes conflicts with other modules. Another search track would be to find out which module that AxKit pulls in causes the crash (if any). You could also try out the 1.5 RC (which must be called 1.4_9x and is probably on CPAN or mirrored somewhere), it's been quite stable in my experience. I tried it without SSL, and the same problem remains: httpd exits silently after seemingly normal startup. I'll try 1.5RC, axkit irc, and debugging if I can't find a way around in my laziness. Thanks. Regards, Ed Loehr
AxKit.org/axkit.apache.org timing?
I recently read that AxKit was in the process of becoming an ASF xml project. Does anyone have a sense of the timing for when this might happen and when axkit.org/axkit.apache.org will return/arrive? Also, does anyone know of a mirror site for axkit.org? Regards, Ed Loehr
Re: AxKit configuration question
Ed Loehr wrote:
I'm attempting to install AxKit 1.4 (and 10 or so other pre-requisite
modules) on my modperl/modssl server, and I'm trying to get the
ultra-basic AxKit manpage example to work ('perldoc AxKit').
The first sign of trouble has arisen: httpd silently exits immediately
after startup once I add the specified AxKit configuration to my Apache
config files, and I have not been able to find any logging whatsoever
yet. I can see it is successfully loading AxKit.pm, and producing
seemingly all of the normal Apache log startup messages I usually see.
It's just that when I go to the ps table, it is not there. Does anyone
have a clue to offer before I recompile with debugging on?
Apache/1.3.20 (Unix) mod_perl/1.25 mod_ssl/2.8.4 OpenSSL/0.9.6b
More data: there is no core file created, and the mere presence of this
one line in my httpd.conf ...
PerlModule AxKit
...with no other AxKit directives anywhere, causes httpd to exit shortly
( 1 sec) after starting. I hacked AxKit.pm to verify it is loading, and
it is successfully completing it's BEGIN block.
Any clues?
Regards,
Ed Loehr
This is kernel 2.2.12-20smp.
# perl -V
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.5-22smp, archname=i386-linux
uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2
09:11:51 edt 1999 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)
cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include'
stdchar='char', d_stdstdio=undef, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lposix -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
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):
Built under linux
Compiled at Aug 30 1999 23:09:51
@INC:
/usr/lib/perl5/5.00503/i386-linux
/usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux
/usr/lib/perl5/site_perl/5.005
# httpd -V
Server version: Apache/1.3.20 (Unix)
Server built: Aug 31 2001 21:07:15
...
Server compiled with
-D EAPI
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D USE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT=/usr/local/apache_ssl-2.8.4-1.3.20
-D SUEXEC_BIN=/usr/local/apache_ssl-2.8.4-1.3.20/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/httpd.scoreboard
-D DEFAULT_LOCKFILE=logs/httpd.lock
-D DEFAULT_XFERLOG=logs/access_log
-D DEFAULT_ERRORLOG=logs/error_log
-D TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
-D ACCESS_CONFIG_FILE=conf/access.conf
-D RESOURCE_CONFIG_FILE=conf/srm.conf
AxKit configuration question
Hi All,
I'm attempting to install AxKit 1.4 (and 10 or so other pre-requisite
modules) on my modperl/modssl server, and I'm trying to get the
ultra-basic AxKit manpage example to work ('perldoc AxKit').
The first sign of trouble has arisen: httpd silently exits immediately
after startup once I add the specified AxKit configuration to my Apache
config files, and I have not been able to find any logging whatsoever
yet. I can see it is successfully loading AxKit.pm, and producing
seemingly all of the normal Apache log startup messages I usually see.
It's just that when I go to the ps table, it is not there. Does anyone
have a clue to offer before I recompile with debugging on?
My server's status line is
Apache/1.3.20 (Unix) mod_perl/1.25 mod_ssl/2.8.4 OpenSSL/0.9.6b
(it once had AxKit 1.4 in it, but I haven't been able to reproduce
that...)
Here's my httpd.conf file:
##
IfModule mod_perl.c
Include conf/perl.conf
/IfModule
##
Here's part of conf/perl.conf:
###
PerlModule AxKit
Location /ax
# Install AxKit main parts
SetHandler perl-script
PerlHandler AxKit
# Setup style type mappings
AxAddStyleMap text/xsl Apache::AxKit::Language::Sablot
AxAddStyleMap application/x-xpathscript \
Apache::AxKit::Language::XPathScript
# Optionally set a hard coded cache directory
# make sure this is writable by nobody
AxCacheDir /opt/axkit/cachedir
# turn on debugging (1 - 10)
AxDebugLevel 10
AxStackTrace On
AxLogDeclines On
/Location
##
If I delete this section of perl.conf, the server starts and runs fine,
albeit without the desired AxKit effect!!
The only thing I have not investigated are a bunch of log messages re
Apache::Status as follows ...
Subroutine menu_item redefined at
/usr/lib/perl5/site_perl/5.005/i386-linux/Apache/Status.pm line 46.
and a bunch for mod_perl.pm ...
Subroutine Apache::Table::TIEHASH redefined at
/usr/lib/perl5/site_perl/5.005/i386-linux/mod_perl.pm line 65535.
Thanks in advance for any clues/pointers.
Ed Loehr
Re: AxKit configuration question
Randy Kobes wrote: On Fri, 31 Aug 2001, Ed Loehr wrote: More data: there is no core file created, and the mere presence of this one line in my httpd.conf ... PerlModule AxKit ...with no other AxKit directives anywhere, causes httpd to exit shortly ( 1 sec) after starting. I hacked AxKit.pm to verify it is loading, and it is successfully completing it's BEGIN block. The AxKit FAQ (which unfortunately I don't think is reachable yet at http://www.axkit.org/) says that there could be some problems with Apache's default build with expat enabled and XML::Parser's version of expat. The recommendation is to recompile Apache with --disable-rule=expat. Does this work? I don't think so, not the way I tried it, anyway... cd $SSL_SRC_DIR/$MOD_PERL_DIST perl Makefile.PL \ USE_APACI=1 EVERYTHING=1 \ DO_HTTPD=1 SSL_BASE=/usr/local/ssl \ APACHE_PREFIX=$SSL_LOCAL_DIR \ APACHE_SRC=../$APACHE_DIST/src \ APACI_ARGS='--enable-module=ssl, \ --enable-module=rewrite, \ --enable-module=perl, \ ... --disable-rule=expat' (make date make test date make install date) | tee make.log cd $SSL_SRC_DIR/$APACHE_DIST make certificate TYPE=custom make install There's also a note (in AxKit 1.4 change log, I think) that says that problem is fixed in 1.4. Also, from 'perldoc AxKit': If you have a recent mod_perl and use mod_perl's Makefile.PL DO_HTTPD=1 to compile Apache for you, this option will be enabled automatically for you. Other clues? Regards, Ed Loehr
Re: [ModPerl] missing POST args mystery
Ed Loehr wrote: I'm stumped ... In a nutshell, my problem is that POSTed form key-value pairs are intermittently not showing up in the request object inside my handler subroutine. As I was puzzling over this, I saw this error message in the logs... (offline mode: enter name=value pairs on standard input) A google search turned up a note about needing to have $CGI::NO_DEBUG = 1 before calling CGI::Cookie-parse(). Adding that line of code before my parse call seems to have fixed the problem. At a glance, looks like CGI.pm was strangely set to read from the command-line (default $CGI::NO_DEBUG = 0), probably triggering a call of Apache's request-args somewhere along the line. How the default setting may have changed I don't know, because I've been using CGI.pm for years without this problem; I may have upgraded that package, picking up a change accidentally. Regards, Ed Loehr
[ModPerl] missing POST args mystery
I'm stumped regarding some request object behavior in modperl, and after
searching the Guide, Google, and the list archives without success, I'm
hoping someone might offer another idea I could explore, or offer some
helpful diagnostic questions.
In a nutshell, my problem is that POSTed form key-value pairs are
intermittently not showing up in the request object inside my handler
subroutine.
I have a modperl-generated form:
HTML
HEAD
META HTTP-EQUIV=Expires CONTENT=Tue, 01 Jan 1980 1:00:00 GMT
META HTTP-EQUIV=Pragma CONTENT=no-cache
TITLE.../TITLE
/HEAD
BODY
FORM METHOD=POST ACTION=postform
...
INPUT NAME=id TYPE=HIDDEN VALUE=123
...
/FORM
/BODY
/HTML
Upon submission, the form data eventually flows to my PerlHandler...
sub handler {
my $r = shift;
my @argsarray = ($r-method eq 'POST' ? $r-content() : $r-args());
...
}
Now, if I examine (print) the form values retrieved from the request
object upon entry into this handler (*after* I load them into $args),
'id' is not present at all. I must be missing something trivially
obvious to some of you.
This is running Apache/1.3.19 (Unix) mod_perl/1.25 mod_ssl/2.8.3
OpenSSL/0.9.6a.
Regards,
Ed Loehr
[RFI] URI escaping modules?
I just noticed that Apache::Util::escape_uri does not escape embedded '' characters as I'd expected. What is the preferred module for escaping '', '?', etc. when embedded in strings? Regards, Ed Loehr
Can't upgrade that kind of scalar
Aside from gdb, any fishing tips on how to track this fatal problem down? Can't upgrade that kind of scalar at XXX line NN... Happens intermittently, often on a call to one of these (maybe the first access of $r?): $r-server-server_hostname() $r-connection-remote_ip() I've tried turning off PerlFreshRestart, have _totally_ clean output from 'use diagnostics', reviewed The Guide, 'perldoc perldiag', FAQ, deja.com, swarthmore, removed /o, used Carp::cluck, handled global vars with 'use vars qw(...)'... Config: apache 1.3.9, mod_perl 1.21, mod_ssl 2.4.9, openssl 0.9.4, perl 5.005_03, DBI 1.13 (no Apache::DBI), DBD::Pg 0.92, Linux 2.2.12-20smp (RH 6.1)...
$r-print delay?
Any ideas on why would this output statement takes 15-20 seconds to
send a 120kb page to a browser on the same host?
sub send_it {
my ($r, $data) = @_;
$| = 1; # Don't buffer anything...send it asap...
$r-print( $data );
}
modperl 1.21, apache/modssl 1.3.9-2.4.9...lightly loaded Linux (RH6.1)
Dual PIII 450Mhz with local netscape 4.7 client...
Re: $r-print delay?
Ken Williams wrote: Are you sure it's waiting? You might try debug timestamps before after the $r-print(). You might also be interested in the send_fd() method if the data are in a file. Fairly certain it's waiting there. I cut my debug timestamps out for ease on your eyes in my earlier post, but here's one output (of many like it) when I had the print sandwiched... Thu Feb 10 14:41:59.053 2000 [v1.3.7.1 2227:1 ed:1] INFO : Sending 120453 bytes to client... Thu Feb 10 14:42:14.463 2000 [v1.3.7.1 2227:1 ed:1] INFO : Send of 120453 bytes completed. Re send_fd(), it's all dynamically generated data, so that's not an option... Other clues? [EMAIL PROTECTED] (Ed Loehr) wrote: Any ideas on why would this output statement takes 15-20 seconds to send a 120kb page to a browser on the same host? $| = 1; # Don't buffer anything...send it asap... $r-print( $data ); modperl 1.21, apache/modssl 1.3.9-2.4.9...lightly loaded Linux (RH6.1) Dual PIII 450Mhz with local netscape 4.7 client...
Re: does ssl encrypt basic auth?
[EMAIL PROTECTED] wrote: Ed Loehr wrote: Is a basic authentication password, entered via a connection to an https/SSL server, encrypted or plain text across the wire? Encrypted - but that question really doesn't belong here. It has nothing to do with modperl. Yes, some of your fellow off-topic police have already served notice privately. My unstated context was that mod_perl authentication was giving me fits, and in my effort to find an alternative, I (gasp) posted off-topic. I'm just glad you're watching. :(
Can't upgrade that kind of scalar (and more)
I've scoured deja.com, FAQs, modperl list archives at
forum.swarthmore.edu, 'perldoc mod_perl_traps', experimented ad
nauseum
for 4 days now... this modperl newbie is missing something
important...
Lasting gratitude and a check in the mail for dinner on me to any of
you
who can offer any tips/help which unlock this riddle for me...
Cheers,
Ed Loehr
SYMPTOMS...
---
Spurious errors in my error_log with increasingly nasty consequences:
Can't upgrade that kind of scalar at XXX line NN...
Not a CODE reference at XXX line NN...
Modification of a read-only value attempted at XXX line NN...
Attempt to free unreferenced scalar.
Attempt to free unreferenced scalar during global destruction.
Attempt to free unreferenced scalar at XXX line NN...
Once upon a time, the server was fully functional even with these
occasional error messages (which is why I ignored them originally).
Now, they are frequent showstoppers, causing requests to fail
altogether with 500 errors and occasional segfaults...
I'm lumping these together because I suspect they are all related.
In any case, the severest of these at present seems to be the
Can't upgrade that kind of scalar at XXX line NN...
message, which causes the request to fail and seems to foul up that
child for the rest of its life.
FAILED REMEDIES...
--
- Turned off PerlFreshRestart
- Got rid of '$| = 1;'
- Got rid of #!/usr/bin/perl -w (!!)
- Check 'use diagnostics' output
- Got rid of string regex optimization flags ( $key =~
m/^xyz/o )
- Replaced use of 'apachectl restart' with
stop-sleep3-startssl;
- use Carp (); local $SIG{__WARN__} = \Carp::cluck;
- Changed global all instances of global 'my $var = 0' to
'use vars qw($var); $var = 0;'
- Commented out Apache::Registry
(Most of these are just suggestions I found during my hunt...)
CONFIGURATION...
(detailed config dumps below)
mod_perl 1.21 (*NOT* Apache::StatINC)
mod_ssl 2.4.9
openssl 0.9.4
perl 5.005_03
DBI 1.13 (*NOT* using Apache::DBI)
DBD::Pg 0.92
Apache 1.3.9 (*VERY* lightly loaded)
Linux 2.2.12-20smp (RH 6.1), 1Gb RAM, RAID 5 (*lots* of free
mem)
Dual PII 450 cpus
Using modified TicketMaster scheme from Eagle book
OBSERVATIONS...
---
I'm convinced the code referenced by the error msgs (XXX line NN) is
almost at random; typically code that's worked flawlessly before
(sometimes my code, often not). I suspect the line numbers in the
error msg may be screwed up. #line did not clarify things.
If I rearrange my code, I have been able to make the error "move" to
another module (eg., from Exporter.pm to CGI.pm). Smell like a stack
corruption problem? Currently, the first unsuccessful statement is:
# ($r is the usual apache request object)
return ($retval,$msg)
unless $ticket{'ip'} eq
$r-connection-remote_ip;
In -X mode, once the server process hits one of these, it can no
longer
serve any modperl-generated page without a 500 error, occasionally
segfaulting in the process.
This also happens on both production and development server in
slightly
different manifestations (with slightly different httpd.conf files).
Other change factors that may or may not be related: new firewall
rules,
increased number of open file handles (echo 8192
/proc/sys/file-max),
increased load, RAM upgrade, numerous modperl app src code changes,
added
more use of Time::HiRes to other modules, new SSL certificate, and
more...
Finally, totally commenting out my incarnation of the TicketMaster
scheme
from the Eagle book (cookie-based passworded sessions) *seems* to
remove
the problem, but it's a moving target so I'm not sure of that yet.
Have
been unable to determine what it might be within TicketMaster that is
causing the problem.
NEXT STEPS...
-
Try removing Logger.pm from Apache::Ticket*
Whittle down until minimal set produces error?
Autoload troubles?
Find/try MacEachern's Apache::Leak? Hunting XS errors?
Apache::Vmonitor?
Relying on $_ in foreach loops?
SSL Certificate differences?
Dreaded Last Step: setup debugger and chase ...
# /usr/local/apache_ssl/bin/httpd -l
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_access.c
mod_auth.c
mod_setenvif.c
mod_ssl.c
mod_perl.c
# /usr/local/apache_ssl/bin/httpd -V
Server version: Apache/1.3.9 (Unix)
Server built: Dec 9 1999 11:40:44
Server's Module Magic Number: 19990320:6
Server compiled with
-D EAPI
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_
Re: ApacheDBI vs DBI for TicketMaster
Edmund Mergl wrote: On Sun, Jan 02, 2000 at 01:48:58AM -0600, Ed Loehr wrote: My apache children are seg faulting due to some combination of DBI usage and the cookie-based authentication/authorization [...] child seg faults. If I comment out all DBI references in the Hm, are you connecting to your database prior to Apache's forking No. BTW, this is all on apache 1.3.9 with mod_ssl 2.4.9 and mod_perl 1.21 on Redhat 6.1 (2.2.12-20smp)... do you use rpm's or did you compile everything by yourself ? Compiled everything myself. Oh, and I am also using DBD::Pg 0.92... Does that suggest anything to anyone? Cheers, Ed Loehr
