Basic authentication
Hi,
I'm having a bit of trouble authenticating users. The script I have works, but only a
couple of times before it just sends out 401 without prompting the user for their
details. We have mod_perl 1.99_05 installed, we don't want to upgrade as we would have
more applications to upgrade than time.
Any help/questions would be appreciated. The problem script is below:
use strict;
use Apache::Const qw(OK AUTH_REQUIRED);
use lib qw(/var/www/html/opbms/libs);
use CheckLogin;
use CreateFrames;
my $r = shift;
print Content-Type:text/html\n\n;
my ($status, $password) = $r-get_basic_auth_pw;
if ($status != OK)
{
$r-status($status);
exit($status);
}
my $ip = '127.0.0.1';
my $port = 31555;
if (CheckLogin::Check($r-user, $password, $port, $ip) eq '1')
{
CreateFrames::Create($r-user, $password, $port, $ip);
}
else
{
$r-note_basic_auth_failure;
$r-status(AUTH_REQUIRED);
exit(AUTH_REQUIRED);
}
Cheers!!
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
RE: mod_perl v2 Forking
Hi,
I had a problem with 5.8.1 and forking in that I was either getting zombies using the
5.6 examples or the parent was dying, depending on which example was used. The way
round I found was to:
# ignore the child, good rule for life
$SIG{CHLD} = 'IGNORE';
# then sort out the socket
my $server = new IO::Socket::INET(LocalPort = $port,
Type = SOCK_STREAM,
Proto = tcp,
Listen = 5)
or die some error;
# wait for a connection
while(my $client = $server-accept())
{
my $pid = fork;
die Error. Fork: $!\n unless defined $pid;
if($pid == 0)
{
# all your child code here
# when it's done, kill the child:
exit(0);
}
}
This seemes reasonably stable. If anybody has a better way, then I'm all ears.
Cheers!
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:24
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be doing this no
matter if I was running CGI or mod_perl or whatever. I am pretty desparate
to get this working, and if anyone wants to earn some cash helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron, but with the
detaching stuff it seemed a lot easier to make a server with IO::Select and
not actually start the server from mod_perl. The end result hopefully will
be a web user being able to start some things that take time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to wait until the
Interpeter is in a safe state. As I understand it this might avoid some
things like core dumps or other errors related to dieing while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the above example had
his problem solved by using Errno and looking for EINTR if that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep 16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No child process
This code works just fine on 5.6 since it is about 150% from examples :)
The above is the result of connecting, doing a who, and doing dienow to
test the alarm.
I also found this:
http://archive.develooper.com/[EMAIL PROTECTED]/msg03022.html
Which totaly describes my problem as well, but shows it happening with perl
5.8.1..
I'd imagine that your accept() isn't being restarted. How does it work
if you change the loop to look like this?
use Errno;
while (1) {
my $client = $server-accept or do {
next if $!{EINTR};
last;
};
spawn(\function, whatever);
}
#!/usr/bin/perl -w
## new frankenstein!
use strict;
use POSIX ();
use POSIX 'WNOHANG';
use Errno;
use IO::Socket;
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
use Net::hostent;
use Carp;
$|=1;
my $pid;
open (DIED, /var/log/daemon_log) or warn $!;
sub logmsg { print DIED $0 $$: @_ at , scalar localtime, \n }
my $listen_socket = IO::Socket::INET-new(LocalPort = 1081,
LocalAddr = '127.0.0.1',
Proto = 'tcp',
Listen= SOMAXCONN,
Reuse = 1 )
or die can make a tcp server on port 1080 $!;
# make the daemon cross-platform, so exec always calls the script
# itself with the right path, no matter how the script was invoked.
my $script = File::Basename::basename($0);
my $SELF = catfile $FindBin::Bin, $script;
# POSIX unmasks the sigprocmask properly
my $sigset = POSIX::SigSet-new();
my $action = POSIX::SigAction-new('sigHUP_handler',
$sigset,
POSIX::SA_NODEFER);
my $action_alrm = POSIX::SigAction-new('sigALRM_handler',
$sigset,
POSIX::SA_NODEFER);
POSIX::sigaction(POSIX::SIGHUP, $action);
POSIX::sigaction(POSIX::SIGALRM, $action_alrm);
sub sigHUP_handler {
print got SIGHUP\n;
exec($SELF, @ARGV)
RE: mod_perl v2 Forking
Hi,
is the database connection created in the child or before it?
If it's created inside the child then it'll die ungracefully when the child
dies, so put something nice and fluffy to close it before the exit.
Otherwise, I don't know I'm afraid.
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:57
To: Stephen Hardisty
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl v2 Forking
Hi,
Doing this works for me. But I am ending up with some errors that I didn't
have before. Of course my bosses would get mad if I posted all of the code
involed, but basicly a database connection that was working fine is now
returning mysql server has gone away, meaning that the connection got
killed. What is weird/scary, is that if I change your $SIG{CHLD} = 'IGNORE';
back to the handler I was using, the database error goes away, but I am back
were I was. Fun huh? :)
Thanks,
Eric
At 03:57 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
I had a problem with 5.8.1 and forking in that I was either getting zombies
using the 5.6 examples or the parent was dying, depending on which example
was used. The way round I found was to:
# ignore the child, good rule for life
$SIG{CHLD} = 'IGNORE';
# then sort out the socket
my $server = new IO::Socket::INET(LocalPort = $port,
Type = SOCK_STREAM,
Proto = tcp,
Listen = 5)
or die some error;
# wait for a connection
while(my $client = $server-accept())
{
my $pid = fork;
die Error. Fork: $!\n unless defined $pid;
if($pid == 0)
{
# all your child code here
# when it's done, kill the child:
exit(0);
}
}
This seemes reasonably stable. If anybody has a better way, then I'm all ears.
Cheers!
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:24
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be doing this no
matter if I was running CGI or mod_perl or whatever. I am pretty desparate
to get this working, and if anyone wants to earn some cash helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron, but with the
detaching stuff it seemed a lot easier to make a server with IO::Select and
not actually start the server from mod_perl. The end result hopefully will
be a web user being able to start some things that take time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to wait until the
Interpeter is in a safe state. As I understand it this might avoid some
things like core dumps or other errors related to dieing while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the above example had
his problem solved by using Errno and looking for EINTR if that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep 16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No child process
This code works just fine on 5.6 since it is about 150% from examples :)
The above is the result of connecting, doing a who, and doing dienow to
test the alarm.
I also found this:
http://archive.develooper.com/[EMAIL PROTECTED]/msg03022.html
Which totaly describes my problem as well, but shows it happening with perl
5.8.1..
I'd imagine that your accept() isn't being restarted. How does it work
if you change the loop to look like this?
use Errno;
while (1) {
my $client = $server-accept or do {
next if $!{EINTR};
last;
};
spawn(\function, whatever);
}
#!/usr/bin/perl -w
## new frankenstein!
use strict;
use POSIX ();
use POSIX 'WNOHANG';
use Errno;
use IO::Socket;
use FindBin ();
use File::Basename ();
use File::Spec::Functions;
use Net::hostent;
use Carp;
$|=1;
my $pid;
open (DIED, /var/log/daemon_log) or warn $!;
sub logmsg { print DIED $0 $$: @_ at , scalar localtime, \n }
my $listen_socket = IO::Socket::INET-new(LocalPort = 1081,
LocalAddr = '127.0.0.1',
Proto
RE: mod_perl v2 Forking
I guess you could, but if there's already a load of code mightn't be a bit of a pain
POE-ing it?
-Original Message-
From: Gareth Kirwan [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 16:50
To: 'Eric Frazier'; Stephen Hardisty
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl v2 Forking
Haven't read much of this thread, but is POE an option ?
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 13:17
To: Stephen Hardisty
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl v2 Forking
:) I think that makes sense. It was created in the child. It
seemed to be
fixed when I made the connection global. When I tried the
connection in the
child again it might well have been a lucky transpireing of
events that let
the child stay alive long enough for the query to get
completed. So I should
keep it global I think.
Thanks,
Eric
At 04:24 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
is the database connection created in the child or before it?
If it's created inside the child then it'll die ungracefully
when the child
dies, so put something nice and fluffy to close it before the exit.
Otherwise, I don't know I'm afraid.
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:57
To: Stephen Hardisty
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl v2 Forking
Hi,
Doing this works for me. But I am ending up with some
errors that I didn't
have before. Of course my bosses would get mad if I posted
all of the code
involed, but basicly a database connection that was working
fine is now
returning mysql server has gone away, meaning that the
connection got
killed. What is weird/scary, is that if I change your
$SIG{CHLD} = 'IGNORE';
back to the handler I was using, the database error goes
away, but I am back
were I was. Fun huh? :)
Thanks,
Eric
At 03:57 PM 9/16/03 +0100, Stephen Hardisty wrote:
Hi,
I had a problem with 5.8.1 and forking in that I was either
getting zombies
using the 5.6 examples or the parent was dying, depending on
which example
was used. The way round I found was to:
# ignore the child, good rule for life
$SIG{CHLD} = 'IGNORE';
# then sort out the socket
my $server = new IO::Socket::INET(LocalPort = $port,
Type = SOCK_STREAM,
Proto = tcp,
Listen = 5)
or die some error;
# wait for a connection
while(my $client = $server-accept())
{
my $pid = fork;
die Error. Fork: $!\n unless defined $pid;
if($pid == 0)
{
# all your child code here
# when it's done, kill the child:
exit(0);
}
}
This seemes reasonably stable. If anybody has a better way,
then I'm all ears.
Cheers!
-Original Message-
From: Eric Frazier [mailto:[EMAIL PROTECTED]
Sent: 16 September 2003 12:24
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl v2 Forking
Hi,
I guess this is off topic for this list, since I would be
doing this no
matter if I was running CGI or mod_perl or whatever. I am
pretty desparate
to get this working, and if anyone wants to earn some cash
helping me fix
things PLEASE call me at 250 655-9513.
I have been trying to accomplish the same thing as Cameron,
but with the
detaching stuff it seemed a lot easier to make a server
with IO::Select and
not actually start the server from mod_perl. The end result
hopefully will
be a web user being able to start some things that take
time, but not screw
things up by interrupting them.
But then I found I was using 5.8.. Thanks to a guy on
comp.lang.perl.misc I
know that there is a change in how signals are handled, they call it
deferred signal handling because Perl now is suppose to
wait until the
Interpeter is in a safe state. As I understand it this
might avoid some
things like core dumps or other errors related to dieing
while trying to do
something besides dieing.
The thing is somehow this ends up killing off my parent
process, just like
in this post:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg43989.html
So this is happening to me as well, however the guy in the
above example had
his problem solved by using Errno and looking for EINTR if
that error is
raised then catch it and move on,
I did get one maybe helpfull thing from my log:
Erro was %!
./franken_socket.pl 8607: got - CHLD
at Tue Sep 16 02:17:42 2003
I got forked
./franken_socket.pl 8599: begat 8607 at Tue Sep 16 02:17:40 2003
begat 8607
./franken_socket.pl 8599: got - CHLD
at Tue Sep 16 02:17:54 2003
./franken_socket.pl 8599: main 8607 -- reaped 1 at Tue Sep
16 02:17:54 2003
reaped 1Erro was No child processes %!
So it looks like the parent got killed on that error No
child process
This code works
Re: [mp1] consistent segfaults with HTML::Mason
Stephen [EMAIL PROTECTED] wrote:
I'm no expert at debugging C, but I dont think that the above looks too
healthy
Well, I think I have it figured out, more or less. The root cause of it
seemed to be a rather, um, interesting bit of code in
HTML::Mason::ApacheHandler which makes use of string eval and sprintf to
define the handler() subroutine. The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
Preloading the module and using the explicit Module-handler method syntax
in httpd.conf seems to have fixed it. (Having said that, it seems to be
working without the additional -handler now ... *sighs*. Either I failed
to add method handlers to the config before, or I'm collecting on a karmic
debt. Or both).
As for the segfaults, I patched my mod_perl source to return undef in that
situation as opposed to segfault, which seems slightly more reasonable
behaviour. Patch below:
--- src/modules/perl/Apache.xs-origFri Jun 6 12:31:10 2003
+++ src/modules/perl/Apache.xs Thu Aug 28 12:10:53 2003
@@ -2075,7 +2075,10 @@
SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
cs = (perl_server_config *)get_module_config(s-module_config,
perl_module);
- TABLE_GET_SET(cs-vars, FALSE);
+if(cs) {
+ TABLE_GET_SET(cs-vars, FALSE);
+}
+else XSRETURN_UNDEF;
}
else XSRETURN_UNDEF;
}
This has taught me more about XS and the um, interesting capabilities of
string eval than I ever wanted to know, I think. Please excuse me whilst I
take a cold shower or three...
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Geoffrey Young wrote: mp1 supports both $$ and :method, so no need to do something special to make it work for both mp1 and mp2. Aah, I'll pass that onto the Mason folks. Ta. Preloading the module and using the explicit Module-handler method syntax in httpd.conf seems to have fixed it. preloading is required in mp1. the - syntax is not. Ah, looks like that was it, in that case. Stephen Veiss -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp1] consistent segfaults with HTML::Mason
/stephen/im/public_html ServerName im.mutatorr.net PerlInitHandler Apache::Reload PerlSetVar ReloadAll On PerlSetVar MasonAllowGlobals $c PerlRequire /usr/local/apache13/conf/conf.pl PerlSetVar MasonDataDir /usr/local/mason/im/ AddType text/html .mhtml AddType text/html .mc DirectoryIndex index.html index.php index.mhtml index.mc LocationMatch (\.mhtml|\.mc)$ SetHandler perl-script PerlHandler HTML::Mason::ApacheHandler /LocationMatch LocationMatch (\.mx|autohandler|dhandler)$ SetHandler perl-script PerlInitHandler Apache::Constants::FORBIDDEN /LocationMatch /VirtualHost conf.pl contains the following: use strict; use warnings; use Apache::DBI (); 1; Thanks for wading through all of this *grins*. Stephen Veiss -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stas Bekman [EMAIL PROTECTED] wrote:
Wearing my bug-tender cap, but not taking the ownership of this bug, I
should
say that your backtrace could be much more useful if you have had rebuilt
apache/perl/mod_perl with debugging symbols enabled. When you do that the
trace will show the arguments to the functions.
http://perl.apache.org/bugs/
provides the details on how to do that.
Hrm. I thought I had. Let me try it again.
Aha. It would seem that make install strips symbols or something...
Program received signal SIGSEGV, Segmentation fault.
0x808ed0d in XS_Apache_dir_config (cv=0x81ce8cc) at Apache.c:3114
3114TABLE_GET_SET(cs-vars, FALSE);
(gdb) bt
#0 0x808ed0d in XS_Apache_dir_config (cv=0x81ce8cc) at Apache.c:3114
#1 0x810c3b3 in Perl_pp_entersub ()
#2 0x81066e0 in Perl_runops_standard ()
#3 0x80c55ba in S_call_body ()
#4 0x80c56fe in Perl_eval_sv ()
#5 0x80860ea in perl_require_module (name=0x8324f7c
HTML::Mason::ApacheHandler, s=0x827019c) at perl_util.c:550
#6 0x807ffdc in perl_call_handler (sv=0x81ce9ec, r=0x8323d34, args=0x0) at
mod_perl.c:1590
#7 0x807f9d1 in perl_run_stacked_handlers (hook=0x815f619 PerlHandler,
r=0x8323d34, handlers=0x81cea4c) at mod_perl.c:1374
#8 0x807dd37 in perl_handler (r=0x8323d34) at mod_perl.c:897
#9 0x809d811 in ap_invoke_handler (r=0x8323d34) at http_config.c:518
#10 0x80b3470 in process_request_internal (r=0x8323d34) at
http_request.c:1324
#11 0x80b3900 in ap_internal_redirect (new_uri=0x8323d0c /index.mhtml,
r=0x8323034) at http_request.c:1461
#12 0x8076042 in handle_dir (r=0x8323034) at mod_dir.c:174
#13 0x809d811 in ap_invoke_handler (r=0x8323034) at http_config.c:518
#14 0x80b3470 in process_request_internal (r=0x8323034) at
http_request.c:1324
#15 0x80b34da in ap_process_request (r=0x8323034) at http_request.c:1340
#16 0x80a9dcb in child_main (child_num_arg=0) at http_main.c:4653
#17 0x80a9f8d in make_child (s=0x819c034, slot=0, now=1062020715) at
http_main.c:4768
#18 0x80aa106 in startup_children (number_to_start=2) at http_main.c:4850
#19 0x80aa7a4 in standalone_main (argc=4, argv=0xbfbffa78) at
http_main.c:5169
#20 0x80ab004 in main (argc=4, argv=0xbfbffa78) at http_main.c:5511
#21 0x8064a6a in _start ()
(gdb) list
3109s = r r-server ? r-server : perl_get_startup_server();
3110if (s s-module_config) {
3111SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
3112cs = (perl_server_config
*)get_module_config(s-module_config,
3113
perl_module);
3114TABLE_GET_SET(cs-vars, FALSE);
3115}
3116else XSRETURN_UNDEF;
3117}
3118
(gdb) print cs
$4 = (perl_server_config *) 0x0
(gdb) print s
$6 = (server_rec *) 0x0
I'm no expert at debugging C, but I dont think that the above looks too
healthy
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, now that I've had a day or so to play with it (using both worker and prefork), I have yet to see any issues. It looks good. However, any further testing I do will probably be limited to prefork, since the overhead of ithreads manages to eat all the memory on my workstation. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KuSoA4aoazQ9p2cRAiDAAKDxbLR17B4R/2w8tD56aKTcKlQ8EgCgo8B0 ICKCbkeKlf6Xe/WE7bwlpm8= =C6/k -END PGP SIGNATURE-
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 31, 2003 at 11:41:42AM +0200, Stas Bekman wrote: Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. Thanks for the note Stephen, but this is not very useful if you don't tell the details about your platform and setup. If you post here the output of t/REPORT or mp2bug that will be much more useful. Thanks. *** mod_perl version 1.9910 *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS= /opt/apache/bin/apxs MP_COMPAT_1X = MP_DEBUG = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_MAINTAINER = 1 MP_TRACE = 1 MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /opt/apache/bin/httpd -V Server version: Apache/2.0.47 Server built: Jul 30 2003 17:58:08 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -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=/opt/apache -D SUEXEC_BIN=/opt/apache/bin/suexec -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /opt/perl/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.20-19.8, archname=i686-linux-thread-multi uname='linux stephenc.theiqgroup.com 2.4.20-19.8 #1 tue jul 15 15:25:37 edt 2003 i686 i686 i386 gnulinux ' config_args='-des -Dprefix=/opt/perl -Dinstallprefix=/opt/perl -Dvendorprefix=/opt/perl -Dsiteprefix=/opt/perl -Dmyhostname=localhost [EMAIL PROTECTED] -Dcf_by=IQG-SPC -Dcc=gcc -Doptimize=-O3 -march=i686 -mcpu=i686 -ggdb3 -Duseshrplib -Duseperlio -Dusethreads -Duseithreads -Dusemymalloc' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 -march=i686 -mcpu=i686 -ggdb3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing' ccversion='', gccversion='3.2 20020903 (Red Hat Linux 8.0 3.2-7)', 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='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/opt/perl/lib/5.8.1/i686-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: RC3 Built under linux Compiled at Jul 30 2003 17:12:12 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /opt/perl/lib/5.8.1/i686-linux-thread-multi /opt/perl/lib/5.8.1 /opt/perl/lib/site_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/site_perl/5.8.1 /opt/perl/lib/site_perl /opt/perl/lib/vendor_perl/5.8.1/i686-linux-thread-multi /opt/perl/lib/vendor_perl/5.8.1 /opt/perl/lib/vendor_perl . Unfortunately a couple of the modules we're using don't want to cooperate with ithreads (XML::GDOME is a notable one). I'm working on patches for these; in the meantime, I'll at least give it a thorough run-through with prefork. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KZcHA4aoazQ9p2cRAmaXAKCIE5sROjyScppt8qu47Pm7LJw6kgCfajBU 1E4cCfuKlCnKzdwCuQVzUzw= =H4RV -END PGP SIGNATURE-
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 30, 2003 at 11:15:32PM +0200, Stas Bekman wrote: Jarkko has just released perl-5.8.1-RC3. Quite a few things have changed since 5.8.0. So it's *very* important that you test your code with this release and immediatelly report to p5p if you have any problems, since Jarkko wants to release 5.8.1 any moment now. Iniital report: I just finished a build with ithreads and worker mpm. All perl and mod_perl tests pass. The only problem so far is the ithreads mod_perl takes three glacial eons to start issue. You brought that up on modperl-dev a few days ago but I haven't had a chance to rebuild everything with ithreads until now. Did you ever hear anything from Arthur? Anyway, now I'm off to load some production code into it and see how it fares. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KF+bA4aoazQ9p2cRAqxdAJ9T/BOqg4jNo25vay1PzIRe+hM8jgCgwbI9 dmGE6oAn+TRiL+ZYRfsKzhY= =HsN4 -END PGP SIGNATURE-
Re: libgtop gone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 29, 2003 at 12:44:37AM -0500, Perrin Harkins wrote: This guy was on HPUX, and he just wanted source to this one library. It used to be available separately. I guess it's not a simple thing to do at this point if you don't want gnome and aren't on Red Hat. http://ftp.gnome.org/pub/GNOME/desktop/2.0/2.0.3/sources/libgtop-2.0.0.tar.gz I haven't checked this myself (it may want some other GNOME component) but it's a good start. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+N3paA4aoazQ9p2cRAmvzAKDprrKc2Ixv+zDwER0reJ4L7pKjJQCfeaop 9aurfdiQJ1/VEitgkvCK2WY= =CClG -END PGP SIGNATURE-
Re: glitched install of mod_perl (1.99.08)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 27, 2003 at 06:25:26PM +1100, Stas Bekman wrote: Hmm, you have perl 5.8.0. How is it possible that you don't have CGI.pm, which is a part of the core? It's probably a perl installed from a vendor-supplied package. You'd be amazed at the shreds the standard Perl distribution can get ripped to. Redhat I know splits a standard Perl installation into no less than 20 packages. CGI,pm and friends get shoved off off into their own RPM (perl-CGI). Other Linux distros I can't speak for but they tend to be similar. In short, don't assume that their kit is complete. Their vendor may have done them a favor via package management. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+Nh4LA4aoazQ9p2cRApiKAKCAQQgOog5s2vvDMd6EaeBABMAnCwCfTztQ UvVqRTba6IoqCfQOJcCX5X0= =eKxk -END PGP SIGNATURE-
RE: Load balancers
On Mon, 13 Jan 2003, Jesse Erlbaum wrote: That's for all the info so far. To answer some questions, hardware is a cost issue right now. It's somewhat scary that $3,200 was a reasonable price several years ago, but I suppose it could be worse. We will investigate further. Actually, $3200 was a STEAL! Cisco's Local Director was in the mid five-figures at the time, IIRC. :-) No, the local directors were that never that much, maybe low five-figures, like $12-15K or so. Boston.com was running on a pair of (saturated) low end LD's up until around Y2K, when we revamped the load balancing architecture and switched over to ArrowPoint (which then got gobbled up by Cisco) load distributing switches. At that time, a past-its-prime LD could be had for $3K or so, and a state-of-the-art Arrowpoint CS-150 ran around $12K (but we installed the higher capacity CS-800, which ran around $30K each -- just don't ask them to support HTTP 100% correctly... ;^) I've been out of touch with hardware load balancing equipment over the last couple of years, but if the decline in hardware costs of these things has continued, I'd guess a reasonably chunky solution can be had in the $5-7K range at this point. (Of course, you'd need to multiply that cost by two for complete redundancy...) [ Love to hear from someone with current knowledge if this is the case though...] -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Stupid newbie question: where is .?
So, I'm using mod_perl as installed via RPMS on RedHat 8.0, and can't believe that an hour of hunting hasn't netted an answer to this apparently simple problem. Perl scripts seem not to have . set to ~user/public_html, as use() and require() fail on files which are in the same directory as the CGI script. What have I missed? The error message states that . is in @INC. To be specific, I've enabled mod_perl for ~user's files like this: Directory /home/user/public_html Options +Includes +ExecCGI AddHandler perl-script .pl PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders /Directory -- Stephen Walton, Professor, Dept. of Physics Astronomy, Cal State Northridge [EMAIL PROTECTED]
Re: Caching in TT2 or Some Mod Perl oddity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jun 26, 2002 at 11:17:49PM +, Rafiq Ismail (ADMIN) wrote: I have a page which - even after a server restart - reverts to an older version of the page. Whilst I was still debugging, I accidently had Data::Dumper doing a print STDOUT and a lovely $VAR1=[] in the corner of my screen. This has long since been removed from my code, however I keep going through hits of the same page - as I said, even after a restart - where either I have the 'correct' funky page, or on the next hit reverting to the old over funked paged. Sounds like browser caching, or a rather borked transparent proxy. Or both. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9GmXLA4aoazQ9p2cRAkFSAJ9tctOR4sNzmtWHhzyVaebftWMcxgCg1Uoh hlAtmfjtL+weqERfSqbCu5Q= =F7ij -END PGP SIGNATURE-
Re: mod_perl2 Web Application Standard?
Hi, Hi, All this talk of MVC and a universal despatch mechanism has started me thinking about Java Web Applications and how they are bundled into a standard configuration (e.g., Java's Servlet standard 2.3) Would such a standard (albeit optional) be useful for mod_perl2? I think it would be useful for *Perl*. The desire for this is part of what drives the P5EE project (Perl 5 Enterprise Environment) over at http://www.officevision.com/pub/p5ee/ http://p5ee.perl.org/ No one gets too excited about this project yet because it is still experimental/preliminary/finding its way. However, progress is steady, and new contributors are always welcome. The P5EE project was a spin-off of the mod_perl list last October and ended up at [EMAIL PROTECTED] http://mathforum.org/epigone/modperl/spayskerdfeld http://mathforum.org/epigone/modperl/quoxveewo (and August 2001). http://mathforum.org/epigone/modperl/premangdoo/ http://mathforum.org/search/epi_results.html?textsearch=P2EEctrlfile=epigon e/modperl.ctrlbool_type=andwhole_words=yes For people on the mod_perl list who don't know about the project, you may want to familiarize yourself with it. Generally standards run contrary to the TMTOWTDI approach of Perl but there are some advantages in a 'minimal' mod_perl web application standard: http://www.officevision.com/pub/p5ee/ (see Philosophy) * ISP's could install mod_perl applications in a uniform/consistent way - (e.g., the standard should prevent name space collisions etc.) http://www.officevision.com/pub/p5ee/ (see Vision: Pervasive Deployment) * A subset of mod_perl methods could be selected as a basis for the standard allowing other 'container' servers besides Apache (e.g., like http://jetty.mortbay.org - except in Perl not Java) The abstraction in P5EE that you are speaking about is the Context. http://www.officevision.com/pub/p5ee/software/htdocs/api/Context-frame.html The design says that P5EE software can (conceptually) run in a variety of web containers or Contexts. P5EE::Context::CGI P5EE::Context::FCGI P5EE::Context::ModPerl P5EE::Context::ModPerlRegistry P5EE::Context::PPerl and even a number of non-web Contexts P5EE::Context::Cmd P5EE::Context::Daemon P5EE::Context::Gtk P5EE::Context::POE P5EE::Context::SOAP P5EE::Context::WxPerl Of course, I see Modperl as the dominant, high-performance container for web applications for the P5EE. * Software companies (not sure who) could provide replication/clustered/load balanced solutions based on this standard I envision open-source (Perl/CPAN) versions of P5EE::Context::ISAPI P5EE::Context::NSAPI to provide containers for other proprietary servers. Replicated Repositories and clustered/load-balanced Contexts are all part of the open-source vision, not restricted to some commercial provider. * Application configuration/management tools could be used to administer mod_perl application(s) on the same server(s) * We could share 'mod_perl' applications on CPAN more easily/quickly Ideally, I'd like to download a single mod_perl archive file (e.g., application.mod) place it in a 'standard' application directory and then point my browser to the new application. I share your desire. Is this something that could be considered with the next release of modperl2? I'm thinking of something that is really 'lite', not too prescriptive, but achieves the objectives above. Nigel
Re: mod_perl via ssl?
You need to specify a command line option of -DSSL when you start the server. If you're using the stock apachectl, it's usually './apachectl start_ssl' Not that this question is on topic... On Tue, 21 May 2002, Chris Garrigues wrote: I've been lurking on this list for a while but hadn't actually been running mod_perl. I'm now trying to get it working on my system, but have hit a wall that I'm sure someone can tell me how to get around. I'm using the Mandrake RPMs for apache and mod_ssl: apache-conf-1.3.23-4mdk apache-1.3.23-4mdk apache-devel-1.3.23-4mdk apache-modules-1.3.23-4mdk apache-mod_perl-1.3.23_1.26-5mdk apache-common-1.3.23-4mdk libopenssl0-0.9.6c-2mdk openssl-0.9.6b-10 mod_ssl-2.8.7-2mdk openssl-devel-0.9.6b-10 I just updated to this version and think I now have my conf files correct in the new architecture although I haven't actually run anything under mod_perl yet. My question is that all my CGIs that I want to convert to mod_perl run under SSL, but I can't figure out how to enable SSL in the httpd-perl server. Am I missing something simple? Chris -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Seg fault on apache start
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 18, 2002 at 05:03:11PM -0400, Jaberwocky wrote: I'm having some problems with this. Apache seg faults on the call to parse... http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_XML_Parser - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjznMB0ACgkQA4aoazQ9p2doowCePV9S0vujCY5wBp7IlQWaGhID kFcAnRQ9nQqe5usEkqdqmhmTBc3sWGzx =4mc9 -END PGP SIGNATURE-
Re: Restarting named service
You could use sudo and give the apache user permission to run, as root, whichever command you use to restart the server. Steve On Thu, 18 Apr 2002, Abd El-Hameed Mohammed wrote: Hi, How can i restart the named service via mod_perl. The script will be activated via a web page. My apache is configured to use User: apache, Group: apache Is ther any other way except usine User root directive in my httpd.conf file Hamid -- === Stephen M. Gray www.frontiermedia.net
Re: Restarting named service
On Thu, 18 Apr 2002 [EMAIL PROTECTED] wrote: or you would be safer running your name server as named as opposed to root. STEVE It should be run as named, but trying to start and stop it as the named user won't get you very far if you plan on using port 53. :-) === Stephen M. Gray www.frontiermedia.net
Re: Location header blows away Set-Cookie?
I think this is in the Guide somewhere, but the short answer is to use 'err_header_out()' rather than 'header_out' for any type of non-success result. On Fri, 12 Apr 2002, Thomas K. Burkholder wrote: Apologies if this is well-known - a generalized search failed to explain the behaviour I'm seeing. Using: Apache/1.3.23 (Unix) Debian GNU/Linux mod_ssl/2.8.7 OpenSSL/0.9.6c mod_perl/1.26 I'm using a perl handler in which I create a session and bind it to a cookie if a session doesn't already exist, fetch some results from a database, put the results in the session, then redirect to another page that is responsible for pulling the results out of the session and producing the html output. As a test case, I do exactly this: $r-header_out(Set-Cookie = 'foo1=bar1'); $r-header_out(Location = $redir); return REDIRECT; I use curl to test with - the result does not contain the Set-Cookie header. Is it expected behaviour that redirection should blow away Set-Cookie headers, and I just have to find a different way to do this? I'm pretty sure this isn't a caching issue since I'm using curl to initiate the test. Am I barking up the wrong tree? Thanks in advance for any help- //Thomas Thomas K. Burkholder -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: mod_perl restart vs. graceful
Hi Darren,
See my suggested refinement below (I don't like to leave the server
down any longer than needed...8^):
On Tue, 9 Apr 2002, darren chamberlain wrote:
For exactly this reason, I always modify apachectl so that the restart
option looks like:
restart)
timeout=${2:-5}
count=0
$0 stop
while [ $count -lt $timeout ]; do
while [ -f $PIDFILE -a $count -lt $timeout ]; do
echo -n .
sleep 1
count=`expr $count + 1`
done
echo
$0 start
;;
This will sleep for $2 (or 5 seconds) between stopping and starting.
The sleep ensures that the start doesn't get called too quickly.
Steve
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Apache+Modperl Website Statistics
On Wed, 27 Mar 2002, darren chamberlain wrote: If you are using a PerlTransHandler anyway, you can have one that sends the client to a particular page if a cookie is not set: (a) Client requests /foo.html (b) TransHandler sees that cookie is not set, does an internal redirect to /js-set-cookie.html, which does some (client size) js magic and transparantly redirects to the cookie-setting page, which sets the cookie and does its own redirect. (c) TransHandler gets this request as well (it was an external redirect instigated by the client-side javascript), sees that the cookie it is looking for is set, and does the appropriate redirecting (to the right sized page). Better take care to avoid an infinite loop for clients who refuse cookies. Steve === Stephen M. Gray www.frontiermedia.net
Re: Serious bug, mixing mod-perl content
Are you using 2 separate apache processes or 2 virtual hosts within the
same apache process?
If it's the latter, according to Apache's documentation:
If no matching virtual host is found, then the first listed virtual
host that matches the IP address will be used.
(http://httpd.apache.org/docs/vhosts/name-based.html)
So it's possible that the client that is getting the wrong answers is
not specifying the Host: hostname parameter in the HTTP request and
Apache is therefore sending the request to the first virtual host.
Steve
On Tue, 12 Mar 2002, Miroslav Madzarevic wrote:
It seems that my mod-perl virtual hosts are mixing content :(
I don't know why ?
I have virthost1 and virthost2 on mod-perl apache, most of the time you get the
right content when calling respective virthost but sometimes when you call virthost2
you get response from virt. host 1. This is a rare bug but happens.
We're using Mandrake Linux and it's 2 apache's (1 mod-perl enabled and the other
without mod-perl - this one uses mod proxy and mod rewrite).
Can someone please direct me how can I solve this problem ?
-
Best regards,
Miroslav Madzarevic, Senior Perl Programmer
[EMAIL PROTECTED]
Mod Perl Development http://www.modperldev.com
Telephone: +381 64 1193 501
jamph
$_=,,.,,.,,,.,,,.,,,..,,.,,,.,.,,,;
s/\s//gs;tr/,./05/;my(@a,$o,$i)=split//;$_=DATA;tr/~`'^/0-4/;map{$o
.=$a[$i]+$_;$i++}split//;@a=$o=~m!...!g;map{print chr}@a; __DATA__
`~^`~~``^`~`~`^``~`~``''~^'`~^``'``^```~^``'```'~`~
--
===
Stephen M. Gray
www.frontiermedia.net
Authenticating against Active Directory
Does anyone have any experience in writing an authentication handler that authenticates against Microsoft's Active Directory? I have a project for a client who wants to use their existing AD data for user data (username, password, realname, groups, etc). In doing a little googling, it seems that AD is sort of like LDAP, but I couldn't find any definitive info that something like Apache::AuthenLDAP will just work against AD. (The Apache server piece would be Linux, if that matters...) (I saw the recent O'Reilly article on doing AD integration, but that seemed to rely on deploying a proxy process on the AD server, which I'd like to avoid, if possible.) Thanks for any insight anyone can add. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: [OT] Apache Config Problem
Yes, just add a 'Port 80' line to your VirtualHost section. While many folks assume that this directive is for telling apache which port to listen on (it's not -- the Listen directive does that...), it's actually a setting that instructs Apache to use the named port in any generated urls. (At least, that's my understanding of it, and it appears to work like that for me...) UseCanonical tells apache to always use the canonical (ServerName) setting in generated urls -- that allows you to have a ServerAlias for something like 'foo.com', and have generated urls redirect to to 'www.foo.com'. So, if you virtual host was something like: Listen 192.168.0.100:8080 VirtualHost 192.168.0.100:8080 ServerName www.foo.com ServerAlias foo.com Port 80 ... /VirtualHost Then (assuming your bigip sends requests for foo.com to 192.168.0.100:8080) generated urls will be to 'http://www.foo.com:80/' (I think the ':80' is dropped as the default port...) HTH, Steve On Tue, 19 Feb 2002, Robert Landrum wrote: I'm trying to do something really simple and trying to avoid writing an Modperl handler to do it. We have a website behind a bigip running on port 8080. When someone requests a URL that doesn't end with a slash, it's redirected to http://host:8080/path/ . I tried turning off UseCononicalName, but it didn't have any effect. Any suggestions? Thanks, Rob -- When I used a Mac, they laughed because I had no command prompt. When I used Linux, they laughed because I had no GUI. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: mod_perl cookbook ... Where?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 18, 2002 at 06:31:15PM -0500, IEEE Consulting wrote: Where's the mod_perl Cookbook? Grep your favorite bookstore for ISBN# 0672322404. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxxkUQACgkQA4aoazQ9p2coFQCdFbwdhoYjXeWMa0I9aze3tUBn tWoAoKklU/xof5U5h3TVT0K9EzK1Ovtq =rH9E -END PGP SIGNATURE-
Re: mod_perl, mod_gzip, incredible suckage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 11:59:02AM -0800, Jeffrey W. Baker wrote: Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? Compile it. Install it. Works brilliantly. Don't know what your problem might be. Please share offlist, perhaps I can help debug it. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxsMtIACgkQA4aoazQ9p2colACguj32YcweRfM7iOy66v8505Hb mSgAn1o4z1N19iDwO8TutmpX93OBxkJ7 =6v+i -END PGP SIGNATURE-
Re: mod_perl, mod_gzip, incredible suckage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 02:44:53PM -0800, Jeffrey W. Baker wrote: Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on every single request. We have (other than the standard modules) mod_perl, mod_php, mod_ssl, mod_gzip, mod_rewrite, and mod_auth_db, all statically linked. (At one point mod_fastcgi was in this cocktail as well, but was removed once everything was converted to mod_perl.) I do now recall having similar segfaults initially. The trick was reordering the modules in Configuration so mod_gzip came last (which actually puts it first, Apache processes the Configuration file from bottom to top). So the relevant portions of our configure line are: SSL_BASE=/usr ./configure \ --enable-module=rewrite \ --enable-module=ssl --disable-rule=SSL_COMPAT \ --enable-module=auth_db \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a \ --add-module=src/modules/extra/mod_gzip.c With this setup we have never had a problem. And with the most recent mod_gzip (I believe it's 1.3.19.1a) it now properly plays along with mod_perl/mod_php, and compresses their post-processing output as well. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxsQ0MACgkQA4aoazQ9p2fUFwCeKOeIKDEuRR6361UpIc+PMCY1 X+gAnis3HX0X6GanHfovTCvQmejIL7be =Dzyq -END PGP SIGNATURE-
Re: mod_perl, mod_gzip, incredible suckage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 03:18:37PM -0800, Jeffrey W. Baker wrote: Okay, I'll take a run at compiling everything statically. First, just try loading mod_gzip before any other (non-static) module. You might save yourself the trouble of recompiling everything. (Although personally, I've never been able to get a DSO Apache working under any circumstances, but that's probably my problem :) - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxsSTgACgkQA4aoazQ9p2dkRwCfZugAi6UkO2JQUnxBhnw9LxQn lB0AniJ4v074YkVZmHgKtKPZxCxmOTl5 =WJ2b -END PGP SIGNATURE-
Re: Influencing @INC list
OK, I'll be the one to throw out the gratuitous plug for Geoff, etal's book. The Mod_Perl Cookbook has a nice discussion of exactly this in Chapter 2. (I'd give you the page, but I left it at work...) (I'm only through the first few chapters, but from what I've read so far, this is a real winner. Buy it.) Steve On Mon, 11 Feb 2002, Brian Reichert wrote: On Mon, Feb 11, 2002 at 04:29:43PM -0500, Kevin Slean wrote: Mod Perl Mongers... I need to run multiple apache servers on one Solaris 2.7 box configured in such a way that each of them accesses their own private copy of perl libraries. I would like to achieve this configuration with the least amount of changes to my over all implementation. For instance, given 2 apache servers defined in the following 2 directories: /usr/local/siteA - directory tree containing everything for server A /usr/local/siteB - directory tree containing everything for server B The default perl installation on this unix system is under /usr/local/lib/perl5 and the default @INC list is: I believe you can abuse PERL5LIB in each vhost... Kevin -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
[OT] Re: New mod_perl Logo
All right -- I know I should just silently delete this, and let it go, but it's like a bad traffic accident, I just have to sneak a look. In exactly what way do you connote American-style out of any of those names? The fact that Big Foot is a mythical being often associated with the US northwest? (I think the Canadians talk about Big Foot too...) And racist?? Come on, that's certainly a reach... When in doubt, accuse others of being provincial, and act damn indignant. Curse their nationality too... Steve Reppucci On Wed, 30 Jan 2002, Ron Savage wrote: Jeezus you guys. All these American-style names are verging on the racist. This is world-wide code, not f---ing American-wide code. Cheers Ron Savage [EMAIL PROTECTED] http://savage.net.au/index.html - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Wednesday, January 30, 2002 12:48 PM Subject: Re: New mod_perl Logo In a message dated 30-Jan-02 12:50:50 AM GMT Standard Time, [EMAIL PROTECTED] writes: How about BigFoot? Probably not the best for a server application. Might make one think of the footprint involved ... and isn't one of the major reasons to moving to mod_perl to reduce the overhead and footprint of the server? Now Yetti no conotation there. Or Swamp Beast, Sasquatch, or possibly even the local favorite Nessie (I'd love to see Ora get a picture of her on the next book!) -Chris -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: Cgi permission Questions
On Mon, 21 Jan 2002, Joe Bifano wrote: Hi all, My first time on the list. I have been looking at the archives but am not able to find anything on this. Exactly. Because this list is about perl, specifically mod_perl, while your question is about Apache, and its configuration. Please don't ask questions here which have no relevance. There are other lists that discuss these issues. Please visit http://www.apache.org/httpd/, where there is a wealth of great documentation put together through the effort of volunteers to answer exactly this question. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: mod_perl vs. C for high performance Apache modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 14, 2001 at 12:12:09PM -0800, Jeff Yoak wrote: Recently I did a substantial project for a client in using mod_perl. That client is happy with the work, but an investor with their company is very angry because of what a horrible choice mod_perl is for high-load web applications compared with Apache modules and even CGI programs, written in C. Word of the day: ultracrepidarianism Of course, financial investors are experts in the field of backend systems. One in this situation wishes your client would pick up on that. The fact that he's comparing mod_perl (an Apache module) to an Apache module should be a glaring sign of said investor's utter cluelessness. The fact that he's even mentioning CGI versus a server API-level module -- well, I'll stop now before I embarass someone. If anyone on this list could forward any resources that do comparisons along these lines, or even analysis of mod_perl's handling of high-load web traffic, I would be very grateful. Whether C is more efficient than a RAD language like Perl (or Python or PHP) is an incredibly stupid question, because one with sufficient knowledge should know already that the answer is yes. The real question is whether said efficiency is worth the arduous hassle of building the app in C. Considering the speed at which modern servers execute interpreted or JIT-compiled languages, that answer is almost always no. There is fast, but then there's fast enough (and finished developing in 25% of the time). They'll have to decide what's more important. Now, as for case studies, here's a quick list: http://perl.apache.org/sites.html And then this article, outlining how mod_perl was used to build the eToys site: http://www.perl.com/pub/a/2001/10/17/etoys.html And now for a completely shameless plug: http://www.iqcoordinator.com/ Which is a processing-intensive work order management system, built entirely on mod_perl. (Some day I will write an article myself :) Our systems don't even break a sweat. Actually, mod_perl saved us from having to buy more hardware. It's plenty fast. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBpphQOGqGs0PadnEQLW2gCdGonCCAU0aCauPTTsIZMvzcWU1mIAnj3J BBNeCw2RdSN90qTCYDFLUYPP =Exa7 -END PGP SIGNATURE-
Re: mod_perl vs. C for high performance Apache modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Dec 14, 2001 at 12:58:51PM -0800, Jeff Yoak wrote: This is something different. The investor is in a related business, and has developed substantially similar software for years. And it is really good. What's worse is that my normal, biggest argument isn't compelling in this case, that by the time this would be done in C, I'd be doing contract work on Mars. The investor claims to have evaluated Perl vs. C years ago, to have witnessed that every single hit on the webserver under mod_perl causes a CPU usage spike that isn't seen with C, and that under heavy load mod_perl completely falls apart where C doesn't. (This code is, of course, LONG gone so I can't evaluate it for whether the C was good and the Perl was screwy.) At any rate, because of this, he's spent years having good stuff written in C. Unbeknownst to either me or my client, both this software and its developer were available to us, so in this case it would have been faster, cheaper and honestly even better, by which I mean more fully-featured. Ah, the good old my timeless knowledge from the Nixon administration still applies argument. Remember that the speed of both languages has increased geometrically as a function of hardware speed. 5 years ago you may have been talking a difference of a second or two between Perl and C. Nowadays you'll be measuring the differences in milliseconds, if that much. And you're right, one still can't verify the veracity of the ancient benchmarked code. On another list someone was dealing with Perl and DBI against PHP for a database-driven site, with nothing to go on but some ApacheBench numbers showing the PHP page about six orders of magnitude faster. Then one minor difference of note: the Perl program had output about 70MB of data; the PHP program, about 940 bytes. I assume that the PHP program was doing a null loop or something where the query should have been. Get him to do a real unbiased comparison on modern hardware, and then defy him to claim that the milliseconds he saves are worth the effort. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBpsFQOGqGs0PadnEQJ9TgCgtZnIhFLq/L/DeZA5CS4yAjzBRiEAn3ED lTRl2/yaG9eH7BK785GKajp3 =jLX5 -END PGP SIGNATURE-
Re: Case of the Vanishing Symbol Tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 12, 2001 at 01:17:45AM -0500, Daniel Jacobowitz wrote: I'm willing to bet that this is the Known Nasty having to do with how Apache re-reloads modules. Looks that way to me, but I get lost in exactly when/how mod_perl gets called. Are you using mod_perl as a DSO? If so, have you tried it statically? It's static right now. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBeYNAOGqGs0PadnEQLzgwCbBt/CT8tAjtu/69SE1QWZmLWWGxIAoOX9 mxNMxkAu8lgF80C2IzEjWqoS =2S3T -END PGP SIGNATURE-
Re: Case of the Vanishing Symbol Tables -- Solved!
Eureka. Took quite a bit of debugging, but I finally tracked it down. First, the setup...our module structure goes something like this: IQGroup \_ Core |_ IQCoordinator |_ IQDeveloper |_ IQNextNeatApplication The IQGroup class is our master mod_perl handler -- it handles 99% of the talking to Apache, as well as providing the handler() routine, error handling, Apache config directives, etc. All of our apps inherit from it. IQGroup::Core has all the classes shared between apps, then each app gets its own namespace to do whatever with. The problem emanates from perl_clear_symtab, which gets called from the remove_module_cleanup function that Apache::ExtUtils sets up. As it traverses the symbol table, it doesn't bother checking for something special like this (trimmed for brevity): SV = PVGV(0x8440a88) at 0x846130c NAME = Core:: GvSTASH = 0x841d1e8 IQGroup GP = 0x842d830 FILE = /home/thebrain/perllib/IQGroup/Core/Utility.pm EGV = 0x846130c Core:: And gleefully blows it away, thus annihilating the symbol tables for IQGroup::Core and everything under it. Presumably perl_clear_symtab isn't supposed to touch symbol tables other than for the module it's currently dealing with, so the attached patch tells it to leave them alone. This has completely fixed the problem on my end. Note I couldn't find any better way of telling if an entry was a symbol table hash, so feel free to change this if you know a trick I don't. -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ Index: src/modules/perl/perl_config.c === RCS file: /home/thebrain/.cvsroot/mod_perl/src/modules/perl/perl_config.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 perl_config.c --- src/modules/perl/perl_config.c 2001/11/20 23:55:59 1.1.1.1 +++ src/modules/perl/perl_config.c 2001/12/12 23:54:35 @@ -1685,7 +1685,7 @@ CV *cv; dTHR; - if((SvTYPE(val) != SVt_PVGV) || GvIMPORTED((GV*)val)) + if((SvTYPE(val) != SVt_PVGV) || GvIMPORTED((GV*)val) || ((hv = GvHV((GV*)val)) + strstr(key,::))) continue; if((sv = GvSV((GV*)val))) sv_setsv(GvSV((GV*)val), sv_undef); msg23485/pgp0.pgp Description: PGP signature
Case of the Vanishing Symbol Tables
With the PerlModule/%INC problem recently being rehashed, here's another one
involving PerlModule vs. use that will really bake your noodle.
Attached is a full mod_perl trace, where I hacked into perl_require_module a
dump of one of my vanishing namespaces on each module load. So you can
definitely see it's loading up properly. All is well until you reach the end,
where it starts reloading everything, and the namespace is now completely gone.
Exporter predictably throws an error at this point (since @EXPORT_OK is now
undefined) and the server fails to start. OTOH, one wonders how Exporter got
the call, since @ISA is gone as well.
I posted this once before and got blown off -- a pox on to those who tell me to
check @INC or what not. There is nothing wrong with my code or my setup -- the
only change I have to make to get things working is to `use` all the PerlModule
modules in startup.pl first, before they're called with PerlModule. And don't
tell me to just use `use` either -- they all load up Apache config directives,
so PerlModule has to be called at some point so Apache recognizes the
directives. But if things were working as advertised, PerlModule would be all I
need.
The two obvious questions:
1) Where the fsck did everything go?
2) Why does this only emanate when stuff is loaded up via PerlModule? I mean,
look at perl_require_module -- all it does is `eval require $foo`. Hard to
go wrong there.
--
Stephen Clouse [EMAIL PROTECTED]
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. http://www.theiqgroup.com/
perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
PerlRequire: arg=`/opt/apache/conf/mod_perl.startup.pl'
attempting to require `/opt/apache/conf/mod_perl.startup.pl'
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {};
loading perl module 'Apache::Constants::Exports'...Dump of IQGroup::Core::Utility
namespace:
$VAR1 = {};
ok
ok
PerlModule: arg='IQGroup'
loading perl module 'IQGroup'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {};
fetching PerlChildInitHandler stack
PerlChildInitHandler handlers stack undef, creating
pushing CODE ref into `PerlChildInitHandler' handlers
ok
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {
'import' = *IQGroup::Core::Utility::import,
'EXPORT_FAIL' = *IQGroup::Core::Utility::EXPORT_FAIL,
'iqsprintf' = *IQGroup::Core::Utility::iqsprintf,
'is_spider_or_bot' = *IQGroup::Core::Utility::is_spider_or_bot,
'VERSION' = *IQGroup::Core::Utility::VERSION,
'ISA' = *IQGroup::Core::Utility::ISA,
'EXPORT' = *IQGroup::Core::Utility::EXPORT,
'commify' = *IQGroup::Core::Utility::commify,
'htmlize_nowrap' = *IQGroup::Core::Utility::htmlize_nowrap,
'htmlize' = *IQGroup::Core::Utility::htmlize,
'EXPORT_OK' = *IQGroup::Core::Utility::EXPORT_OK,
'BEGIN' = *IQGroup::Core::Utility::BEGIN,
'EXPORT_TAGS' = *IQGroup::Core::Utility::EXPORT_TAGS
};
ok
PerlModule: arg='IQGroup::IQCoordinator'
loading perl module 'IQGroup::IQCoordinator'...Dump of IQGroup::Core::Utility
namespace:
$VAR1 = {
'import' = *IQGroup::Core::Utility::import,
'EXPORT_FAIL' = *IQGroup::Core::Utility::EXPORT_FAIL,
'iqsprintf' = *IQGroup::Core::Utility::iqsprintf,
'is_spider_or_bot' = *IQGroup::Core::Utility::is_spider_or_bot,
'VERSION' = *IQGroup::Core::Utility::VERSION,
'ISA' = *IQGroup::Core::Utility::ISA,
'EXPORT' = *IQGroup::Core::Utility::EXPORT,
'commify' = *IQGroup::Core::Utility::commify,
'htmlize_nowrap' = *IQGroup::Core::Utility::htmlize_nowrap,
'htmlize' = *IQGroup::Core::Utility::htmlize,
'EXPORT_OK' = *IQGroup::Core::Utility::EXPORT_OK,
'BEGIN' = *IQGroup::Core::Utility::BEGIN,
'EXPORT_TAGS' = *IQGroup::Core::Utility::EXPORT_TAGS
};
ok
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {
'import' = *IQGroup::Core::Utility::import,
'EXPORT_FAIL' = *IQGroup::Core::Utility::EXPORT_FAIL,
'iqsprintf' = *IQGroup::Core::Utility::iqsprintf,
'is_spider_or_bot' = *IQGroup::Core::Utility::is_spider_or_bot,
'VERSION' = *IQGroup::Core::Utility::VERSION,
'ISA' = *IQGroup::Core::Utility::ISA,
'EXPORT' = *IQGroup::Core::Utility::EXPORT,
'commify' = *IQGroup::Core::Utility::commify,
'htmlize_nowrap' = *IQGroup::Core::Utility::htmlize_nowrap,
'htmlize' = *IQGroup::Core::Utility::htmlize,
'EXPORT_OK' = *IQGroup::Core::Utility::EXPORT_OK,
'BEGIN' = *IQGroup::Core::Utility::BEGIN,
'EXPORT_TAGS' = *IQGroup::Core::Utility::EXPORT_TAGS
Re: Case of the Vanishing Symbol Tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 11, 2001 at 11:08:07PM -0500, Perrin Harkins wrote: Are you using PerlFreshRestart? Same behavior, on or off. No need to get testy. That came out wrong, apparently. Sorry. You should be able to replace a PerlModule call with Perluse MyModule;/Perl in the same place in httpd.conf. Does that work for you? The Eagle book says to do that with earlier versions. This doesn't work either. They simply refuse to be loaded anywhere other than the startup.pl. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBbuAwOGqGs0PadnEQK1agCZAS4ksWa1P1ddy5v+5TnTnusq07oAn0jt fjNlzg6pzLmMRCSfpJwp5F2o =1Msz -END PGP SIGNATURE-
Re: Case of the Vanishing Symbol Tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 11, 2001 at 05:33:12PM -0800, David Pisoni wrote: IMHO, this looks similar to (though more catastrophic than) the problem I have been dealing with for some time now. From the archive : http://groups.yahoo.com/group/modperl/message/38622 There is a long thread about it. It is presently unresolved. (We're hoping for Divine intervention. We'd settle for Doug. :-) This is actually the thread I was referring to :) The first time I encountered this, Apache actually would start successfully, but accessing the application would error with undefined subroutine App::Class::handler. A glance at Apache::Status revealed the exact behavior you're describing. But you're right, it *is* more catastrophic now, in that it's no longer content with nuking just PerlModule modules, it's eating other ones as well. Just wish I could spot *where* they're vanishing at...tried all day today but no luck. I'll give it another try tomorrow. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBbxNQOGqGs0PadnEQI/kgCg5I9fxWtVp5+WuS/ostqbSNVSCKsAniNK C4lgQ9YycR91+N02vi4pS2l7 =Vl6Y -END PGP SIGNATURE-
Re: Vhosts + mod_perl
Well, you certainly haven't inconvenience yourself by taking the time to look at the copious documentation available on this, now have you? That said, here's a snippet of what you want to use: NameVirtualHost 192.168.0.10 VirtualHost 192.168.0.10 ServerName www.logsoft.com ServerAlias logsoft.com ServerAlias www2.logsoft.com DocumentRoot /var/apache/htdocs Options +ExecCGI +Indexes AddHandler cgi-script .cgi Location /perl SetHandler perl-script PerlFreshRestart On PerlHandler Foo:Bar PerlSetVar SOME_VAR /usr/local/foo /Location /VirtualHost hth, Steve On Sat, 1 Dec 2001, James wrote: Does anyone have a quick example of setting up a vhost with mod_perl enabled please? Also an ordinary cgi-bin, with file extensions .pl and .cgi enabled? Also with a vhost, I can name the host anything I like can't I? For example, say my domain is localhost.localdomain but I'm using dyndns to make it a hostname, say, trains.ath.cx. I can assign fred.trains.ath.cx and john.trains.ath.cx with vhosts, the requests will get piped to my main machine which is trains, and the vhost section will take care of the rest, knowing which document root to use, right? I don't have to mess around with DNS or anything do I to make new subdomains? Is it: virtualhost fred.trains.ath.cx /doc/root Options +Indexes +ExecCGI DocumentIndex ??? index.html default.html perl-handler # hmm, get mod_perl working in /doc/root/perl cgi-bin # hmmm, get a cgi-bin happening in /doc/root/cgi-bin /virtualhost Or something like that? Many Thanks. James -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Re: DSO Issues
If we're collecting a list of things that don't work in a DSO build, add perl subs (via !--#perl sub=My::handler--). At least, they didn't work as of January of this year. On Tue, 27 Nov 2001, John Chia wrote: On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP it. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
RE: Doing Authorization using mod_perl from a programmers perspective
FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: New user help
Build apache first, then build mod_perl. The mod_perl install modifies the apache tree (it asks you for a path to the apache tree to modify, but defaults to ../apachelatest version) If you're new to mod_perl, you'll want to head on over to the guide (http://perl.apache.org/guide) for Stas' great descriptions of the build procedure and lots of other subjects. Also, I find it easier to build apache statically when doing a mod_perl build. (Others are much bolder than me... ;^) Good luck, Steve Reppucci On Tue, 30 Oct 2001, Rudi wrote: Hi, I'd like to join the mod_perl / apache community. I'm having install problems that I've been trying to solve for 2 days with no luck. So I'd like bother you folks with a beginer question. I'm using Debian 2.2, Apache 1.3.14 and mod_perl 1.24_1. I've tried several times and this is a close as I can get. a) unzip both Apache and mod_perl. b) mod_perl is first : perl Makefile.Pl EVERYTHNG = 1,make,make install. c) Now apache : ./configure --prefix=/usr/local/apache --enable-module=rewrite --enable-shared=rewrite --activate-module=src/modules/perl/libperl.a --enable-shared=perl Everything compiles OK. However, my httpd.conf file now has LoadModule perl_module libexec/libperl.so But this is no libperl.so on my hardrive. I've run updatedb and search but there is no libperl.so. As a result apache will no start ( error about libperl.so ) At work I use Coldfusion,PHP and some CGI with perl. I'm looking forward to getting into mod_perl heaps as perl is a tool I can use for both web development and system admin. Thanks in advance. Kind regards Rudi. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
[OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 11:27 PM 10/23/2001 +0800, Gunther Birznieks wrote: At 09:45 PM 10/23/2001, Perrin Harkins wrote: Matt Sergeant wrote: OK, so what are we missing? ... Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. ... I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. Hi, This issue of a P2EE specification has come up before (and I participated in the discussion), but since it is off-topic for the mod_perl list, I would appreciate some referrals of where to go to discuss this. Last time this came up, I was referred to three different mailing lists (also, see http://lists.perl.org/). However, none of the lists were interested in the P2EE problem (including the PerlSDK list). If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. Stephen
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Nathan, At 11:06 AM 10/23/2001 -0600, Nathan Torkington wrote: Stephen Adkins writes: If no one suggests an appropriate list, I propose starting a p2ee group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to perl.org for inclusion in the list of lists. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support viewcvs or similar for web browsing of the CVS repository? Stephen
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: Stephen Adkins wrote: If no one suggests an appropriate list, I propose starting a p2ee group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy (Edition) rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with ok with me messages or how about 'foo'? messages. Stephen
[OT] Re: IPC::Shareable
Hi, The shared memory segment was already created by another user, and it was created without permissions for you to write to it. Try the ipcs command to view existing shared memory segments. Try the ipcrm command to remove an old one. Stephen At 03:02 PM 10/16/2001 -0700, Rasoul Hajikhani wrote: Pardon the off topic thread, I am trying to make IPC::Shareable work with my script, however I get this error: IPC::Shareable::SharedMem: shmget: Permission denied at /usr/local/lib/perl5/site_perl/5.005/IPC/Shareable.pm line 456 [Tue Oct 16 14:44:15 2001] [error] Could not create shared memory segment: Permission denied Does any one know what's up?
Re: Off-topic - Apache Config - Load crises
I agree with the response that you need to do some statistics gathering to try to accurately isolate the cause of your problems. I *don't* agree with the other suggestion that was made to UP the keepalive to 15-20 seconds (the default that apache comes with is 5, IIRC). Here's why: Assuming that you have one server serving both modperl and image requests, those keepalives are tieing up a large, heavy server, doing nothing but waiting for a new potential request. (Right on to the suggestion to try to get those image requests directed to a separate web server which can be separately tuned...) I actually have a snippet from a writeup I did for a client who was experiencing high server loads about a year ago, here's what I wrote then: - KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 In my experience, the performance killer here is KeepAliveTimeout. This defines the number of seconds that a server child will wait for a client to send additional requests over an already-open connection before closing the socket and making itself available to service other clients' requests - this default value is way too high. Where keep alives work well is in situations where an bunch of requests are likely to occur one after another - such as what's typical when fetching an HTML page containing dozens or more image files served from the same server. Keeping the connection open and serving the HTML page and many of its images without tearing down and re-establishing the connection makes sense here. On a heavily loaded server however, having a server hang around idle, tieing up resources for this long waiting for a new request is wasteful. It's much less of a drain to get that process back into the pool of available child servers as quickly as possible, allowing it to service other requests. This is especially true when you realize that the typical browser tries to optimize its transfers by opening up to four separate TCP connections to the server when loading a page's components, thereby tieing up four child servers. Thinking of the typical client request, where an HTML page is fetched and its referenced images are then also requested, it makes sense to me that these requests are going to come very quickly. It certainly seems reasonable to expect that subsequent component requests will occur in under a second, and that if more than a second elapses without a request, then it's likely that all of the components have been read and the user is likely now reading the page. This being said, I like to set KeepaliveTimeout to its lowest value - '1'. In my not-very-scientific tests, this seems to be the best value to balance the latency experienced by any one client with the overall performance of the server. - Lowering the keepalive did the trick for these people. Disclaimer: I don't have any carefully gathered evidence that this idea (setting keepalive to '1') will do what I postulate it should above. But back when I had access to a large website, with lots of bandwidth, we did some empirical tests that certainly seemed to confirm this idea -- setting a smaller keepalive resulted in better 'ab' numbers. I *did* though send a message to the Apache group, and got a response from Mark Slemko which pointed towards this as a possible issue. A couple of other suggestions: Set Timeout to a lower value (maybe 30?) and decrease MaxClients using the techniques described in Stas' guide. Also, I agree that given the network latency of your site, you might be better off setting the keepalives to a higher value than what I recommend in the above (maybe 2?) I'd love hear others' thoughts on this -- ideas for tuning web servers is a fun topic, afaic...! Steve On Thu, 11 Oct 2001, Rafiq Ismail wrote: I know this is a bit off topic, but I could use some immediate advise on server config? Got a server which is getting hit really bad. Have to keep it up. I've got: P Timeout 300 # Keepalive, better on this server... KeepAlive On MaxKeepAliveRequests100 KeepAliveTimeout5 # performance services MinSpareServers 5 MaxSpareServers 50 StartServers20 StartServers20 MaxClients 250 Pings look like: 64 bytes from x.x.x.x: icmp_seq=0 ttl=244 time=1069.3 ms 64 bytes from x.x.x.x: icmp_seq=1 ttl=244 time=984.8 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=244 time=1138.9 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=244 time=1567.1 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=244 time=1622.3 ms 64 bytes from x.x.x.x: icmp_seq=5 ttl=244 time=1382.8 ms 64 bytes from x.x.x.x: icmp_seq=6 ttl=244 time=1145.5 ms 64 bytes from x.x.x.x: icmp_seq=7 ttl=244 time=1065.6 ms 64 bytes from x.x.x.x: icmp_seq=8 ttl=244 time=1133.6 ms There are some really graphic intensive pages here, however I'm not sure if Keep alive is good when there's lots of contention for pages. Should I: i) disable
Re: [OT] 408 http responses?
I've got a couple of dozen this month -- not sure what the source
is, but they definitely seem to be coming from just a few hosts.
Also, many of mine have no URI in the request, they just seem to
connect and not make any request.
Smells like some time of worm...
On Thu, 20 Sep 2001, Nick Tonkin wrote:
Hi all, sorry to bother, but has anyone else noticed a bunch of 408
(client timed out) requests beginning last evening?
Some but not all of these have also been trying the Nimda exploit. Perhaps
Nimda (or another Micro$oft product) is screwing up the clients?
nick@world /usr/local/apachessl/binperl -e
'open(L,/home/nick/logs/httpd_log); while(L){
chomp;my $r=m/408/?4:m/cmd|root|c\+di/?w:;
if($r){$_=~s/(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*/$1/;$c{$r}{$_}++;}}
foreach(sort{ $c{4}{$a}=$c{4}{$b} } keys %{ $c{4} }){
print$_\t\t[$c{4}{$_}]\t[$c{w}{$_}]\n;}'
207.249.143.170 [1] []
207.160.174.25 [1] []
62.149.161.207 [1] []
62.116.29.17[1] []
207.113.14.149 [1] []
209.129.49.65 [1] []
207.168.157.118 [1] []
207.202.38.140 [1] []
61.134.13.47[1] []
207.113.21.89 [1] []
24.67.119.127 [1] []
209.89.119.5[1] []
199.201.128.19 [1] [2]
207.113.25.50 [1] []
207.42.186.90 [1] []
207.113.25.249 [2] []
207.40.42.66[3] []
207.153.76.249 [4] []
207.241.153.3 [5] []
207.12.40.51[6] [16]
207.183.55.149 [6] []
207.217.138.18 [6] []
207.215.53.116 [7] []
207.152.93.12 [8] []
207.152.93.17 [8] []
207.77.187.76 [8] []
207.71.8.190[8] [384]
207.32.123.115 [9] []
207.252.220.55 [12][]
207.228.113.164 [12][]
207.242.45.234 [12][]
207.71.105.133 [13][112]
207.30.192.101 [14][]
207.248.190.158 [15][]
207.105.76.201 [15][]
207.215.126.141 [15][]
207.232.253.221 [16][]
207.245.74.7[16][]
206.221.254.59 [16][]
207.97.117.43 [16][]
207.208.128.185 [16][]
207.203.42.126 [16][]
207.190.221.23 [16][]
207.227.70.194 [16][]
207.127.178.25 [16][]
207.178.85.42 [16][]
207.153.199.78 [16][]
207.153.229.122 [16][]
207.236.169.100 [16][]
207.88.22.128 [16][]
207.252.1.68[16][]
207.170.35.143 [16][]
207.212.64.137 [16][]
207.76.239.206 [16][]
207.196.218.5 [16][]
207.137.76.119 [17][]
207.71.228.1[91][274]
~~~
Nick Tonkin
--
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
RE: ANNOUNCE: Starting work on Apache::RedirectUnless
Hi, I have been following this thread with interest because I have been struggling with the same problem. I define it this way. * To achieve secure authentication which is widely supported, you need to use Basic authentication over SSL * All URLs which can be accessed with HTTPS can be accessed with HTTP * I secure certain directories with .htaccess and all of the links in my site which point to them are via HTTPS, so as long as people always follow the links, they will never transfer the password in clear text (essentially) over the network using HTTP. * However, if they type the URL directly into the browser and they *forget* to use https but rather use http, their password is exposed to network sniffers. I think that it was to solve this problem that J.J.Horner suggested the module. Any request to a secured area using HTTP would be automatically redirected to the same URL with HTTPS instead. Thus, the browser would never, ever be prompted to surrender the authentication credentials (password) in the clear over HTTP. Thus, I see great value to JJ's suggested module. Is there an easier way to safeguard against Apache prompting for a password over HTTP? Stephen At 01:41 PM 9/18/2001 -0500, Christian Gilmore wrote: A realm is defined by the following three things: 1) AuthName 2) ServerName (well, the server name in the URL actually) 3) Port (well, the port to which the browser is talking) If these three things are not always the same, the browser will prompt the user to re-authenticate. So, you cannot authenticate a user on your https port and magically expect that information to be passed by the browser to your http port. You'd have to do application-layer session handling with some kind of shared information across services. There are security implications to consider here... Regards, Christian -Original Message- From: 'J. J. Horner' [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 18, 2001 12:01 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ANNOUNCE: Starting work on Apache::RedirectUnless The problem with that solution is that we have 2 virtual hosts, one http, one https, on one machine. https is the only available transport outside of our network, while the http server is available internally. This is a production webserver, with existing information, applications, etc. We don't want to redesign our existing setup just to move content to a secure virtualhost when someone wants to authenticate. This approach allows us to keep things from the developer side very transparent. Developers can continue to maintain and create as usual, with the added step of a login being transferred by https method. If I were designing a server from scratch, I would plan better, but since we are trying to implement encrypted basic authentication after the server, sites, applications are in place, we have to work around them. With the AuthName set to one value across the server, we may be able to prevent too many logins. We need to keep the same content on both virtualhosts as much as possible. Ideas? Comments? Thanks, JJ * Christian Gilmore ([EMAIL PROTECTED]) [010918 11:36]: Putting it into the auth phase would be appropriate, but I have to wonder why this module is needed other than to refrain from keeping your configuration file clean. Your unsecure virtual host should have no auth statements in it if you want all auth to be on your secure virtual host... You'll need to have your entire session where you want the user to authenticate on the same virtual host, else the user will be prompted multiple times or you will have a security gap if you're leaving it all up to the service layer. Regards, Christian -Original Message- From: J. J. Horner [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 18, 2001 8:51 AM To: [EMAIL PROTECTED] Subject: ANNOUNCE: Starting work on Apache::RedirectUnless I have need of a module that will redirect to https anytime basic authentication is required. I figure the best way to do this is to step in at the authentication phase, and should authentication be required and the method be http, redirect to https for any and all basic authentication traffic. Perhaps after this, redirect to http, if desired. Any comments or suggestions? Thanks, JJ -- J. J. Horner H*,6d6174686c696e40326a6e6574776f726b732e636f6d *** H*,6a6a686f726e65724062656c6c736f7574682e6e6574 Freedom is an all-or-nothing proposition: either we are completely free, or we are subjects of a tyrannical system. If we lose one freedom in a thousand, we become completely subjugated. -- J. J. Horner H*,6d6174686c696e40326a6e6574776f726b732e636f6d *** H*,6a6a686f726e65724062656c6c736f7574682e6e6574
Re: [PATCH] $r-print won't print reference to PVIV or PVMG
Turns out PVNV is a possibility as well (generally if the scalar is a
zero-length string). Here's an updated patch.
--
Stephen Clouse [EMAIL PROTECTED]
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. http://www.theiqgroup.com/
diff -ur mod_perl-1.26.orig/src/modules/perl/Apache.xs
mod_perl-1.26/src/modules/perl/Apache.xs
--- mod_perl-1.26.orig/src/modules/perl/Apache.xs Fri Jul 6 15:15:04 2001
+++ mod_perl-1.26/src/modules/perl/Apache.xsSat Sep 8 18:08:47 2001
@@ -1171,7 +1171,8 @@
for(i = 1; i = items - 1; i++) {
int sent = 0;
-SV *sv = SvROK(ST(i)) (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
+SV *sv = SvROK(ST(i)) (SvTYPE(SvRV(ST(i))) == SVt_PV ||
+SvTYPE(SvRV(ST(i))) == SVt_PVIV
+ || SvTYPE(SvRV(ST(i))) == SVt_PVNV ||
+SvTYPE(SvRV(ST(i))) == SVt_PVMG) ?
(SV*)SvRV(ST(i)) : ST(i);
buffer = SvPV(sv, len);
#ifdef APACHE_SSL
PGP signature
[PATCH] $r-print won't print reference to PVIV or PVMG
There's a bug in the write_client routine where it won't print a reference to a
scalar that has been upgraded from a PV. A string comparison will usually
trigger an upgrade to PVIV. Additionally, with PerlTaintCheck on, a tainted
scalar will be a PVMG, because the tainted flag is magic. At first I thought
the latter could be intentional behavior, but passing the string itself instead
of a reference was allowed, so it appears to be just an oversight. The attached
patch fixes both of these cases.
--
Stephen Clouse [EMAIL PROTECTED]
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. http://www.theiqgroup.com/
diff -ru mod_perl-1.26.orig/src/modules/perl/Apache.xs
mod_perl-1.26/src/modules/perl/Apache.xs
--- mod_perl-1.26.orig/src/modules/perl/Apache.xs Fri Jul 6 15:15:04 2001
+++ mod_perl-1.26/src/modules/perl/Apache.xsTue Aug 28 20:47:37 2001
@@ -1171,7 +1171,7 @@
for(i = 1; i = items - 1; i++) {
int sent = 0;
-SV *sv = SvROK(ST(i)) (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
+SV *sv = SvROK(ST(i)) (SvTYPE(SvRV(ST(i))) == SVt_PV ||
+SvTYPE(SvRV(ST(i))) == SVt_PVIV || SvTYPE(SvRV(ST(i))) == SVt_PVMG) ?
(SV*)SvRV(ST(i)) : ST(i);
buffer = SvPV(sv, len);
#ifdef APACHE_SSL
PGP signature
Modules `use`d by PerlModule vanishing after startup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have recently been working on a framework for moving our applications to mod_perl but I've run into a very odd problem. I load our program's main Apache handler, with: PerlModule IQGroup::IQCoordinator And then set it up as a PerlHandler for a virtual host. But when I attempt to load the program, it fails and throws this into the error log: [Thu Aug 9 14:29:05 2001] [error] Can't locate object method GetCurrentRequest via package IQGroup::Core::ApacheRequest (perhaps you forgot to load IQGroup::Core::ApacheRequest?) at /usr/lib/perl5/5.6.1/IQGroup/IQCoordinator.pm line 60. Except it IS being loaded, it's the first module `use`d by our PerlHandler. A trace on the Apache process even shows the module being read at startup. When I insert Apache::Status and take a look at the symbol table, it shows the IQGroup::Core::ApacheRequest namespace, but with no symbols in it! Even more odd, the modules that it in turn uses DO show up, all symbols intact. Now, if I load the handler in the startup file: use IQGroup::IQCoordinator; then everything loads properly, although I get a slew of subroutine blah redefined messages in the error log when it hits the PerlModule directive. This doesn't seem like intended behavior (nothing I read suggests it's supposed to work like this)...so what's eating my module's symbol table? - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBO3Lr3gOGqGs0PadnEQLHTACgrvUHoQSRdUDYntXkzmnCOapDy5MAn2Ex HIvS8i793nzDBqowJ/EMf7T9 =0PSY -END PGP SIGNATURE-
Re: [OT] WebMacro (was: RoboWeb 1.0b, web application test suite generator)
Hi, Please be aware that WebMacro is a moderately popular Java templating tool hosted at http://www.webmacro.org Naming it WWW::WebMacro might be a bit confusing. It's your choice. I just wanted to make you aware of the other WebMacro. Stephen At 08:48 AM 7/25/2001 +1000, Jeremy Howard wrote: Gunther Birznieks wrote: If you guys end up finally collaborating, one very minor request I would have is that it goes into CPAN as something more standard like WWW:: namespace rather than a marketing name like RoboWeb. The current plan is for the 'scripting language' which provides a simple interface for scripting interactions will be called 'WWW::Automate'. The project that combines RoboWeb and WWW::Automate into a flexible recorder for web interactions might be 'WebMacro' which would appear in CPAN as 'WWW::WebMacro'. These are all preliminary suggestions and open to discussion. HTTP::WebTest already is in an appropriate place in the hierarchy, and is descriptively named. HTTP::WebTest will probably be able to use WWW::Automate scripts (either as a plugin in just through its generic Perl API) but this doesn't require any new project or name. If anyone is interested in contributing, note that RoboWeb is already on SourceForge, and WWW::Automate will be up in the next week or two. Contact me privately if you'd like more information on getting involved.
Re: Real Widgets and Template Languages
Gang, First, a reminder to sign up on perl-widget-developer if you want to keep up with this thread. Already there are posts going there that are *not* going to modperl. http://sourceforge.net/projects/perl-widget We have achieved Milestones 1 and 2. * Milestone 1 - a proof of concept prototype of code * Milestone 2 - a SourceForge project set up for it ... Then given the assumption that those objects are simple, many more people can implement them. If I have to be concerned about a lot of stuff everytime I make a widget like multilingual support hooks and event hooks then I will never write a widget because I don't have time. This is why I want widgets to be tiny and atomic. Let's make it simple. If you want multilingual can there be some way of making the multilingual features a wrapper around existing atomic widgets? Same for events and other such expert features. ... It is absolutely my intent to satisfy the minimalist's needs. Gunther intends to use these widgets in a simple and elegant way which represents how *many* people will first use the Perl Widget Library. I promise that simple widgets will be simple to write. Frankly, complex widgets will be pretty simple to write. I want a module that fits into people's *existing* software. After that, they may find it valuable to expand and use the other features. I envision the following four user-driven Milestones. (Real users, real value!) If we satisfy the first-round needs of Gunther, Jay, and Stephen, we will have a set of software which meets many of your needs out there. Please do *not* discuss this post on the modperl list, only on perl-widget-developer. I also don't want to put a lot of emphasis on what feature is in what release. Essentially, this is my attack plan. Any of you are free to accelerate the development of one or another feature. o Milestone 3: get it ready for Gunther Birzniek's needs x get HTML generation of Pods working to own site x get rid of -w warnings in cgi-bin/cgiexample o add named-parameters to constructors: Controller, State, Config o add named-parameter, state_args = $cgi o resolve $widget-value() and $widget-values() * When Gunther is happily using the PWL in his application, we will consider this milestone achieved. * Gunther, I am close to a release that I think will be usable to you. I may then need you to write a Widget::Config::Extropia or whatever and give me feedback on what sucked about the API. After that I need you to come up with a detailed checklist of changes that need to be made to achieve the milestone. (Of course we will discuss it all on the perl-widget-developer mailing list.) o Milestone 4: internationalization for Jay Lawrence's needs o incorporate concepts of internationalization (string lookup) o add Widget::HTML::TextLabel (?) widget with internationalization abilities o add Widget::HTML::Money (?) widget with internationalization abilities * When Jay is happily using the PWL in his application, we will consider this milestone achieved. * Jay, same for you as for Gunther. I just put his milestone before yours because I want to make the simple things simple. But of course we will be working on it all at the same time. o Milestone 5: enhance the vision for Stephen Adkins' needs o add Widget::HTML::Template widget o add Widget::HTML::DualOrderedMultiSelect widget o incorporate a parent concept into widgets, and event bubbling o incorporate concept of browser sensitivity o add support for Javascript in the head o add cgi-bin/wexec (CGI script for running full-widget UI) * When Stephen is happily using the PWL in his application, we will consider this milestone achieved. o Milestone 6: Release as Widget-1.00 and announce to modperl and Perl community o get Pod documentation of classes up to speed o create a better statement of what this is o create a list of have you ever wished that... ? questions to interest people o add mod_perl support
Re: Real Widgets and Template Languages
At 09:49 PM 5/29/2001 +0800, Gunther Birznieks wrote: At 12:15 PM 5/28/01 -0400, Stephen Adkins wrote: Hi, Development of a straw-man set of Perl Widget Library core classes is going well. A Sourceforge project (perl-widget) is in the process of being set up too. (I will announce when it is set up.) ... The state information can be accessed from *any* source by implementing an appropriate Widget::DataSource::State class (and using some additional, not-yet-implemented arguments to Widget-controller()). I think it would be better as a Widget::State::DataSource rather than the other way around. From the way you describe it, this is really an interface to getting state information that should be retrieved from a DataSource specific state driver. I have come to the same conclusion. I am changing the design to have three core base classes (other than the widgets): Widget::Controller Widget::Config Widget::State A CGI program might run with the following derived classes: (These are the initial defaults I am working on.) Widget::Controller::CGI Widget::Config::XML Widget::State::CGI All of these drivers may be overridden, as long as the driver you replace it with conforms to the interface definition described by the core base classes. (Kind of like a Java interface. You would be encouraged to derive from the core base classes, but that is not necessary.) ... I don't understand the Widget::Controller. Can you say more about this? The Widget::Controller (or perhaps, Widget::CGI::Controller) is the container class that you spoke about in your original post. I call it a Controller rather than a Container because I envision it being able to dispatch events generated by the widgets. Ah. I just want something to contain the widgets essentially. So perhaps from my perspective events aren't necessary and I would potentially just place the widgets into an array representing my HTML screen. I have found that event handling comes in surprisingly handy even for simple tasks. Essentially, it allows widgets to define callbacks. For instance, the DateDropDowns widget defines an event change (modelled after the Javascript onChange event) that, when triggered, concatenates the , MM, and DD back into -MM-DD. The following is working code. Notice that the $wc-dispatch_events($query); statement takes care of whatever widget housecleaning there may be (in this case, recomposing the date as a single variable from the three drop-downs). :: cgisample :: #!/usr/local/bin/perl -w ## # cgisample ## # This is an example of a CGI script that uses the capabilities # of the Perl Widget Library minimally. # It looks like any other perl script which uses the CGI.pm # library. # See 'wexec' for an example of a CGI script that uses # the full capabilities of the Perl Widget Library. ## use lib /usr/ov/acoc/dev/src/Widget; use CGI; $query = new CGI; use Widget; $wc = Widget-controller(); $wc-dispatch_events($query); print EOF; Content-type: text/html head titlecgisample/title /head body bgcolor=#ff h1cgisample/h1 hr form method='POST' EOF $anniv_dt = $wc-widget(anniv_dt); $button = $wc-widget(check_it); print Anniversary Date: , $anniv_dt-html(), br\n; print $button-html(), br\n; print Your anniversary date appears to be: , $anniv_dt-value(anniv_dt), br\n; print EOF; /form /body /html Also will we require XML to configure? Or is this also an optional feature that you more or less want for yourself but others can choose to not use? Configuration data is read in via the Widget::Config class, and this class can be replaced with a class which reads config data from any other source, as long as it conforms to the same calling interface. I was under the impression that XML was your desired means of writing a config file. Do you have a preference to use something different? I like XML for Config files, we use that in our Java stuff all the time. But Perl is one of the nicest and flexible config file languages out there. IE My config file is Perl. Anyway, I think it is weird to think of configuring just widgets. Usually you configure an application and widgets are a part of that. But everyone here will have a different way of preferring to write their application config whether it's XML or Perl and what features of these that are used (eg just a set of scalars or references to hashes or ... ?) or in the case of XML using attributes versus subtags... I had the hunch that everyone's configuration needs would be different. Hence the Widget::Config (interface) and Widget::Config::XML (driver) design. (Thanks for the input.) I am not quite sure that the configuration is so extensive for each individual widget that it can't be done by having a named parameter constructor similar
Re: Real Widgets and Template Languages
At 05:27 PM 5/29/2001 +0200, Issac Goldstand wrote: My $0.02 on XML config files. Although they may be attractive to some, personally, I don't like them. I see XML is merely the expression of the configurable parameters of the object. IE it is just a means to the end. Personally, I would like to define my widget properties through a GUI and then will probably use Storable to dehydrate and rehydrate my widget objects. I would never want to code up XML data and I don't think I'm alone. :) Definately when it comes to interchanging your widget data with another system something like XML really starts to make sense. I don't think it makes sense necessarily for your internal day-to-day operations. What I would advocate is that there are a variety of sources for widget configuration data from something as simple and elegant as Perl code to XML of some layout to Storable data stored in a blob field of a DBI source. Actually, I personally think that you're both correct here - I think the proper way to stash the widgets would be through Storable. If you wish to do it through XML, then that should call for an extension to Storable which can store/retrieve data from XML. Issac I completely understand what all three of you are saying, and I think the needs of the Gunther and Jay are being accommodated in the new design. However, a note on XML and Storable ... The XML::Simple class allows you a cache option (which I am using) where it caches the perl data structure in a Storable. The XML::Simple class reads the XML file into a perl data structure, then stores it as a Storable. On subsequent reads, it checks the timestamps of the .xml file and the .stor file and only rereads the XML file if it is newer than the .stor file. Otherwise, it just reads the .stor file. This appears to be about 3x faster. It would be kind of interesting if the Storable class were extended to store as XML ... ;-) Stephen
Re: Real Widgets and Template Languages
At 09:53 PM 5/29/2001 +0800, Gunther Birznieks wrote: At 05:17 PM 5/28/01 -0400, Stephen Adkins wrote: ... $widget = $wc-widget(first_name); print First Name: , $widget-html(), \n; A widget type has already been defined. So I don't see that the method to output it's display should be called html() which is, well, HTML specific. I prefer print First Name: , $widget-display(), \n; Since widgets are components that know how to display themselves whether its WML or HTML or whatever. This is a philosophical design decision that I have been struggling with. The widget does indeed know that it should generate HTML, so it could have a method, $widget-display(), $widget-draw(), etc. However, this implies that the widget has the freedom to decide how it should render itself and that the caller does not need to know. This is not correct. The caller in this case has already cooked up a bunch of HTML and is counting on the widget to produce HTML which can be inserted. The widget does *not* have the freedom to render any other way. This is why I have (sort of stubbornly) stuck with the $widget-html() method despite the unanimous suggestions for a $widget-display() method. I do believe there is a place for a display() method, but it is at the controller level. The is the level at which the caller may not know what technologies are being used by the widgets. This whole discussion brings out two other important design decisions. 1. What are the UI technologies we really wish to support? (i.e. is this *really* a Widget or an HTML::Widget library?) 2. Which classes represent Logical Widgets and which Physical Widgets? 1. TECHNOLOGIES I propose that the following technologies will have supporting Controller/State/Widget combinations to make this not just another web widget library. * CGI/HTML - a web application * mod_perl/HTML - similar, a web application using mod_perl * WAP/WML - driven from a WAP device * X11 (Gtk-Perl)- an X windows application * Curses (terminal) - a screen-oriented terminal application * Term - a line-oriented (scrolling) terminal application * Cmd - similar to Term, but the state must be saved between each cmd (I know I'm stretching the paradigm a little bit here, probably beyond what is reasonable. If you don't think one or more of these is a good idea, please keep it to yourself. I have a vision for it, and even if it's not very useful, it will shape the abstractness of the design elements. On the other hand, I would welcome suggestions for additional UI technologies that I might consider supporting.) One of the primary design rules is to *not* fall into the least common denominator trap. Many cross-platform application frameworks have done this and failed. Rather, the design goal is to *enable* the widget to fully utilize the capabilities of the technical environment it is in. This brings me to the next topic. 2. LOGICAL vs. PHYSICAL USER INTERFACE ELEMENTS I have spoken about the separation of the logical and physical user interface. This facilitates applications being written to the logical interface. The physical UI is then determined at a combination of configuration-time (config file) and run-time (user preferences, browser capabilities, etc.). As the library has developed, it has become clear that the logical UI is really only a figment of the coder's imagination, represented by code like $widget = $wc-widget(file_name); However, the Widget::Controller ($wc) decides (based on config and runtime values) which *physical* UI widget is returned. This could be a drop-down list box (select), a text box, a set of radio buttons, or some sort of complex/compound file chooser widget. So when you code a widget, it is a physical widget. The selection between physical widgets in order to fulfill the requirements of the logical widget are all decided by the Widget::Controller. Similarly if the Controller is a CGI/mod_perl Controller, it will only choose HTML widgets, whereas if the Controller is a WAP Controller, it would only choose WML widgets, etc. Note: This allows you to write physical widgets which are tied intimately with a particular browser version. The Controller and Config mechanism would *allow* you (not force you) to write an application that falls back gracefully and uses other physical widgets for different browsers. A Menu widget using all sorts of whiz-bang DHTML on IE 5.0 could be rendered sanely using a different visual paradigm on an NS 2.0 browser (or Lynx, or Curses!) using a different physical widget. This brings us back to the debate over the display() method vs. the html() method. Every widget class only runs in a certain environment. An HTML widget is being told to emit HTML, hence the method name html(). In addition, the display() method really does not display anything. It simply returns HTML. It is only displayed when the HTML is printed to STDOUT
Re: Real Widgets and Template Languages
At 10:04 AM 5/29/2001 -0700, [EMAIL PROTECTED] wrote: On Tue, 29 May 2001, Stephen Adkins wrote: Right. I have many more requirements I eventually want to support (such as internationalization). The trick is making the design such that it works in the simple case for simple things, while supporting advanced features for those who wish to use them. I think it is coming together pretty well. I hope you didn't mean to say eventually! ;-) Me - I need I18L'n right off the top. If my widgets aren't multilingual then I'll have to go elsewhere. 75% of my apps are bi and trilingual. I think we should bite the bullet and start talkin Unicode and ISO-639 language codes right at the beginning. OK. The priority of internationalization has been increased. Here is the first snapshot of code. http://www.officevision.com/pub/Widget/ Soon I will have the Sourceforge site up and we can stop clogging up this mailing list. Stephen
Re: Real Widgets and Template Languages
At 03:42 AM 5/30/2001 +0200, Issac Goldstand wrote: Wait a second, here... I was under the assumption that the Widget library was not going to be limited to HTML output only. According to your page, it seems that the only customization that you plan on doing is to modify the HTML to work properly with specific browsers (eg, MSIE vs Mozilla/Netscape). ... Issac Don't get worked up. The documentation on the page is about a week old. http://www.officevision.com/pub/Widget/ The link to the code is the only new addition. All of the comments you have read on this mailing list are accurate. I recommend you download the code, take a look, then comment. Stephen
Re: Real Widgets and Template Languages
Hi,
Development of a straw-man set of Perl Widget Library core classes is
going well. A Sourceforge project (perl-widget) is in the process of being
set up too. (I will announce when it is set up.)
The first 0.01 release will be for public comment on
the structure and concepts of the core classes.
With regard to all of the debate on closures/classes/etc., let me say that
I intend for the PWL to be useful in a variety of environments with
different people using more or less of the features.
I am favoring flexibility over performance at the moment, so full classes
are being used to access the different features of the different systems
with which it will need to interface.
At the low end, the PWL will support the simple use that Gunther requires:
simple generation of HTML of a named widget based on configuration
information.
At the high end, Jay Lawrence and I envision much more sophisticated
features ...
but let's not let the consideration of those get in the way of
accomplishing our
first task as described above.
A Template Toolkit user should be able to say
[%PERL%]
use Widget;
$stash-{wc} = Widget-controller();
[%END%]
Birth Date: [% wc.widget(birth_date) %]
or eventually something simpler like
[% USE wc = Widget %]
Birth Date: [% wc.birth_date %]
and the appropriately configured HTML will be inserted.
For non-users of Template Toolkit, they can do the comparable perl ...
use Widget;
$wc = Widget-controller();
$widget = $wc-widget(birth_dt);
print Birth Date: , $widget-html(), \n;
The rendering of this widget as HTML requires at least the following
* config information (Widget::Config)
* state information (to get the current value) (Widget::CGI::State in a
CGI environment)
The state information can be accessed from *any* source by implementing an
appropriate
Widget::DataSource::State class (and using some additional,
not-yet-implemented arguments
to Widget-controller()).
see below for more comments ...
At 11:10 PM 5/28/2001 +0800, Gunther Birznieks wrote:
At 02:16 AM 5/25/01 -0400, Stephen Adkins wrote:
...
I have done the Widget.pm convenience functions and factory code.
I am working on the Widget::Config class to read XML config data using
XML::Simple.
Then on to Widget::Base a parent class for all implemented widgets.
Then on to Widget::Controller which will be handed a CGI object
(or Apache::Request or whatever using one of the much-commented on schemes)
and dispatches events detected from submit buttons, etc.
Then I do my first actual widget, Widget::HTML::Date.
I'll camp on this while I get lots of feedback.
I don't understand the Widget::Controller. Can you say more about this?
The Widget::Controller (or perhaps, Widget::CGI::Controller) is the
container class
that you spoke about in your original post. I call it a Controller rather
than
a Container because I envision it being able to dispatch events generated
by the
widgets.
Also will we require XML to configure? Or is this also an optional feature
that you more or less want for yourself but others can choose to not use?
Configuration data is read in via the Widget::Config class, and this class can
be replaced with a class which reads config data from any other source, as
long as
it conforms to the same calling interface.
I was under the impression that XML was your desired means of writing a
config file.
Do you have a preference to use something different?
Thanks,
Gunther
Stephen
Re: Real Widgets and Template Languages
I don't understand the Widget::Controller. Can you say more about this? Also will we require XML to configure? Or is this also an optional feature that you more or less want for yourself but others can choose to not use? Hi, Below is running code for the Perl Widget Library. So far, there are only two widgets. * a generic Widget::HTML::Element * a drop-down menu Widget::HTML::Select Are there early comments on the interface from Perl? Is this shaping up into what was desired? Stephen shark:/usr/ov/acoc/dev/src/Widget/examples more Widget.xml Widget.2 :: Widget.xml :: config widget name=first_name tag='input' type='text' size='14' maxlength='99'/ widget name=last_name widget-class='Widget::HTML::Element' tag='input' type='text' size='14' maxlength='99'/ widget name=birth_dt widget-type='date'/ widget name=sexwidget-type='sex'/ widget-type name=date tag='input' type='text' size='14' maxlength='99'/ widget-type name=sex widget-class='Widget::HTML::Select' domain='sex'/ domain name=sex item name=M label=Male/ item name=F label=Female/ /domain /config :: Widget.2 :: #!/usr/local/bin/perl use lib ..; use Widget; my ($wc, $widget, @widgets); $wc = Widget-controller(); $widget = $wc-widget(first_name); print First Name: , $widget-html(), \n; $widget = $wc-widget(last_name); print Last Name: , $widget-html(), \n; $widget = $wc-widget(birth_dt); print Birth Date: , $widget-html(), \n; $widget = $wc-widget(sex); print Sex: , $widget-html(), \n; shark:/usr/ov/acoc/dev/src/Widget/examples Widget.2 First Name: input name='first_name' maxlength='99' size='14' type='text'/ Last Name: input name='last_name' maxlength='99' size='14' type='text'/ Birth Date: input name='birth_dt' maxlength='99' size='14' type='text'/ Sex: select name='sex' option value='M'Male/option option value='F'Female/option /select
RE: Concepts of Unique Tracking
How quickly we forget ... Don't we remember the huge outcry over Intel putting a unique ID in every CPU which would could be transmitted via web browser and destroy all of our privacy? The frustration we feel as programmers who are trying to identify anonymous visitors is exactly what privacy is all about. And I am thankful for it. Get used to it. People need to opt-in in order to be identified. The closest thing we can get to this is people leaving their cookies enabled on their browser. Stephen At 10:43 AM 5/25/2001 -0700, Jonathan Hilgeman wrote: Let's take over the world and recompile all browsers to have them send out the MAC address of thet network card. Jonathan
Re: Real Widgets and Template Languages
Jay, I think that pretty much describes what I have in mind ... plus a few other features. Hopefully within a week or two (based on demands of other *paying* jobs), I will have a working distribution with most of the bare-bones plumbing in place and a little configurable date widget implemented. This will allow me to solicit feedback on the plumbing and concepts before I go hog wild on implementing a host of widgets. (In fact, I predict the package will be downright boring for a month or more, to those who don't want to shape its development, while I get the concept and the internals right.) I have done the Widget.pm convenience functions and factory code. I am working on the Widget::Config class to read XML config data using XML::Simple. Then on to Widget::Base a parent class for all implemented widgets. Then on to Widget::Controller which will be handed a CGI object (or Apache::Request or whatever using one of the much-commented on schemes) and dispatches events detected from submit buttons, etc. Then I do my first actual widget, Widget::HTML::Date. I'll camp on this while I get lots of feedback. Stephen P.S. I have submitted an application for a Sourceforge project called the Perl Widget Library. The short name is perl-widget. I am waiting for approval from Sourceforge. This won't hold me up though. I plan on posting distributions on my web site. At 12:28 PM 5/24/2001 -0400, Jay Lawrence wrote: Hey all, Let me describe what I have been imagining as the ideal widget for what I am writing: 1 - it can look to its environment to determine how to render itsself - am I on an HTML page or something else? 2 - it has properties that can be set and remain static no matter who's using it - size, shape, colour, max, min 3 - it has properties that are customized by the individual user of the widget - current value, theme choice, 4 - it can tell developers and environments what it can do - switch_on, switch_off, increment, decrement, etc. 5 - it is capable of persisting from invocation to invocation - user 1 sets current_value to x - which always comes back for user 1 6 - it can look to its environment for interhitable properties - global theme choice, global font, etc. 7 - templating systems know how to call widgets - because they always use the same method to display themselves 8 - widget can interact with each other - increasing value on slider widget changes current record # value for database record widget 9 - access restrctions - users can override some values but not others - not everyone can even use this widget, etc. 10 - multilingual - some things are language neutral others are not - size would probably be neutral whereas label would be language sensitive 11 - above all it is easy to use - ie/ don't make me set a zillion properties just to make it work! I am going to throw out a buzzword, gasp, which may serve as a model for what we are talking about: JavaBeans. I do feel there is a lot of additional complexity there but it is along the right direction IMHO. If you translate my wishlist into technologies I think I am talking about: A - a good persistant object management environment B - user sessions C - integration of widgets (objects) to user sessions D - Object API (properties and methods) which are consistant and predictable E - self documenting objects This is what I have been looking for/writing myself! I am really eager to chip in on this project and get it going ASAP - but do acknowledge the need for hearty discussion about what people really want not just my own views. :)) Jay
Re: Real Widgets and Template Languages
Hi, I will step up to write this code. (if it is what I think it is) I have responded to the message by beginning a requirements document. http://www.officevision.com/pub/HTML-Widget/ Please read it and send me any comments. The following are the questions I need advice on in order to proceed. * What CPAN package namespace should I use? I studied the existing packages, and what we are trying to do looks like it fits under the existing top level package HTML. I propose to take the space HTML::Widget (see package layout in design doc). Gunther suggested the top-level Widget name space. I was under the impression that we should stay away from creating new top-level entries at CPAN unless there was really *nothing* similar. Confusingly, there is already an HTML::Widgets. Thoughts? * What CPAN packages should I begin with and build upon? CGI and Apache::Request were mentioned. I figure I will use these. HTML::StickyWidgets was also mentioned. Do you mean HTML::StickyForms? Are there others I should build dependencies on? * Should I begin immediately with a new Sourceforge project? another way? The codebase I will begin with is in CVS on my local server. Perhaps I should just continue that way and post versions to CPAN for distribution. However, we may have email traffic for the project that exceeds the general interests of the modperl list. Thoughts? I would need to get enough responses from people who would join that Sourceforge mailing list before it would be worth it to go do that. Stephen There has been some discussion on the list lately about generating widgets ala CGI.pm, HTML::StickyWidgets etc... The thing is that these products or plug-ins are very HTML oriented. The widget is defined as an HTML widget like a textfield or checkbox or dropdown or what-have-you. What I am really looking for is a library that abstracts and allows widgets to be developed that are tied to an application not to a set of HTML necessarily. I guess I will start by providing an example of what I want based on what we currently do in our Java framework when he use Templating there. I'd like it if someone has developed the same thing in Perl that we could reuse, otherwise, we may need to write this. ... snip ...
RE: :Parser Expat cause segfaults
-Original Message- From: Oskari 'Okko' Ojala [mailto:[EMAIL PROTECTED]] Got a problem: About 250 of 1000 requests cause a segfault (11) when using XML::Parser::parse() under mod_perl. In FAQs it is stated that this is because of the bundled Expat in Apache. I've tried disabling Apache's Expat with --disable-rule=EXPAT, but it doesn't help. Have you found any workarounds or patches, or is the reason to my segfaults somewhere else? Platform: Red Hat 7.0 Apache 1.3.19 mod_perl 1.25 perl 5.6.0 expat 1.95.1 HTML::Mason 1.02 XML::Parser 2.30 There's (apparently) a known symbol conflict between XML::Parser 2.30 and Apache (which I only know because it happened to someone here just the other day). Drop down to 2.29 and it should work fine. Stephen.
Re: forbidden vs. cookie
Howdy Ken! I think there are two separate issues here -- there's an expiration time on the cookie, which is your app's instruction to the client as to how long the cookie should be kept. Then there's an expiration time of the ticket represented by that cookie data (to use the Ticket Auth example), which is the length of time the ticket is valid for. The ticket expiration time should be in a (tamper-proof) container encoded within the cookie, and checked by the server side app for freshness with each request. Allowing a client's broken idea of the current time (whether broken through maliciousness or through ignorance) to affect the duration of the ticket's validity is (IMO) a bad thing. If the client's broken idea of the time causes the cookie not to be stored for the correct duration, oh well, that's *their* problem, right? As Tom Christiansen likes to preach Never trust anything sent from the client. Steve On Tue, 1 May 2001, Ken Y. Clark wrote: On Mon, 30 Apr 2001, will trillich wrote: after seeing the 'expires' dilemma brought about by poorly configured client system clocks, what advice should we follow? (what's the Official Party Line on expiring cookies?) I'm not really sure how to answer your question. I have usually understood that the client handles all of this. That is, you tell the client that the cookie is good for 30 minutes, and it figures out when those 30 minutes have expired and then quits sending a valid cookie back to the server. Is that right? Anyone? Anyone? Bueller? -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Can anyone help please
Hi everyone, I have to make the tracking of users who follow links to external sites possible, preferably indicating in specific logfiles when a new browser is opened for linking to external sites. We have tried proxy solutions, modifying Apache core modules and are considering scanning and parsing our Html on the fly. I understand that uri.c could be modified or changes could be made to the .htaccess file. The problem is it has to be fast and transparant, does anyone have any ideas??? Thanks in advance Steve Smith
Re: Help with Apache::SubProcess needed.
Thanks very much. That did the trick. Steve On 13 Feb 2001, at 17:04, Stas Bekman wrote: On Mon, 12 Feb 2001, Stephen Gailey wrote: Help with Apache::SubProcess needed. I have tried the example for running a long duration task from Mod Perl, as found in the performance tuning guide, but I get the following error: [error] Can't locate object method "cleanup_for_exec" via package "Apache" at /usr/local/apachessl/handlers/wrapper_handler line 22 I am using the script right off the page and I have downloaded (from CPAN) and installed SubProcess. any ideas? I've released a new version of the guide, but Doug didn't have a chance to release a new version of this module with a new function yet. Just apply this patch and recompile: -- SubProcess.xs.orig Sat Sep 25 19:17:12 1999 +++ SubProcess.xs Tue Dec 19 21:03:22 2000 @@ -103,6 +103,14 @@ XPUSHs(io_hook(ioep, io_hook_read)); } + +void +ap_cleanup_for_exec(r) +Apache r + +CODE: +ap_cleanup_for_exec(); + int ap_call_exec(r, pgm=r-filename) Apache r _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Help with Apache::SubProcess needed.
Help with Apache::SubProcess needed. I have tried the example for running a long duration task from Mod Perl, as found in the performance tuning guide, but I get the following error: [error] Can't locate object method "cleanup_for_exec" via package "Apache" at /usr/local/apachessl/handlers/wrapper_handler line 22 I am using the script right off the page and I have downloaded (from CPAN) and installed SubProcess. any ideas? Thanks in advance. Steve
RE: Fwd: [speedycgi] Speedycgi scales better than mod_perl withsc ripts that contain un-shared memory
This doesn't affect the argument, because the core of it is that: a) the CPU will not completely process a single task all at once; instead, it will divide its time _between_ the tasks b) tasks do not arrive at regular intervals c) tasks take varying amounts of time to complete [snip] I won't agree with (a) unless you qualify it further - what do you claim is the method or policy for (a)? I think this has been answered ... basically, resource conflicts (including I/O), interrupts, long running tasks, higher priority tasks, and, of course, the process yielding, can all cause the CPU to switch processes (which of these qualify depends very much on the OS in question). This is why, despite the efficiency of single-task running, you can usefully run more than one process on a UNIX system. Otherwise, if you ran a single Apache process and had no traffic, you couldn't run a shell at the same time - Apache would consume practically all your CPU in its select() loop 8-) Apache httpd's are scheduled on an LRU basis. This was discussed early in this thread. Apache uses a file-lock for its mutex around the accept call, and file-locking is implemented in the kernel using a round-robin (fair) selection in order to prevent starvation. This results in incoming requests being assigned to httpd's in an LRU fashion. I'll apologise, and say, yes, of course you're right, but I do have a query: There are at (IIRC) 5 methods that Apache uses to serialize requests: fcntl(), flock(), Sys V semaphores, uslock (IRIX only) and Pthreads (reliably only on Solaris). Do they _all_ result in LRU? Remember that the httpd's in the speedycgi case will have very little un-shared memory, because they don't have perl interpreters in them. So the processes are fairly indistinguishable, and the LRU isn't as big a penalty in that case. Ye_but_, interpreter for interpreter, won't the equivalent speedycgi have roughly as much unshared memory as the mod_perl? I've had a lot of (dumb) discussions with people who complain about the size of Apache+mod_perl without realising that the interpreter code's all shared, and with pre-loading a lot of the perl code can be too. While I _can_ see speedycgi having an advantage (because it's got a much better overview of what's happening, and can intelligently manage the situation), I don't think it's as large as you're suggesting. I think this needs to be intensively benchmarked to answer that other interpreters, and you expand the number of interpreters in use. But still, you'll wind up using the smallest number of interpreters required for the given load and timeslice. As soon as those 1st and 2nd perl interpreters finish their run, they go back at the beginning of the queue, and the 7th/ 8th or later requests can then use them, etc. Now you have a pool of maybe four interpreters, all being used on an MRU basis. But it won't expand beyond that set unless your load goes up or your program's CPU time requirements increase beyond another timeslice. MRU will ensure that whatever the number of interpreters in use, it is the lowest possible, given the load, the CPU-time required by the program and the size of the timeslice. Yep...no arguments here. SpeedyCGI should result in fewer interpreters. I will say that there are a lot of convincing reasons to follow the SpeedyCGI model rather than the mod_perl model, but I've generally thought that the increase in that kind of performance that can be obtained as sufficiently minimal as to not warrant the extra layer... thoughts, anyone? Stephen.
RE: Newbie cookie question
On Fri, 5 Jan 2001, James Hall wrote:
[snip]
$user=$query-param('login');
$password=$query-param('pass');
Okay, there's your problem. You may want to try it this way:
use CGI::Cookie;
...
my %cookies = CGI::Cookie-parse($r-header_in('Cookie')):
my $user = $cookies{'login'};
my $password = $cookies{'pass'};
For more info on how to work with cookies in mod_perl, check the eagle
book. Also note that if you're going to do a redirect and set cookies at
the same time, you have to put the cookies into $r-err_header, since
$r-header doesn't get sent for "error" conditions like redirects.
HTH,
Steve
Re: Document Contains no data
--- Stas Bekman wrote: On 17 Nov 2000, Stephen A. Cochran wrote: I have a program which runs fine 90% of the time under mod_perl. About 10% of the time Netscape reports "Document contains no data". Looking at the socket traffic, the client receives an orderly release indication (T_ORDEL_IND = 132) on the socket and reponds with a orderly release request, which closes the socket. run it in single mode and attach to the process with strace(1) or truss(1) (depending on what you have). See the debug chapter in the mod_perl guide. --- end of quote --- Thanks for the suggestions from the list for this problem. The strace/truss probably would have helped solve the problem, too bad Digital Unix doesn't have either : ( After two months I finally tracked it down. Turns out that in an infrequently called sub to handle minor error conditions, there was a line "close STDERR". The comment from the author said it was to "kill any ugly errors that havne't made it out yet ...". Not really sure what he really wanted to do originally, but that was the problem. Anytime a process which had executed this code under mod_perl received another mod_perl request, the browser displayed the "Document contains no data" error due to the sequence of requests as described above in my original post. I just confirmed this with a short script which only does "close STDERR". Thought I'd post this in case someone else ever runs into this, or it's a bug. Not sure of closing STDERR is a common practice in CGIs, but maybe a gotcha for the porting guide. Steve Cochran
Re: RFC: mod_perl advocacy project resurrection
I've been following along with this thread with interest, expecially since I'm new to the mod_perl list and community (thanks for all the help so far!). I thought you might be interesed in a 'mod_perl newbie' opinion. Recently I was handed an online event calendar running under CGI and asked to get it to run under mod_perl to speed it up. I'm comfortable with perl, but by no means a guru. And this was the first time using mod_perl. In the past I've used several products which might be considered competitors to mod_perl: Web Objects and Cold Fusion. CF was horrible, I'm glad I didn't have to work with it for long. WO was very nice to work with, and it had all the ecommerce and transation logic needed to build a enterprise web application quickly. (None of my work has been in ecommerce, instead in the medical industry (patient data, lab results, etc) which has many of the same requirements). Installing: I've installed mod_perl twice in the last month. The first time was on Solaris and was quite painless. The second time was on RH 7.0, and was fairly painful. Took most of a day of futzing around to finally get it installed and working. I ran into two problems, first the unrecognized version of apache 1.3.14, and second when I had downgraded to 1.3.12 the new auto-configure part of apache was bypassing the standard Configuration file which mod_perl had inserted itself into, so Apache was building itself without mod_perl. As several others have said here, there is work which could be done in this area. My suggestions would be: - easier install in general (big red button approach is always nice) - make it easier (clear instructions too) on how to configure apache with mod_perl and other modules. The current 'big red button' only works if you have no other modules or already have them configured. - Instructions written for someone who knows nothing about mod_perl, and possible very little about unix. This is a general problem for all open source projects. With today's IT shortage, more and more sys admins are just power users who were promoted or sucked into duties because someone else left. If you want to catch their eye, make sure you talk at their level. I realize this can be a pain in you know where, and it's something that as you look to advocate you need to think about. "Do we want to target everyone, or should there be a minimum level or aptitude before we recommend someone installs this?" Anyone can walk into Staples these days and install Linux. If they have a decent distribution installing everything is easy. But even without a package manager like RH, apache is usually very painless to install. I know a number of non-profits who just have competent users maintaining a Linux server with apache, because for the most part it's trouble free. At worst they might have to restart the server. Technical Issues: The second problem I see with mod_perl is a technical one. Because of the design of mod_perl, debugging problems can be fairly involved. Is the problem my code? Or is it apache, or maybe mod_perl? Could even be perl for that matter. Take for example the problem I ran into recently. (Please don't take this as a rant just because I had problems, I'm happy with mod_perl. But I'm fairly capable around unix and compiling, instead imagine this happening to someone who wasn't that comfortable.) The event calendar works great under CGI, so I try it under mod_perl. It was written to work under mod_perl by a better perl programmer that I'll ever be (Jon Howell of Faq-o-matic fame) and is very well designed. It even worked under mod_perl with some minor changes like supplying the user/pass to the database since it wasn't running under cgiwrap any longer. And it worked! But only 90% of the time. The other 10% of the time, the client received no data, and the page generated by the script ended up in the apache log. After cleaning up one implicit database handle destruction warning the problem persisted, and I began to attempt to discover where the connection was being closed. So I did what any lazy programmer does, I added some print statements to send a note to STDERR. While these all showed up when the program worked correctly, when problem occured, the prints to STDERR dissapeared. But the html page was printed to the apache log, basicly standard error. So it looks like if the socket is closed, stderr dissapears, and stdout goes to the error log. So no pointers appeared in the log, which wasn't very helpful. Next attempt was to do some packet sniffing to see why the socket was closeing. Turns out that the web server sends an orderly release indication (T_ORDEL_IND = 132), so the client being a good citizen reponds with a orderly release request and there goes the socket. While my description of the problem was more in-depth that I meant it to be, my point is that now I'm left with the need to trace through system calls made by apache, mod_perl and my program to try and find
Re: setting a variable based on the server.
The solution i'm working on is something like this:
in the httpd.conf add
in the linux box
PerlSetVar NETP 0
in the solaris box
PerlSetVar NETP 1
then change the code to
if ($NETP)
{
return $netp-run();
}else{
return 0;
}
I've seen some problems with the PerlSetVar directive at my site, but
otherwise I do something quite similar. I wound up defining the
variables I need in apachectl (SYBASE=/opt/sybase; export SYBASE; etc.).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[OFF] strace
I'm trying to debug an intermittant problem on a Dec Unix server, and have gotten to the point where I need to use strace. On Dec Unix, strace wants a module ID, not a process ID. Anyone here familiar with Dec Unix? Steve Cochran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache::ASP (QueryString eats +)
On 21 Nov, sergen wrote: When sending text with "+" by "?" on url $Request-QueryString eats "+" (the text is absolutely the same but only this sign). Is it a bug or may be some else ? using: Mandrake 7.2 Apache 1.3.14-2mdk apache-mod_perl 1.3.14_1.24-2mdk Apache-ASP 2.002mdk httpd-perl (proxied) If someone know what to do pls send a sign, thnks Note that URL encoding treats the symbol '+' as the URL encoded version of the symbol ' ' (space, ASCII 32). The sequence of characters you need to include in a query string in order to have your script interpret it as the symbol '+' is '%43'. Your problem report isn't exactly clear on what you mean by "eats", but this may be your trouble. HTH Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Document Contains no data
I have a program which runs fine 90% of the time under mod_perl. About 10% of the time Netscape reports "Document contains no data". Looking at the socket traffic, the client receives an orderly release indication (T_ORDEL_IND = 132) on the socket and reponds with a orderly release request, which closes the socket. I've added some printing calls to determine how far it's getting in the script, even one on the first line. When it fails there are no warnings, none of the STDERR output shows up in the error log, and the html is still generated and output to the error_log. It seems like once the socket it closed, the script continues, but output to STDERR dissapears and STDOUT goes to the error log. Any ideas why the server is sending the orderly release indication or any ways to trace it? I've run the server in single process mode, but it still doesn't give any errors or warnings. I've tried on two different machines, both DECs, one running Perl 5.00404, Apache/1.3.12, mod_perl/1.24, the other running perl 5.00404, Apache/1.3.6, mod_perl/1.20. Steve Cochran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Page contains no data error
I'm moving someone else's CGIs to run under mod_perl, and about 95% of the time they work. The other 5% of the time Netscape gets a "Document contains no data." error and the web page that should have been sent to the brower is written into the apache error log. No other error is given in the error log. This is running on Apache 1.3.12, perl 5.004_04, and mod_perl 1.24. I'm beginning to suspect that mod_perl and perl arn't playing well together, since mod_perl and apache were just upgraded. After a server process gives the error, all mod_perl requests (such as perl-status) that hit that process will get the same error. Any ideas what it might be or a better way to track it down? Steve Cochran
@INC and use
I've been porting a CGI to mod_perl, and had it working. Then last night mod_perl and apache were upgraded and recompiled and it stopped working. The script parses the URL for a command name (ex: ?cmd=search) and then hands off the job to a different module (ex: search.pm). The path for this module is loaded as a library with the use command at the beginning of the module which dispatches all the different commands (use lib '/data/public/myapp/dev/lib';). The dispatcher parses the module name at during execution, not at compile time. From the mod_perl guide: (http://perl.apache.org/guide/porting.html#Reloading_Modules_and_Required_F), it looks as if the use statment is only effective during compile time, and the @INC is reset to normal, which wouldn't include this path. Am I understanding this correctly? And if I am understanding this correctly, I'm curious why it was working in the first place. Steve Cochran Dartmouth College
RE: Wild Proposal :)
-Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: 11 October 2000 04:45 To: Ajit Deshpande Cc: [EMAIL PROTECTED] Subject: Re: Wild Proposal :) Hi Ajit, It's not entirely clear to me what problem you're trying to solve here. I'll comment on some of the specifics you've written down here, but I may be missing your larger point. Ajit's examples aren't perfect, but the problem is a real one. The problem is one of generalisation. Logically, you don't want to put an application that is 10% web-related into mod_perl. So, you can take it out the other 90% and stick it into an RPC server, but wouldn't it be nice if there was an application server framework that handled connections,load balancing and resource management for you? There's DBI::Proxy already. Before jumping on the "we need pooled connections" bandwagon, you should read Jeffrey Baker's post on the subject here: http://forum.swarthmore.edu/epigone/modperl/breetalwox/38B4DB3F.612476CE@acm .org People always manage to miss the point on this one. It's not about saving the cycles required to open the connection, as they're minimal at worst. It's about saving the _time_ to open the connection. On a network application, opening a connection is going to be quite possibly your largest latency. On a large application doing a lot of transactions per second, the overhead involved in building connections and tearing them down can lose you serious time. It also complicates scaling the database server. It's far better to pay your overhead once and just re-use the connection. Stephen.
Finding Consultants on adding Perl Modules
Hi: Do you have a list of consultants who have experience in adding Perl Modules to Apache? We have a business need for some modules, such as Storable, and would be willing to contract for them. Is there some mechanism in general for finding Apache consultants? There are other areas we could use some help in, but as you know, many people put Apache on their resume if they have even read your web site! I'd appreciate any help you could give on this. Byron Byron Stephen Lee Server Development Manager Telleo 4 North Second Street Suite 300 San Jose, CA 95113 phone (408) 792-5742 fax (408) 792-5795 email: [EMAIL PROTECTED]
mod_perl-1.24 - Make FAILS!
Last few lines of make ... MOD_PERL mod_auth.c cc -c -I../../os/unix -I../../include -DLINUX=2 -DMOD_PERL -DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED -D MOD_PERL mod_setenvif.c rm -f libstandard.a ar cr libstandard.a mod_env.o mod_log_config.o mod_mime.o mod_negotiation.o mod_status.o mod_include.o mod_autoindex.o mod_dir.o mod_cgi.o mod_asis.o mod_imap.o mod_actions.o mod_userdir.o mod_alias.o mod_access.o mod_auth.o mod_setenvif.o ranlib libstandard.a === modules/standard === modules/perl cc -O2 -Dbool=char -DHAS_BOOL -I/usr/local/include -I/usr/lib/perl5/5.00503/i386-linux/CORE -DMOD_PERL_VERSION=\"1.24\" -DMOD_PE RL_STRING_VERSION=\"mod_perl/1.24\" -DNO_PERL_METHOD_HANDLERS=1 -DNO_PERL_DIRECTIVE_HANDLERS=1 -DNO_PERL_SECTIONS=1 -DNO_PERL_SS I=1 -I../../os/unix -I../../include -DLINUX=2 -DMOD_PERL -DUSE_HSREGEX -DUSE_EXPAT -I../../lib/expat-lite -DNO_DL_NEEDED -DMO D_PERL -c mod_perl.c In file included from mod_perl.h:92, from mod_perl.c:67: /usr/lib/perl5/5.00503/i386-linux/CORE/perl.h:2546: redefinition of `union semun' make[3]: *** [mod_perl.o] Error 1 make[2]: *** [all] Error 1 make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/src/httpd_perl/apache_1.3.12/src' make: *** [apache_httpd] Error 2 Perl version 5.005_03 built for i386-linux (2.0.36) Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.1-ac1, archname=i386-linux uname='linux porky.devel.redhat.com 2.2.1-ac1 #1 smp mon feb 1 17:44:44 est 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 -lndbm -lgdbm -ldb -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 Apr 6 1999 23:34:07 @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 Any ideas? -- Stephen Marriott - [EMAIL PROTECTED] HiSOFT, The Old School, Greenfield, Bedford, MK45 5DE, UK Tel: +44 1525 718181 Fax: +44 1525 713716 Freecall: 0500 223 660 http://www.hisoft.co.uk/ PGP public key on request.ICQ#:29793027 http://aist.co.uk/ http://cinema4d.co.uk/ http://speedyshop.com/ AFFILIATES NETWORK - http://www.hisoft.co.uk/cgi-bin/gp?pg=an.main
mod_ssl and deprecated SSLDisable
I built mod_ssl without any backward compatibility enabled, and that caused the mod_perl ``make test'' to fail, since SSLDisable is no longer recognized in this configuration. Simply removing the ``SSLDisable'' from the IfModule mod_ssl.c stanza in t/conf/httpd.conf line is sufficient for the tests to succeed, most likely since, in conjunction with the change in syntax, mod_ssl now defaults to disabled, and requires an explicit ``SSLEngine on'' directive before it starts making further demands of the httpd.conf file. My apologies if this is a well known issue. - Stephen P. Schaefer -- Find my public key at http://pgp5.ai.mit.edu Key fingerprint = E1 B6 97 1B 96 9F A1 D1 77 09 AA 90 4B 0F 91 CC PGP signature
Re: [performance/benchmark] printing techniques
"Stas" == Stas Bekman [EMAIL PROTECTED] writes: Stas Ouch :( Someone to explain this phenomena? and it's just Stas fine under the handler puzzled, what can I say... Continuous array growth and copying? -- Stephen "So if she weighs the same as a duck, she's made of wood."... "And therefore?"... "A witch!"
Re: Data structure question
"Drew" == Drew Taylor [EMAIL PROTECTED] writes:
Drew I would like to return a single data structure, but order IS
Drew important (hence the current setup). I was thinking of using
Drew an array, where each element is a hash reference. So I would
Drew return something like this:
In this case pseudohashes are absolutely what you're looking for.
They'll also have the smallest impact on your code as you can walk
@{$ref}[1..foo] when you need the items in order and grab $ref-{key}
when you need a particular value. Just remember that $ref-[0] is
special.
--
Stephen
"Farcical aquatic ceremonies are no basis for a system of government!"
Re: [performance/benchmark] printing techniques
"Stas" == Stas Bekman [EMAIL PROTECTED] writes:
Stas Is this a question or a suggestion? but in both cases
Stas (mod_perl and perl benchmark) the process doesn't exit, so
Stas the allocated datastructure is reused... anyway it should be
Stas the same. But it's not.
It was a suggestion. Examining the optrees produced by aggrlist_print
and the following two routines which should be equivalent to
concat_print and multi_print from your original posting
sub concat_print{
my $buffer;
$buffer .= "!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML//EN\"\n";
$buffer .= "HTML\n";
$buffer .= " HEAD\n";
$buffer .= "/HTML\n";
print $buffer;
}
sub aggrlist_print{
my @buffer = ();
push @buffer,"!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML//EN\"\n";
push @buffer,"HTML\n";
push @buffer," HEAD\n";
push @buffer,"/HTML\n";
print @buffer;
}
sub multi_print{
print "!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML//EN\"\n";
print "HTML\n";
print " HEAD\n";
print "/HTML\n";
}
shows that aggrlist_print performs 25% OPs than concat_list and 43%
more OPs than multi_print.
Stas handler:
Stas concat_print|111 5000 0876
Stas aggrlist_print |113 5000 0862
Stas multi_print |118 5000 0820
Stas buffered benchmark:
Stas concat_print:8 wallclock secs ( 8.23 usr + 0.05 sys = 8.28 CPU)
Stas multi_print:10 wallclock secs (10.70 usr + 0.01 sys = 10.71 CPU)
Stas aggrlist_print: 30 wallclock secs (31.06 usr + 0.04 sys = 31.10 CPU)
Stas Watch the aggrlist_print gives such a bad perl benchmark,
Stas but very good handler benchmark...
As Matt has already commented, in the handler the method call
overheads swamps all the other activities. so concat_print
aggrlist_print (yes, method invocation in perl really is that bad).
When you remove that overhead the extra OPs in aggrlist_print become
the dominating factor.
--
Stephen
"So if she weighs the same as a duck, she's made of wood."... "And
therefore?"... "A witch!"
Re: speed up/load balancing of session-based sites
"Perrin" == Perrin Harkins [EMAIL PROTECTED] writes: Perrin I think every RDBMS I've seen, includig MySQL, guarantees Perrin atomicity at this level. Look, Mummy, the funny man said MySQL and RDBMS in the same sentence :) -- Stephen "There are those who call me... Tim"
[OT] Re: growing processes
"Wim" == Wim Kerkhoff [EMAIL PROTECTED] writes: Wim We're using SqlNet to connect multiple Linux web servers to Wim Oracle running on a Solaris box. Adjust 'processes' and 'sessions' upwards in your initSID.ora file on your database server. Use: svrmgrl connect inernal show paramete something to see what's currently being used. -- Stephen "And what do we burn apart from witches?"... "More witches!"
Re: mod_perl suddenly demanding DSO.
"Stas" == Stas Bekman [EMAIL PROTECTED] writes: Stas This is not a fatal error. It was fixed in the current CVS Stas version. Get it from http://perl.apache.org/from-cvs/modperl Thanks, Stas. Bleeding edge here I come :) -- Stephen "So if she weighs the same as a duck, she's made of wood."... "And therefore?"... "A witch!"
Re: mod_perl (DSO) dumping core with perl 5.6.0
"Doug" == Doug MacEachern [EMAIL PROTECTED] writes: Doug won't performance suffer in that case? i "benchmarked" Perl Doug malloc vs. system malloc under solaris once, there were far Doug more syscalls to brk() with system malloc. Ilya has claimed for about 18 mths now that usemymalloc=y is the Right Thing to do on Solaris and that previous assertions that Solaris' malloc is better are no longer true. He claims that perl's malloc is tuned to perl's memory usage patterns resultinging in the lower overhead and supposedly greater speed. That said, I still don't run that way. :) -- Stephen "And what do we burn apart from witches?"... "More witches!"
RE: Why does Apache do this braindamaged dlclose/dlopen stuff?
So in the longer term, is there a reason the parent has to contain the interpreter at all? Can't it just do a system call when it needs one? It seems a bit excessive to put aside a couple of megabytes of system memory just to run startup.pl. Well, remember that the interpreter itself will remain shared throughout, so there's no real disadvantage in having in the parent. The main reason to run startup.pl in the parent is to overcome as much of Perl's startup time as possible. Compiling the code domainates the startup time, so the thing to do is to pull in your modules in startup.pl . That way, it's only done once, and the results are shared between all children. I think the thing to do here is fix the memory leaks 8-) Stephen.
RE: Why does Apache do this braindamaged dlclose/dlopen stuff?
-Original Message- From: Gerald Richter [mailto:[EMAIL PROTECTED]] Sent: 19 January 2000 04:36 To: Alan Burlison; [EMAIL PROTECTED] Subject: RE: Why does Apache do this braindamaged dlclose/dlopen stuff? So I would agree to your last sentences that Dynloader is responsible for unloading, because that's the only module, which knows what it had loaded. Agreed. It's a relatively small change to DynaLoader, with great benefits for embedded Perl. Also I am not so sure if unloading all the libraries can be really successfully done, because the Perl XS libraries don't assume that they will ever unloaded (because they are actualy only unloaded when the program exits). This may be the reason for memory leaks Daniel metioned earlier, because the XS libraries don't have a chance to free there resources (or not aware of that they actually should do so). Yes and no. If XS libraries are written with OO-style wrappers (which, IMHO, they always should be), then surely you can catch the unloading in a DESTROY sub and use that to do the deallocation of resources? Perl can only manage Perl resources, and extension resources should be the responsibility of the the programmer. Stephen.
Re: modperl success story
Barb and Tim wrote: full honesty. The language itself is hard enough to swallow. How is Perl hard to swallow? Perl is so easy and flexible. Stephen
Re: Apache Proxy Virtual Servers...
"Trevor" == Trevor Phillips [EMAIL PROTECTED] writes: Trevor This works fine, except "the.other.machine" gets the Host Trevor header as "the.other.machine" and NOT whatever is passed Trevor to the proxy by the client. As a result, virtual servers Trevor with the same IP but different name are NOT working! Do you actually need virtual hosts in the mod_perl server or would URI namespace spereation accomplish what you want? For instance: VirtualHost host1:80 ProxyPass/ http://the.other.machine:80/host1/ ProxyPassReverse / http://the.other.machine:80/host1/ /VirtualHost VirtualHost host2:80 ProxyPass/ http://the.other.machine:80/host2/ ProxyPassReverse / http://the.other.machine:80/host2/ /VirtualHost -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away"
RE: Another IE5 complaint
-Original Message- From: Rod Butcher [mailto:[EMAIL PROTECTED]] Sent: 23 November 1999 10:20 Cc: [EMAIL PROTECTED] Subject: Re: Another IE5 complaint Am I the only battling service vendor who actually feels good when somebody bookmarks my website ? I can absorb the overhead of accesses to a favorites icon. This may be a security hazard for the client, but I detect a holier-than-thou attitude here against M$. Will somebody tell me why this M$ initiative is bad, other than for pre-determined prejudices ? Rgds Rod Butcher Speaking as someone who works for an ISP, anything that obscures (by volume) genuine errors is a Bad Thing. The error log is a useful diagnostic tool only if you can see the errors. Yes, you could filter out the requests before examining the file, but the point is MS is making more work for people by being thoughtless. Further reasons it's a bad idea * It's not standard * It's a specific solution to a general problem, and therefore fragile (i.e. it breaks too easily) * It's a quick hack rather than a genuine initiative (which would take effort) Stephen. -- disclaimer type="std" The views expressed are personal and do not necessarily reflect those of Planet Online Limited. /disclaimer
Re: MD5 risks?
"Trevor" == Trevor Phillips [EMAIL PROTECTED] writes: Trevor Another alternative is to get the MD5 base64 key to the Trevor URI. My query is, what is the chance of two URI's giving Trevor the same MD5? Is there any risk in it, or is MD5 guranteed Trevor to give unique ID's? (I know the risk would be SLIM, but Trevor how slim?) Is MD5 used regularly for this kind of thing? What you're asking about is the likelihood of a 'birthday attack' on a given hash. Quoting Bruce Schneier's 'Applied Cryptography', 2nd ed. p166: Finding two [m-bit] message that hash to the same value would only require 2**(m/2) messages This means that if you're worried about a birthday attack, you should use a hash value twice as long as you otherwise might think you need. For example, if you want to drop the odds of someone breaking into your system to less than 1 in 2**80, use a 160-bit one-way hash function. So, with MD5 you have a 1 in 2**64 chance of getting a collision between two URLs. Adding the lenght of the URL doesn't make any practical difference as that's already done as part of the hashing algorithm. BTW, if you plan dealing with any cryptographic-related functions, Schneier's book is a must: ISBN 0-471-12845-7 -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away"
Re: New mod_perl RPM really needed? (was: sourcegarden plug)
Stas Bekman [EMAIL PROTECTED] writes: I think it would help. If you succeed to build a good SRPM for a general purpose usage, we ether can ask RH to put it in, or can put it on sourcegarden or perl.apache.org - it's not an issue. Thanks! I found one, actually. On my RH6.0 box at home, I installed an apache+mod_perl SRPM that seemed to work fine. Mod_perl was statically linked in, so I don't have the chaining difficulties. Unfortunately, I had to compile from the SRPM version, since the RPM was compiled for RH5.2, and was therefore looking under the wrong Perl version number for Perl modules. If you look on any RedHat mirror which has the contrib directory, you should be able to find an apache_mod-perl RPM and SRPM. -- Stephen L. Peters [EMAIL PROTECTED] PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "Poodle: The other white meat." -- Sherman, Sherman's Lagoon
