Re: message type 0x49 arrived from server while idle
The solution David and others found is not applicable to my problem because I'm already running apache 1.3.27 (not 1.3.28 which seems to be causing this trouble) I'm not sure I understand what you're saying here. At the beginning of your message it looked like you were using 1.3.27, not 1.3.28. Are you saying that the problem is present with a 1.3.27 Apache but not with 1.3.28? If so then could you not simply stay with 1.3.27? Ged, thanks for your answer. I am currently using 1.3.27 (haven't tried 1.3.28) - David's problem went away after reverting from 1.3.28 to 1.3.27 but my problem persists even with 1.3.27 ... cheers, tobias --- http://www.funkreich.de // may the funk be with you
RE: [mp2][QUESTION]: Filter to modify request headers on a proxy server
Hi, I've just tried that script again (see link below) using a POST request. In the error log file, there is the content of the POST Request e.g. user=cpringlepassword=x but nothing else. There is no HTTP headers. My Apache directive to enable the filter is PerlInputFilterHandler iPAQApache::ResetBrowser Is this the correct directive? _/*** * _/ **Chris Pringle** _/ *Industrial Trainee ** *** _/_/_/ _/_/_/ *Personal Systems Group (PSG) ** ***_/ _/ _/ _/*Hewlett Packard - Bristol** *** _/ _/ _/_/_/ * ** _/ INVENT **Tel - +44 (0) 117 31 29664 ** ** _/Email - [EMAIL PROTECTED] ** *** _/ * -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 September 2003 11:37 To: Pringle, Chris (HP-PSG) Cc: [EMAIL PROTECTED] Subject: Re: [mp2][QUESTION]: Filter to modify request headers on a proxy server Pringle, Chris (HP-PSG) wrote: Hi, I am trying to write a filter that will sit on a proxy server and alter HTTP requests. Basically, what I want it to do is modify the User-Agent header field so that when the request is proxied, the remote web server gets a different User-Agent header field to the one that was originally sent by the browser. There are also other header fields I may need to modify, but I would imagine this is a simple task once I've worked out how to alter the User-Agent field. Does anyone have any ideas how I might go about doing this? I've tried writing several PerlInputFilterHandlers, all with no success. Will input filters work with a proxy? I've got output filters working with no problem. Any sample code to do what I want, along with the relavent Apache directives would be very much appreciated! The sample code that you need is here: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_In put_Filters I haven't tried to mix filters with proxy, but I see no reason why shouldn't it work. It might not work if proxy is implemented as a filter itself and is running before the modperl filters, need to look at the actual implementation. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2][QUESTION]: Filter to modify request headers on a proxy server
Pringle, Chris (HP-PSG) wrote:
Hi,
I've just tried that script again (see link below) using a POST request.
In the error log file, there is the content of the POST Request e.g.
user=cpringlepassword=x but nothing else. There is no HTTP headers.
My Apache directive to enable the filter is
PerlInputFilterHandler iPAQApache::ResetBrowser
Is this the correct directive?
The directive is correct, but you don't show your code and your config, so I
have no idea if the rest is correct or not. This directive is used to
configure both, connection and request level filters. It's the attribute of
the handler subroutine is what makes the difference and the placement in
httpd.conf.
You need to declare it as:
package iPAQApache::ResetBrowser;
use base qw(Apache::Filter);
sub handler : FilterConnectionHandler { your code is here }
1;
and you need to put it outside of Location or similar block in httpd.conf
just like shown at:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters
Also make sure that you run at least mod_perl 1.99_09, or even better the
current cvs. And in the future please follow the info at
http://perl.apache.org/bugs/ so we know more about your setup.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: [mp2][QUESTION]: Filter to modify request headers on a proxy server
Thanks for this. I had put 'PerlInputFilterHandler
iPAQApache::ResetBrowser' inside the proxy block, and it should have
been outside like you said.
_/***
* _/ **Chris Pringle**
_/ *Industrial Trainee **
*** _/_/_/ _/_/_/ *Personal Systems Group (PSG) **
***_/ _/ _/ _/*Hewlett Packard - Bristol**
*** _/ _/ _/_/_/ * **
_/ INVENT **Tel - +44 (0) 117 31 29664 **
** _/Email - [EMAIL PROTECTED] **
*** _/ *
PerlInputFilterHandler iPAQApache::ResetBrowser
Is this the correct directive?
The directive is correct, but you don't show your code and your config,
so I
have no idea if the rest is correct or not. This directive is used to
configure both, connection and request level filters. It's the attribute
of
the handler subroutine is what makes the difference and the placement in
httpd.conf.
You need to declare it as:
package iPAQApache::ResetBrowser;
use base qw(Apache::Filter);
sub handler : FilterConnectionHandler { your code is here }
1;
and you need to put it outside of Location or similar block in
httpd.conf
just like shown at:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_In
put_Filters
Also make sure that you run at least mod_perl 1.99_09, or even better
the
current cvs. And in the future please follow the info at
http://perl.apache.org/bugs/ so we know more about your setup.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2][QUESTION]: Filter to modify request headers on a proxy server
Pringle, Chris (HP-PSG) wrote:
Thanks for this. I had put 'PerlInputFilterHandler
iPAQApache::ResetBrowser' inside the proxy block, and it should have
been outside like you said.
So it did work this time, right? Perhaps we should issue a warning if a
connection filter is found insider Location or alike.
PerlInputFilterHandler iPAQApache::ResetBrowser
Is this the correct directive?
The directive is correct, but you don't show your code and your config,
so I
have no idea if the rest is correct or not. This directive is used to
configure both, connection and request level filters. It's the attribute
of
the handler subroutine is what makes the difference and the placement in
httpd.conf.
You need to declare it as:
package iPAQApache::ResetBrowser;
use base qw(Apache::Filter);
sub handler : FilterConnectionHandler { your code is here }
1;
and you need to put it outside of Location or similar block in
httpd.conf
just like shown at:
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_In
put_Filters
Also make sure that you run at least mod_perl 1.99_09, or even better
the
current cvs. And in the future please follow the info at
http://perl.apache.org/bugs/ so we know more about your setup.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Use of Apache::Directive in BEGIN block
Title: Re: Use of Apache::Directive in BEGIN block Thank you very much. I had looked at http://perl.apache.org/docs/2.0/user/help/help.html, but did not see the instructions about running t/REPORT I will certainly use t/REPORT in the future until mp2bug is part of the distro. Perhaps that instruction could be more, um, blatant? At 3:03 PM -0700 9/18/03, Stas Bekman wrote: Matisse, your bug report is incomplete, you have missed the report about your environment as explained at the guidelines (http://perl.apache.org/bugs/). In the future please include it, it's probably unimportant for this case. To address this issue upgrade to 1.99_09 or may be you even need the current cvs, I don't remember when Philippe has fixed that, check the Changes file. t/response/TestApache/conftree.pm does the testing of this feature and works just fine in the current cvs. -- -- Matisse Enzer Hamilton Partners 707-431-4300 ext. 212 (office) 415-225-6703 (mobile)
Re: Use of Apache::Directive in BEGIN block
Matisse Enzer wrote: Thank you very much. So does it work now? I had looked at http://perl.apache.org/docs/2.0/user/help/help.html, but did not see the instructions about running t/REPORT You mean, you missed it, since it's there: http://perl.apache.org/docs/2.0/user/help/help.html#Important_Information I will certainly use t/REPORT in the future until mp2bug is part of the distro. it's actually in the distro (outdated META tag), i just need to make it working before 'make install', as now it works only post 'make install'. Perhaps that instruction could be more, um, blatant? patches to improve things are always welcome. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[Fwd: Re: Perl 5.8.1 and mod_perl2 and FreeBSD]
FYI Original Message Date: Fri, 19 Sep 2003 10:44:13 +0800 From: Autrijus Tang [EMAIL PROTECTED] To: John Peacock [EMAIL PROTECTED] CC: Perl 5 Porters [EMAIL PROTECTED] ??, 2003-09-19 00:05, John Peacock What is the status of thread support on FreeBSD vis-a-vis Perl? There is some comment on the Installing mod_perl 2.0 web page that seems to suggest that the thread support by FreeBSD is unstable. Is that still true? Am I going to be sorry if I try this? My production servers runs with that exact setup (FreeBSD, maintperl, mod_perl2, svn, mason) without any problems. The trick is simple: do *not* use threads; build a non-threaded perl, and avoid using a threaded MPM. Thanks, /Autrijus/ signature.asc Description: PGP signature
Re: Use of Apache::Directive in BEGIN block
At 11:19 AM -0700 9/19/03, Stas Bekman wrote: Matisse Enzer wrote: Thank you very much. So does it work now? I wasn't able to get 1.99_09 to install. -8-- Start Bug Report 8-- 1. Problem Description: make install for 1.99_09 failed with: cp xs/modperl_xs_sv_convert.h xs/modperl_xs_typedefs.h xs/modperl_xs_util.h cp: copying multiple files, but last argument `xs/modperl_xs_util.h' is not a directory Try `cp --help' for more information. make: *** [modperl_xs_h_install] Error 1 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.0.45 Server built: May 6 2003 14:05:29 Server's Module Magic Number: 20020903:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -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=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt 2002 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' 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=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm' ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)', 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 -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.2.92' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Sep 1 2002 23:56:49 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Fri Sep 19 19:40:52 2003 GMT. -8-- End Bug Report --8-- -- -- Matisse Enzer Hamilton Partners 707-431-4300 ext. 212 (office) 415-225-6703 (mobile)
message type 0x49 arrived from server while idle
I have developed an application based on Apache 1.3.27, mod_perl 1.27, Postgres 7.3.2, Class::DBI 0.94 (utilizes Ima::DBI) on SuSE Linux 7.0 with a 2.4.20 kernel. I already posted my problem to the Class::DBI userlist but unfortunately didn't get any answers yet so I'm trying my luck here hoping that somebody can help. The problem described below is very similar to the one posted by David Wheeler (of bricolage fame) some time ago (Topic mod_perl + Apache 1.3.28, http://www.gossamer-threads.com/perl/mailarc/gforum.cgi?post=75733;search_string=0x49;guest=1213631t=search_engine#75733) Here we go: The problem is that everytime more than one request at a time is made to the server I find the following error message in my logs and from then on apache seems to be stalled and is unable to process any further requests: message type 0x49 arrived from server while idle Nobody seems to have seen this error message before (I grep'd through my perl lib dir and found nothing). It seems to have got something to do with many apache children accessing the postgres database (I'm using Apache::DBI but also tried without it) because the problems are completely gone when starting apache in single-process mode. I'm really stuck with this problem and have absolutely no clue where to look. I tried building some stripped-down scripts to reproduce the error in a smaller environment but strangely that always worked. I'd be very grateful if somebody here could share some ideas on this. The solution David and others found is not applicable to my problem because I'm already running apache 1.3.27 (not 1.3.28 which seems to be causing this trouble) Thank you very much in advance! -- Cheers, Tobias --- http://www.funkreich.de // may the funk be with you
Re: Use of Apache::Directive in BEGIN block
Matisse Enzer wrote:
At 11:19 AM -0700 9/19/03, Stas Bekman wrote:
Matisse Enzer wrote:
Thank you very much.
So does it work now?
I wasn't able to get 1.99_09 to install.
-8-- Start Bug Report 8--
1. Problem Description:
make install
for 1.99_09 failed with:
cp xs/modperl_xs_sv_convert.h xs/modperl_xs_typedefs.h xs/modperl_xs_util.h
cp: copying multiple files, but last argument `xs/modperl_xs_util.h' is
not a directory
Try `cp --help' for more information.
make: *** [modperl_xs_h_install] Error 1
[...]
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_COMPAT_1X = 1
MP_GENERATE_XS = 1
MP_LIBNAME = mod_perl
MP_USE_DSO = 1
MP_USE_STATIC = 1
Cool, MODPERL_AP_INCLUDEDIR in your top level Makefile is not set.
Can you please try with the cvs version first:
http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution
and if it still doesn't work, please try with this patch, which should go in
in any case:
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.124
diff -u -r1.124 Makefile.PL
--- Makefile.PL 26 Aug 2003 22:22:15 - 1.124
+++ Makefile.PL 19 Sep 2003 21:27:30 -
@@ -71,7 +71,7 @@
MODPERL_LIBMAKE= '$(MAKE) -f $(MODPERL_MAKEFILE)',
PERL = $build-perl_config('perlpath'),
MOD_INSTALL= ModPerl::BuildMM::mod_install(),
-MODPERL_AP_INCLUDEDIR = $build-apxs('-q' = 'INCLUDEDIR'),
+MODPERL_AP_INCLUDEDIR = $build-ap_includedir(),
MODPERL_XS_H_FILES = join( \\\n\t, @xs_h_files),
},
clean = {
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: message type 0x49 arrived from server while idle
Hi there, On Fri, 19 Sep 2003, Tobias Kremer wrote: I have developed an application based on Apache 1.3.27, mod_perl 1.27, Postgres 7.3.2, Class::DBI 0.94 (utilizes Ima::DBI) on SuSE Linux 7.0 with a 2.4.20 kernel. The problem is that everytime more than one request at a time is made to the server I find the following error message in my logs and from then on apache seems to be stalled and is unable to process any further requests: message type 0x49 arrived from server while idle Nobody seems to have seen this error message before (I grep'd through my perl lib dir and found nothing). I think it's from Postgres, not Perl. Try Googling for message type arrived from server while idle It seems to have got something to do with many apache children accessing the postgres database I'm sure that's right, I think you're confusing Postgres somehow. There are suspicions about threads in some of the messages that Google found with the query above. I've never used Postgres so I wouldn't know where to point you, but have you checked the Postgres docs for that message? There are a few references such as this http://developer.postgresql.org/docs/pgsql/src/interfaces/libpq/fe-protocol3.c fairly late on in the Google results. The solution David and others found is not applicable to my problem because I'm already running apache 1.3.27 (not 1.3.28 which seems to be causing this trouble) I'm not sure I understand what you're saying here. At the beginning of your message it looked like you were using 1.3.27, not 1.3.28. Are you saying that the problem is present with a 1.3.27 Apache but not with 1.3.28? If so then could you not simply stay with 1.3.27? 73, Ged.
[mp2][QUESTION]: Filter to modify request headers on a proxy server
Hi, I am trying to write a filter that will sit on a proxy server and alter HTTP requests. Basically, what I want it to do is modify the User-Agent header field so that when the request is proxied, the remote web server gets a different User-Agent header field to the one that was originally sent by the browser. There are also other header fields I may need to modify, but I would imagine this is a simple task once I've worked out how to alter the User-Agent field. Does anyone have any ideas how I might go about doing this? I've tried writing several PerlInputFilterHandlers, all with no success. Will input filters work with a proxy? I've got output filters working with no problem. Any sample code to do what I want, along with the relavent Apache directives would be very much appreciated! _/*** * _/ **Chris Pringle** _/ * ** *** _/_/_/ _/_/_/ *Personal Systems Group (PSG) ** ***_/ _/ _/ _/*Hewlett Packard - Bristol** *** _/ _/ _/_/_/ * ** _/ INVENT **Tel - +44 (0) 117 31 29664 ** ** _/Email - [EMAIL PROTECTED] ** *** _/ *
Re: [mp2][QUESTION]: Filter to modify request headers on a proxy server
Pringle, Chris (HP-PSG) wrote: Hi, I am trying to write a filter that will sit on a proxy server and alter HTTP requests. Basically, what I want it to do is modify the User-Agent header field so that when the request is proxied, the remote web server gets a different User-Agent header field to the one that was originally sent by the browser. There are also other header fields I may need to modify, but I would imagine this is a simple task once I've worked out how to alter the User-Agent field. Does anyone have any ideas how I might go about doing this? I've tried writing several PerlInputFilterHandlers, all with no success. Will input filters work with a proxy? I've got output filters working with no problem. Any sample code to do what I want, along with the relavent Apache directives would be very much appreciated! The sample code that you need is here: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters I haven't tried to mix filters with proxy, but I see no reason why shouldn't it work. It might not work if proxy is implemented as a filter itself and is running before the modperl filters, need to look at the actual implementation. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Use of Apache::Directive in BEGIN block
I get the following error:
Can't locate object method lookup via package Apache::Directive at
/webcontent/dev.mycardmaker.com/lib/perl/Doodlelab/Apache/Test.pm line 4.
when I try to start Apache.
Here is the entire contents of Test.pm
BEGIN {
use Apache::Directive;
my $tree = Apache::Directive-conftree();
foreach my $node ( $tree-lookup('PerlSetVar') ) {
# I want to do something here.
}
}
1;
--
--
Matisse Enzer
Hamilton Partners
707-431-4300 ext. 212 (office)
415-225-6703 (mobile)
Re: Use of Apache::Directive in BEGIN block
On Thu, 2003-09-18 at 13:52, Matisse Enzer wrote: I get the following error: Can't locate object method lookup via package Apache::Directive at /webcontent/dev.mycardmaker.com/lib/perl/Doodlelab/Apache/Test.pm line 4. when I try to start Apache. We need more information about your system. Please take a look at the bug reporting guidelines here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems - Perrin
RE: client-side certificate extraction
To the next guy, To answer my question with what I have: My requirement has been pushed out 6 months, so I'm done for now. The Gunther Birznieks/www.extropia.com project has modules to do some of the things I queried about. I looked at it but ran out of time before I found what I would need. I also found where various training issues are likely because certificates may have to be bought and the browser or web server might not necessarily handle problems gracefully/friendly and the issue of revocation does not have a widely used tool for processing certificate status updates. Chuck Modssl manual on client side certs (setup only - not programming): http://www.modssl.org/docs/2.8/ssl_faq.html Quote from Gunther Birznieks (from an old post): If you download our Perl objects @ http://www.extropia.com/development/webware2/webware2.html, I have an AuthManager::Certificate which implements client certificate authentication. Probably the best place to download the code for that is on the extropia perl project at sourceforge if you want to see the implementation. It's actually trivial because mod_ssl will decode the certificate into extra environment variables indicating stuff like the DN of the user. It's a requirement of SSL to make sure the certificate is valid based on the certificate's signature(s). At that point, then you need to deal with certificate revocation which is another matter. A lot of servers back up certificate authentication with LDAP. So the client sends the cert which verifies that they are who they say they are, but LDAP needs to be used to actually get the relevant authorization information out. If you use the framework we have, that is accomplished by configuring the use of AuthManager::Certificate against Auth::LDAP. Auth::Cache::Session can optionally be used to speed up the process. Chapter 20 on the link I gave you has details on why we broke up the modules the way we did. Note that this is not to be confused with a handler. This is application level logic. mod_ssl already handles certificate decoding so you really don't need a handler anymore. At that point it seems like app logic to take the user and figure out what you want them to do. Of course, you can code authorization info into a cert like the roles that they are intended for. But I think that's IMHO, a really BAD way to do it because you have to revoke the cert to change the permissions of the user. Best to leave the cert to identify the user and allow a dynamic datastore to determine what they can do in most cases. Later, Gunther PS The hard part about client certificates isn't using them, its managing them and the customers that use them. = References for Related subjects The book Microsoft® Windows® 2000 Active Directory(tm) Programming has several pages on programming with LDAP on Windows Active Directory. According to Gunther, LDAP is used in this process somehow. -Original Message- From: Goehring, Chuck Mr., RCI - San Diego Sent: Tuesday, September 16, 2003 10:26 AM To: [EMAIL PROTECTED] Apache. Org (E-mail) Subject: client-side certificate extraction ModPerlers, We have a requirement to change our web servers to require client-side ssl certificates by Oct 1, 2003. Can someone give me some pointers on how mod_perl might be used to extract the user's name at login time. I suspect this might require a handler. This might be used to avoid multiple logins. Thanks Chuck
MP2 Apache Settings
Hello Group, Hope this isn't too apache related and considered off topic. I have a bunch of sites, each have their own IP. Some of those sites have subsites within them with different domain names, these subsites are virtual's based on domainname with all the same parent IP. If I have MP2 modules and location names that I want to share to specific IPs or Specific Virtual Hosts is there was way to define it once or does it have to be within each virtual host. For example: VirtualHost 10.0.0.5 ServerName domain1.com PerlModule YADDA::LoginLocation "/login" SetHandler perl-script PerlHandler YADDA::Login/Location /VirtualHost VirtualHost 10.0.0.5 ServerName domain2.com /VirtualHost VirtualHost 10.0.0.6 ServerName domian3.com /VirtualHost In the case above I want the module YADDA::Login and the location to be available to BOTH the .05 virtual hosts, but not the .06 - so both /domain1.com/login and domian2.com/login do the same thing but domain3 would not. Is the choice either global to everything or defined within each virtual that I want it? I've been reading the server and dir create/merge section on perl.apache.org but I'm not even sure it relates. Thanks -Chris
Re: [OT] MP2 Apache Settings
Why not just make an include file that contains the module directives, and then just add an Include myloginconffile.conf to each virtualhost section? Issac - Original Message - From: Chris Faust To: [EMAIL PROTECTED] Sent: Thursday, September 18, 2003 10:04 PM Subject: MP2 Apache Settings Hello Group, Hope this isn't too apache related and considered off topic. I have a bunch of sites, each have their own IP. Some of those sites have subsites within them with different domain names, these subsites are virtual's based on domainname with all the same parent IP. If I have MP2 modules and location names that I want to share to specific IPs or Specific Virtual Hosts is there was way to define it once or does it have to be within each virtual host. For example: VirtualHost 10.0.0.5 ServerName domain1.com PerlModule YADDA::LoginLocation "/login" SetHandler perl-script PerlHandler YADDA::Login/Location /VirtualHost VirtualHost 10.0.0.5 ServerName domain2.com /VirtualHost VirtualHost 10.0.0.6 ServerName domian3.com /VirtualHost In the case above I want the module YADDA::Login and the location to be available to BOTH the .05 virtual hosts, but not the .06 - so both /domain1.com/login and domian2.com/login do the same thing but domain3 would not. Is the choice either global to everything or defined within each virtual that I want it? I've been reading the server and dir create/merge section on perl.apache.org but I'm not even sure it relates. Thanks -Chris
Use of Apache::Directive in BEGIN block
Title: Use of Apache::Directive in BEGIN
block
Using
Apache/2.0.45 (Unix) mod_perl/1.99_08 Perl/v5.8.0
on a Redhat 87.0 system
I get the following error:
Can't locate object method lookup via package
Apache::Directive at
/webcontent/dev.mycardmaker.com/lib/perl/Doodlelab/Apache/Test.pm line
4.
when I try to start Apache.
Here is the entire contents of Test.pm
BEGIN {
use Apache::Directive;
my $tree =
Apache::Directive-conftree();
foreach my $node (
$tree-lookup('PerlSetVar') ) {
# I want to do something here.
}
}
1;
--
--
Matisse Enzer
Hamilton Partners
707-431-4300 ext. 212 (office)
415-225-6703 (mobile)
Re: Use of Apache::Directive in BEGIN block
Matisse Enzer wrote:
Using Apache/2.0.45 (Unix) mod_perl/1.99_08 Perl/v5.8.0
on a Redhat 87.0 system
I get the following error:
Can't locate object method lookup via package Apache::Directive at
/webcontent/dev.mycardmaker.com/lib/perl/Doodlelab/Apache/Test.pm line 4.
when I try to start Apache.
Here is the entire contents of Test.pm
BEGIN {
use Apache::Directive;
my $tree = Apache::Directive-conftree();
foreach my $node ( $tree-lookup('PerlSetVar') ) {
# I want to do something here.
}
}
1;
Matisse, your bug report is incomplete, you have missed the report about your
environment as explained at the guidelines (http://perl.apache.org/bugs/). In
the future please include it, it's probably unimportant for this case.
To address this issue upgrade to 1.99_09 or may be you even need the current
cvs, I don't remember when Philippe has fixed that, check the Changes file.
t/response/TestApache/conftree.pm does the testing of this feature and works
just fine in the current cvs.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Summary: identifiying unique users
Ged wrote: How to avoid multiple logins? The short answer is: you can't. Sure you can. Charge $10 per login. I don't want to clobber the list with non-technical trivia, but even when you charge money, you can't avoid it. If only there is one user that is willing to pay the amount twice, your scheme is broken. As with technical solutions: the higher the amount you charge, the lesser the risk of people doing it. But the risk remains... --Frank
Sleeping sessions
Hello modperl, I need help. I've compiled apache 1.3.28 + mod_perl 1.28 + mod_ssl 2.8.15. Before that all was ok, but at the moment all httpd session freezing in memory and turning to sleeping, 30-40 min and server is overloaded. I use PerlRun instead of Apache::Registry. Any ideas? --- Sincerely yours, Andrey A. Kudrin,
Re: Sleeping sessions
Hi there, On Wed, 17 Sep 2003, Andrey A. Kudrin wrote: I've compiled apache 1.3.28 + mod_perl 1.28 + mod_ssl 2.8.15. Before that all was ok, Before what? Before mod_ssl? Try it without. Have you checked in the documentation that the version of mod_ssl is suitable for your purposes? but at the moment all httpd session freezing in memory and turning to sleeping, 30-40 min and server is overloaded. You must send more information. Read the documentation on the mod_perl site to find out what you need to send. 73, Ged.
Re: Summary: identifiying unique users
On Wed, Sep 17, 2003 at 08:39:58AM +0200, Frank Maas wrote: Ged wrote: How to avoid multiple logins? The short answer is: you can't. Sure you can. Charge $10 per login. I don't want to clobber the list with non-technical trivia, but even when you charge money, you can't avoid it. If only there is one user that is willing to pay the amount twice, your scheme is broken. As with technical solutions: the higher the amount you charge, the lesser the risk of people doing it. But the risk remains... The only nearly reliable way I have found of doing this is to impliment a two stage registration process. Normal online registration with a face to face sales meeting where the account is activated. This however requires significant investment in an offline process and backoffice. On the down side people can always :- A. Use another legitimate account (Beg, Borrow, Steal) B. Have another meeting where an actor obtains the new acount details (Fraud). In respect to client side cookies this does not help as I will often in the case of system testing use multiple machines (Unix/Windows) with multiple browser versions. Your best be is to use server side token versioning which will prevent multiple browsers simultaniously using the same login but does not prevent different logins being used. Hope it helps Paddy
upgrading to apache 2
I am currently running apache 1.3.26 with mod_perl 1.36 and Perl 5.6.1 on my web server which is a Sun Solaris machine running Solaris 7. We have just bought a new Sun machine for our web server and I will be installing Solaris 9. I figure that now is a good time to upgrade my software. I would like to install Apache 2, mod_perl 2, and Perl 5.8. Does anyone know of any specific problems, issues that I should look out for? I am also running MySQL and I use the perl DBI-DBD modules for interfacing between apache and mysql. If anyone has any suggestions or tips to pass along I would appreciate it. Malki Cymbalista Webmaster, Weizmann Institute of Science Rehovot, Israel 76100 Internet: [EMAIL PROTECTED] 08-934-3036
Re: upgrading to apache 2
Hello there, On Wed, 17 Sep 2003, Malka Cymbalista wrote: I am currently running apache 1.3.26 with mod_perl 1.36 and Perl 5.6.1 on my web server which is a Sun Solaris machine ... I would like to install Apache 2, mod_perl 2, and Perl 5.8. While Apache version 2 is stable, mod_perl version 2 is not yet. If you are prepared to accept some of the issues which arise during the early stages of software development then by all means try mod_perl version 2. If not, then stay with the latest version 1, which means you must also use a version 1 Apache. There have been several issues with Perl 5.8.0, and although I have had no problems with 5.8.0 on my own development boxes, in either case I would wait for Perl 5.8.1 before release into a user environment - and I would test that for a couple of months first. As far as I can tell Perl 5.6.1 is as good a release of Perl as any. 73, Ged.
Re: AIX perfomance
Hi Ged, On 9/12/03 at 4:12 PM, [EMAIL PROTECTED] (Ged Haywood) wrote: Roughly what hardware setups do you generally work with, and what differences are notable between Linux and AIX when running mod_perl servers? (If that's not too long a piece of string to measure:). Are there situations where you'd prefer one or the other, if so why? Sorry for the slow response; I've been out of town. Most of my mod_perl/AIX systems are used to generate organizational performance reports, basically data-mart type stuff, which is very DBI (DB2) and computationally-intensive, and also often invlove running COBOL binaries which have been ported from OS/390 and run via RPC::XML. If the need to run COBOL is absent from a project, then I usually deploy on Lintel, since procurement is so much easier. I never rely on OS ditributions of perl, apache, or mod_perl so my working enviroment is always identical. As I mentioned earlier, Rafael should not be experience slowness on AIX unless he's comparing dated RS/6000 hardware with new Intel. Scalability, especially with big SMP iron, still favors the RS/6000 though at a colossal cost. Bill
Re: Sleeping sessions
Ged Haywood wrote: [...] but at the moment all httpd session freezing in memory and turning to sleeping, 30-40 min and server is overloaded. You must send more information. Read the documentation on the mod_perl site to find out what you need to send. Ouch, that's a lot to read ;) It's better to point people to a simple: http://perl.apache.org/bugs/ Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RTF/MSword Generation from PERL
Hi All, I have an online FAQ. Running under IIS 5.0/Win2k/PerlEx with ActiveState Perl 5.6.1 ... sorry can't run 5.8.0 yet The answers to the FAQ questions contain jpegs, bmps, and gifs I'd like to repeatably generate RTF/MSWord 97 files from XHTML1.0 Transitional webpages 1 per FAQ (webpage) and 1 large ~300MB for the whole site. I know I can use RTF::Writer and some other HTML::* modules [Thanks Sean M. Burke :) ] . but I'm a little iffy on the embedding of images in it ? It can be done since win2k app, 'write', supports it but via PERL ? Also, does anyone have a link handy to the full spec ? I can't seem to get any good search results on search.cpan.org for MSWord is there a different phrase I should be looking for ? Would SP/jade be a better solution ? Thanks in advance. END -- Philip M. Gollucci Consultant E-Mail: [EMAIL PROTECTED] URL : http://p6m7g8.net/Resume/resume.shtml Phone : 301.474.9598 eJournalPress DBA / Software Engineer / System Administrator E-Mail: [EMAIL PROTECTED] URL : http://www.ejournalpress.com Phone : 301.530.6375 $Id: .signature,v 1.4 2003/05/02 23:46:37 philip Exp $
Re: RTF/MSword Generation from PERL
Philip M. Gollucci wrote: Hi All, I have an online FAQ. Running under IIS 5.0/Win2k/PerlEx with ActiveState Perl 5.6.1 ... sorry can't run 5.8.0 yet The answers to the FAQ questions contain jpegs, bmps, and gifs Philip, frankly I fail to see anything in your request that has to do with modperl. There are many other appropriate places where you can ask this question. See: http://perl.apache.org/docs/offsite/other.html Let's keep the Signal to Noise ratio high on this list. Thank you. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Apache::IncludeHook
Geoffrey Young wrote: hi all... I wanted to let everyone know that I have ported !-- #perl -- SSI tag support to Apache 2.0. it should behave under both prefork and threaded mpms, and work pretty much the same as it did in Apache 1.3, despite the fact that mod_include is now an output filter. while the support is fairly complete, the code is a bit messy and can be refactored. however, I wanted to get something released for people to play with before I needed to move on to something else. geoff++ can you please update this page? http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl v2 Forking
Cameron B. Prince wrote:
I have a report generator program written in Perl that I need to start from
a CGI. The program takes about 15 minutes to run, so I must fork or double
fork. I have two goals:
1) Have no zombies when the program completes
2) Fork in such a way that restarting Apache doesn't kill the forked
process.
I tried out the code here which is for mod_perl v1:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
There are two problems with the code listed in the example:
1) Apache::SubProcess doesn't seem to contain the same methods as the older
version.
most of them aren't needed (they don't exist in the Apache 2.0 API.
2) open isn't working. (I've already been down this road and switched
another call to an external program to use IPC::Run, but that program
doesn't take long and needs no fork.)
what open()? what's not working? please be more specific, show us some code
and the actual error messages. Are you talking about open in
http://perl.apache.org/docs/1.0/guide/performance.html#A_Complete_Fork_Example
?
I took out the parts of the code that caused problems and ended up with
this:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This works and accomplishes my first goal, but not the second. If I start
the program and restart Apache, the program is killed.
have you detached the session as explained here?
http://perl.apache.org/docs/1.0/guide/performance.html#Detaching_the_Forked_Process
I admit I haven't tried this code from the above url with 2.0 yet (and it'd be
nice to have such a test (hint! hint!)) but I can't see it in your sample, so
I assume that you haven't tried it ;)
Also while you are at it, once you figure out all the quirks if you can help
us porting
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl
to 2.0 docs that would be very helpful for those coming after you. Thanks.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Steve Hay wrote: [...] Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. What other misleading parts are we talking about? The main thing is to get mod_perl.lib installed in the first place under mp1. I remember someone wanted to port ModPerl::MM to mp1, if that happens, than it'd become a non-issue as well ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Steve Hay wrote: [...] Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. What other misleading parts are we talking about? I'm just getting confused with changes in Apache itself, I think. Apache 1 used to have lib, libexec and modules: lib stored the static .lib's, libexec stored the import libraries for various dll's, and modules stored the .so (aka .dll) files for Apache modules. But with Apache 2, I have only lib and modules. The latter still (rightly) contains just the .so files for Apache modules, so presumably all the static *and* import libraries are thrown together into lib now? Now, my mp2's Apache::BuildConfig contains this: 'MODPERL_AP_LIBDIR' = 'C:\\apache2/lib', 'MODPERL_AP_LIBEXECDIR' = 'C:\\apache2/modules', which I find confusing. The first line there is fine, but the second line seems wrong. One would think that MODPERL_AP_LIBEXECDIR specifies where Apache's libexec directory is, but there isn't one any more! Furthermore, it seems that the files that would have been in it are now in lib? So maybe MODPERL_AP_LIBEXECDIR should say C:\\apache2/lib (that's an ugly mess of back- and forward slashes too), and that should be used as the location to install mod_perl.lib into (since mod_perl.lib is one of these import library things). That would be wrong as things stand, though, because MODPERL_AP_LIBEXECDIR seems to be used as the location to install mod_perl.so, which should indeed be C:\\apache2/modules. Perhaps the simplest thing would be to rename MODPERL_AP_LIBEXECDIR to MODPERL_AP_MODDIR since it specifies where Apache's modules directory is and there isn't a libexec anymore? - Steve
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: Basic authentication
Stephen Hardisty wrote:
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;
don't do that - AUTH_REQUIRED is an error status, so apache will send it's
own set of headers.
my ($status, $password) = $r-get_basic_auth_pw;
if ($status != OK)
{
$r-status($status);
exit($status);
}
yike!
you shouldn't ever play with $r-status. calling exit is also not the
standard way.
examples of auth handlers abound, so you should really just be following
them - even though you are using mod_perl 2.0, the API is really the same
wrt get_basic_auth_pw() etc.
some examples include the many, many modules on CPAN. you can also find
detailed auth examples in
http://www.modperlcookbook.org/chapters/ch13.pdf
and
http://www.modperlcookbook.org/code/ch13/
specifically
http://www.modperlcookbook.org/code/ch13/Cookbook/Authenticate.pm
HTH
--Geoff
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) or die Couldn't restart: $!\n;
}
sub sigALRM_handler {
print got ALARM timeout\n;
}
$SIG{CHLD} = \REAPER_NEW;
sub REAPER {
$SIG{CHLD} = \REAPER; # loathe sysV
my $waitedpid = wait;
logmsg reaped $waitedpid . ($? ? with exit $? : '');
}
sub REAPER_NEW {
logmsg got - @_\n;
my $wpid = undef;
while ($wpid = waitpid(-1,WNOHANG)0) {
logmsg main $pid -- reaped $wpid . ($? ? with exit $? : '')
;
print DIED reaped $wpid . ($? ? with exit $? : '');
}
}
print PID: $$\n;
print ARGV: @ARGV\n;
print [Server $0 accepting clients]\n;
#while (my $connection = $listen_socket-accept()) {
while (1) {
my $connection = $listen_socket-accept() or do {
next if $!{EINTR};
last;
};
print DIED Erro was $! %! \n;
$connection-autoflush(1); ## missing seemed to cause client problem, but
not telnet
if (!defined($pid = fork)) {
logmsg cannot fork: $!;
}elsif
Re: mod_perl v2 Forking
Eric Frazier wrote: ... 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. Mostly, yes. Look at the perldelta manpage that is distributed with perl 5.8.0, section Safe Signals. If you want to restore the 5.6-ish unsafe signal handling, this is not possible with 5.8.0 :(. But, as it has been acknowledged that this unsafe behaviour is desirable in some cases, it will be possible with perl 5.8.1. You can grab a 5.8.1 release candidate 4 from CPAN : http://search.cpan.org/~jhi/ (RC5 should be out in a few days) and see with it if using unsafe signal handlers solves your problem. You can enable them with the PERL_SIGNALS environment variable. Here's the relevant part of the perlrun manpage that comes with perl 5.8.1 RC4 : =item PERL_SIGNALS In Perls 5.8.1 and later. If set to Cunsafe the pre-Perl-5.8.0 signals behaviour (immediate but unsafe) is restored. If set to Csafe the safe (or deferred) signals are used. See Lperlipc/Deferred Signals (Safe signals). HTH.
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, That sound like one way to go, I want to be very careful with something like this. You speak as if restoring 5.6 behaviour is the best or only way to go. Do you see any other alternatives? Thanks, Eric At 04:57 PM 9/16/03 +0200, Rafael Garcia-Suarez wrote: Eric Frazier wrote: ... 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. Mostly, yes. Look at the perldelta manpage that is distributed with perl 5.8.0, section Safe Signals. I did read that, it seems kind of misleading. The 5.8 IPC doc was more helpful, but I still didn't get a clear idea how to handle this and the examples are not updated yet. If you want to restore the 5.6-ish unsafe signal handling, this is not possible with 5.8.0 :(. But, as it has been acknowledged that this unsafe behaviour is desirable in some cases, it will be possible with perl 5.8.1. You can grab a 5.8.1 release candidate 4 from CPAN : http://search.cpan.org/~jhi/ (RC5 should be out in a few days) and see with it if using unsafe signal handlers solves your problem. You can enable them with the PERL_SIGNALS environment variable. Here's the relevant part of the perlrun manpage that comes with perl 5.8.1 RC4 : =item PERL_SIGNALS In Perls 5.8.1 and later. If set to Cunsafe the pre-Perl-5.8.0 signals behaviour (immediate but unsafe) is restored. If set to Csafe the safe (or deferred) signals are used. See Lperlipc/Deferred Signals (Safe signals). HTH. (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
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 = '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
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
Hi,
Well, I am not sure if this is going to be the best solution long term, but
it works!
while ( $connection ){
my $return_value = undef;
if(/quit|exit/i){ last;}
elsif (/closeme/i ) {$connection-close(); }
elsif (/date|time/i){ printf $connection %s\n, scalar
localtime; exit(0); }
that did call to a sub, and then connected to a database. I am wondering if
that connection object is better off being global. I changed the connect to
be global, restarted and did a test and it worked fine! I was all ready to
post back to here with the good news, when just to double check I went back
and made the db connect in the local sub like before. And it still worked?!
So it seems like I might be in better shape for now, but I might have some
long term problems with DB connections dieing, most likely related to this
child handling. I have to think that becase the query I am doing is VERY
well tested and never causes an issue.
Thanks tremedously for everyone's help so far, I at the very least have some
directions to go in now.
I still would very much like to learn what the correct, put it in the book
solution should be..
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 ();
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 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;
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 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
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
ensuring singularity of users
Hi, I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. I'm looking into Captchas, but I'm wondering what other options there are, and what folks think about that here. My impression so far is that there's no 100% effective way to do it. If there's a better place to ask about this, please let me know. Thanks, Zack -- Zack Brown
client-side certificate extraction
ModPerlers, We have a requirement to change our web servers to require client-side ssl certificates by Oct 1, 2003. Can someone give me some pointers on how mod_perl might be used to extract the user's name at login time. I suspect this might require a handler. This might be used to avoid multiple logins. Thanks Chuck winmail.dat
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Steve Hay wrote: [...] What other misleading parts are we talking about? I'm just getting confused with changes in Apache itself, I think. Apache 1 used to have lib, libexec and modules: lib stored the static .lib's, libexec stored the import libraries for various dll's, and modules stored the .so (aka .dll) files for Apache modules. But with Apache 2, I have only lib and modules. The latter still (rightly) contains just the .so files for Apache modules, so presumably all the static *and* import libraries are thrown together into lib now? Now, my mp2's Apache::BuildConfig contains this: 'MODPERL_AP_LIBDIR' = 'C:\\apache2/lib', 'MODPERL_AP_LIBEXECDIR' = 'C:\\apache2/modules', which I find confusing. The first line there is fine, but the second line seems wrong. One would think that MODPERL_AP_LIBEXECDIR specifies where Apache's libexec directory is, but there isn't one any more! Furthermore, it seems that the files that would have been in it are now in lib? So maybe MODPERL_AP_LIBEXECDIR should say C:\\apache2/lib (that's an ugly mess of back- and forward slashes too), and that should be used as the location to install mod_perl.lib into (since mod_perl.lib is one of these import library things). That would be wrong as things stand, though, because MODPERL_AP_LIBEXECDIR seems to be used as the location to install mod_perl.so, which should indeed be C:\\apache2/modules. Perhaps the simplest thing would be to rename MODPERL_AP_LIBEXECDIR to MODPERL_AP_MODDIR since it specifies where Apache's modules directory is and there isn't a libexec anymore? It's the problem with apxs then, since mp2 just uses the same names as apxs: ~/httpd/prefork/bin/apxs -q LIBEXECDIR /home/stas/httpd/prefork/modules ~/httpd/prefork/bin/apxs -q LIBDIR /home/stas/httpd/prefork/lib I'm not sure if we want to contradict apxs on that. My suggestion is to remove the need for developers to know about those dirs/vars and have it all abstracted behind ModPerl::MM (which already does most of it). If it gets ported to mp1 and uses the same API then no matter what happens behind the scenes it'll do the right thing for the developer. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
(please trim your followups!) Re: mod_perl v2 Forking
whoah! people, please trim the irrelevant stuff in your replies, this thread keeps on growing for no reason. Perhaps you should read http://perl.apache.org/maillist/email-etiquette.html#Extracts_From_Other_Posts if you are new to this list. We want these threads to be useful for those who will later read them in archives. Thank you! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[Fwd: mod_perl and PHP don't share the environment nicely]
Forwarded on behalf of Andy Lester [EMAIL PROTECTED] Original Message Date: Mon, 15 Sep 2003 14:53:15 -0500 From: Andy Lester [EMAIL PROTECTED] To: Perl 5 Porters [EMAIL PROTECTED], [EMAIL PROTECTED] PHP and mod_perl do not share the environment nicely. PHP's putenv() will cause segfaults. Caveats should be distributed all around in PHP and mod_perl, at the very least, with the following two options: * Recompile Perl itself with -DPERL_USE_SAFE_PUTENV, then recompile mod_perl and Apache, in that order. * Replace all PHP calls to putenv() with apache_setenv(). I'm publishing this so that it will be archived and Googlable. Most of the following is written by, and based research from, Nick Dronen. xoxo, Andy ++ Background / Affected Configuration ++ We've been seeing segmentation faults in an Apache configured with mod_perl and PHP. There are several posts, all to archived PHP mailing lists, with stack traces that match the ones we've been seeing, but no useful resolutions. This document describes the problem and solution so other users who encounter this problem can acquire a clear idea what to do. At first, it looks like the problem is caused by either PHP or the C runtime library. It's not. It's caused by the use of both mod_perl and mod_php in Apache, if (and hopefully only if) your perl is not configured to use the C library's putenv(3) routine. Other Apaches configured to use mod_perl and any other module that manipulates the process's environment may also be affected. At any rate, this is what we're using: * Apache 1.3.28 * PHP 4.3.3 * Perl 5.8.0 * mod_perl 1.28 ++ Symptoms - PHP ++ If PHP is configured with --enable-debug, errors containing apparantly corrupt memory will appear in the log files. (Reformatted here to make it less unreadable.) [Thu Aug 28 13:11:47 2003] Script: '/path/to/file.html' /usr/src/php-4.3.3/Zend/zend_opcode.c(159) : Block 0x08D77C58 status: /usr/src/php-4.3.3/Zend/zend_variables.c(44): Actual location (location was relayed) Beginning: OK (allocated on Zend/zend_language_scanner.c:4718, 64 bytes) End: Overflown (magic=0x08376158 instead of 0x2A8FCC84) At least 4 bytes overflown --- [Thu Aug 28 13:11:47 2003] [error] php Warning: String is not zero-terminated ([EMAIL PROTECTED]) (source: /usr/src/php-4.3.3/Zend/zend_opcode.c:159) in Unknown on line 0 [Thu Aug 28 13:11:47 2003] Script: '/path/to/file.html' --- /usr/src/php-4.3.3/Zend/zend_opcode.c(159): Block 0x08D77D00 status: /usr/src/php-4.3.3/Zend/zend_variables.c(44): Actual location (location was relayed) Beginning: Overrun (magic=0x083763F0, expected=0x7312F8DC) [Thu Aug 28 13:11:47 2003] [notice] child pid 3983 exit signal Segmentation fault Note that the garbage in the String is not zero-terminated line is about 80 characters long and filled with randomness. It's been truncated here. Symptoms - core dumps If your apache is able to create a core file, you can examine the stack trace by doing: $ gdb /path/to/httpd /path/to/core or $ dbx /path/to/httpd /path/to/core In some cases -- specifically when httpd is running suid/sgid -- Apache will not dump core. There is a kernel patch for Linux that changes this behavior so you can get a core dump. The patch is available for Linux kernel versions 2.4.x and 2.5.x at: http://www.ussg.iu.edu/hypermail/linux/kernel/0204.2/1170.html Memory madness can cause segmentation faults at any number of places in a complex program, depending on how memory is accessed. Below is one of the more common stack traces we've seen . A strong sign that you're suffering from this problem is the presence of putenv(3) in the stack. If your stacks look different than this, a sample program appears at the end of this document, along with instructions how to run it. If the program segfaults, you might be seeing the same problem. Here's a classic stack trace (also reformatted a bit): #0 0x4207448f in _int_realloc () from /lib/i686/libc.so.6 #0 0x4207448f in _int_realloc () from /lib/i686/libc.so.6 #1 0x42073416 in realloc () from /lib/i686/libc.so.6 #2 0x4202ab8f in __add_to_environ () from /lib/i686/libc.so.6 #3 0x4202aab8 in putenv () from /lib/i686/libc.so.6 #4 0x080f68ba in zif_putenv ( ht=1, return_value=0x8c01ffc, this_ptr=0x0, return_value_used=0) at /usr/src/php-4.3.3/ext/standard/basic_functions.c:1347 #5 0x080ce2e6 in execute
Re: ensuring singularity of users
On Tue, 2003-09-16 at 12:46, Zack Brown wrote: I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. We talked quite a bit about preventing multiple logins recently. I think it was last week. Check the archives. I'm looking into Captchas Are you trying to prevent multiple people from using the same account, or one person from having multiple windows open, or anyone from using bots? My impression so far is that there's no 100% effective way to do it. That's correct, unless you have control over the client machines. You can require cookies, which will tell you if multiple users on separate browsers are sharing a login, but that's about all you can do without possibly breaking your system for someone. - Perrin
Re: ensuring singularity of users
Perrin Harkins wrote: On Tue, 2003-09-16 at 12:46, Zack Brown wrote: I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. We talked quite a bit about preventing multiple logins recently. I think it was last week. Check the archives. Perhaps someone would like to summarize these and put a short tutorial on perl.apache.org? This question seems to come back pretty often. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ensuring singularity of users
On Tue, Sep 16, 2003 at 01:55:46PM -0400, Perrin Harkins wrote: On Tue, 2003-09-16 at 12:46, Zack Brown wrote: I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. We talked quite a bit about preventing multiple logins recently. I think it was last week. Check the archives. I'm looking into Captchas Are you trying to prevent multiple people from using the same account, or one person from having multiple windows open, or anyone from using bots? I want to prevent one person from having multiple accounts. My impression so far is that there's no 100% effective way to do it. That's correct, unless you have control over the client machines. You can require cookies, which will tell you if multiple users on separate browsers are sharing a login, but that's about all you can do without possibly breaking your system for someone. Someone can appear to be multiple people by disabling cookies though. I want to ensure that if person A registers to use a site, they are not able to register again using a different login, or else they are only able to register a small enough number of times that it isn't worth it for them to do so. Be well, Zack - Perrin -- Zack Brown
Re: ensuring singularity of users
On Tue, 2003-09-16 at 14:42, Zack Brown wrote: I want to prevent one person from having multiple accounts. Okay. That's correct, unless you have control over the client machines. You can require cookies, which will tell you if multiple users on separate browsers are sharing a login, but that's about all you can do without possibly breaking your system for someone. Someone can appear to be multiple people by disabling cookies though. That's why I said require cookies: you reject all requests from people who don't allow cookies, and then you use the cookies for tracking. A moderately tech-savvy user can delete your cookie and log in again under a separate account, but people who are scared of opening up prefs and messing with cookie management (or people who simply don't care enough to bother) will be stopped. If you have a fixed set of clients who are definitely not using proxies, you can use IP instead of cookies. I want to ensure that if person A registers to use a site, they are not able to register again using a different login Ask them for a credit card then. There's no other way that will really work 100% of the time. - Perrin
Re: ensuring singularity of users
On Tue, Sep 16, 2003 at 03:11:04PM -0400, Perrin Harkins wrote: On Tue, 2003-09-16 at 14:42, Zack Brown wrote: I want to prevent one person from having multiple accounts. Okay. That's correct, unless you have control over the client machines. You can require cookies, which will tell you if multiple users on separate browsers are sharing a login, but that's about all you can do without possibly breaking your system for someone. Someone can appear to be multiple people by disabling cookies though. That's why I said require cookies: you reject all requests from people who don't allow cookies, and then you use the cookies for tracking. A moderately tech-savvy user can delete your cookie and log in again under a separate account, but people who are scared of opening up prefs and messing with cookie management (or people who simply don't care enough to bother) will be stopped. If you have a fixed set of clients who are definitely not using proxies, you can use IP instead of cookies. Any simple way to defeat the system will end up not working. I'm looking for something truly secure. I want to ensure that if person A registers to use a site, they are not able to register again using a different login Ask them for a credit card then. There's no other way that will really work 100% of the time. That's what I figured. Even that won't work all the time, but it will probably limit people to one login per credit card. Unfortunately, then I have to get a merchant account, and there will always be some users who just don't like giving out credit card information. Be well, Zack - Perrin -- Zack Brown
Summary: identifiying unique users
Stas Bekman wrote: Perrin Harkins wrote: Zack Brown wrote: I'd like to implement something that tries to ensure that one user can't masquerade as multiple users. We talked quite a bit about preventing multiple logins recently. I think it was last week. Check the archives. Perhaps someone would like to summarize these and put a short tutorial on perl.apache.org? This question seems to come back pretty often. I tried to recap the discussion and looked in the archive. Am I wrong when I summarize it with it is not possible in a foolproof way? Or, with a bit more words: | How to avoid multiple logins? | | The short answer is: you can't. To ensure that a login is only used | by one person at the same time, you need to have some method to | identify persons. You can't do that based on the information you | can get from a request. And even if you could get information, there | is no guarantee that the information is correct - it can be faked | | IP-address |can hardly be mentioned as a contestor with proxy servers, |firewalls, anonimyzers and the rest; | | MAC-address |there are reports that it is able to get this as part of the UUID |or in an SSL key, but it can't be trusted as a user could simply |change this or make it a non-unique value | | SSL session id |it seems that SSL_SESSION_ID offers some unique recognition of |the client; it stays valid for some time (hours, days) and is |there to avoid needless handshaking | | Cookie |you can do something supplying a unique identifier in a cookie |that you provide, but chances are that you lock up your system. |The interesting issue is 'when do you expire a cookie/user link?' |Do this too early and you will allow logins to hop from one person |to the other, do this too late and you will have problems with |people that (for instance) suffer from a crashing browser | | Where IP and MAC address seem totally unusable, the SSL session and | your own cookie offer a mechanism that can of use. If you aim at the | not-so-technical user and are prepared to be rude to those users | that tamper with your system, you can make it work to some extent. Comments and additions to this summary are welcome through the list. After polishing this, it can be brought into the proper docs. --Frank
Re: Summary: identifiying unique users
Hi all, On Tue, 16 Sep 2003, Frank Maas wrote: | How to avoid multiple logins? | | The short answer is: you can't. Sure you can. Charge $10 per login. 73, Ged.
Re: Summary: identifiying unique users
On Tue, Sep 16, 2003 at 10:46:28PM +0100, Ged Haywood wrote: Hi all, On Tue, 16 Sep 2003, Frank Maas wrote: | How to avoid multiple logins? | | The short answer is: you can't. Sure you can. Charge $10 per login. If they can make more than $10 by faking a login, then it's worth it. 73, Ged. -- Zack Brown
Re: AIX perfomance
On Fri, Sep 12, 2003 at 04:12:00PM +0100, Ged Haywood wrote: Hi there, On Fri, 12 Sep 2003, William McCabe wrote: I've got a lot of experience with mod_perl on both linux and AIX and can state categorically that there are no typical conditions which would cause AIX run strangely slowly compared to linux on comparable hardware. That's useful information, thanks Bill. We don't see much about AIX here but it seems to me that it's been becoming more common recently. AIX will of course have an massive growth in popularity now that SCO has withdrwan IBMs un*x licence. ;* Paddy
[PATCH] Re: mp2 with perl-5.8.1 on Windows
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Hi,
Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows?
I've got it building, but I can't start the Apache server at all. (It's
fine without the mod_perl bits in the httpd.conf file.)
See this thread on p5p for what I'm getting:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html
Cheers,
- Steve
I also found a problem, as below:
==
Perl_safesysmalloc(unsigned int 0x0010) line 70 + 21 bytes
: perl-5.8.1/util.c
modperl_hash_seed_init(apr_pool_t * 0x0026a7f0) line 44 + 7 bytes
: modperl-2.0/src/modules/perl/mod_perl.c
modperl_hook_pre_config(apr_pool_t * 0x0026a7f0,
apr_pool_t * 0x00848100, apr_pool_t * 0x0084a108) line 594 + 9 bytes
: modperl-2.0/src/modules/perl/mod_perl.c
ap_run_pre_config(apr_pool_t * 0x00401441, apr_pool_t * 0x0026a7f0,
apr_pool_t * 0x00848100) line 126 + 49 bytes
main(int 0x00401d82, const char * const * 0x0008) line 575 + 19 bytes
APACHE! mainCRTStartup + 227 bytes
==
which seems to be related to the safemalloc() call on line
44 of src/modules/perl/mod_perl.c. (by the way, I had to
comment out the fprintf() call at line 66 to get it to
compile, otherwise an error about my_perl being undeclared
was found).
I still haven't found out what the problem with the server crashing on
startup is, but the attached patch against CVS seems to fix the
fprintf() problem that you refer to.
I've no idea how advisable what I've done is, but without it I get:
=
cl -IC:/Temp/modperl-2.0/src/modules/perl
-IC:/Temp/modperl-2.0/xs -IC:\
apache2/include -IC:\apache2/include -nologo -Gf -W3 -Od -MD -Zi
-DDEBUGGING -DW
IN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
-DPERL_IM
PLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -IC:\perl\lib\CORE
-DMOD_PERL -
DMP_COMPAT_1X -Od -MD -Zi -DDEBUGGING -c mod_perl.c
C:\perl\bin\perl.exe -M
ExtUtils::Command -e mv mod_perl.obj mod_perl.lo
mod_perl.c
mod_perl.c(66) : error C2065: 'my_perl' : undeclared identifier
mod_perl.c(66) : warning C4047: 'function' : 'struct interpreter *'
differs in l
evels of indirection from 'int '
mod_perl.c(66) : warning C4024: 'Perl_IStdIO_ptr' : different types for
formal a
nd actual parameter 1
mod_perl.c(66) : warning C4047: 'function' : 'struct interpreter *'
differs in l
evels of indirection from 'int '
mod_perl.c(66) : warning C4024: 'Perl_IStdIO_ptr' : different types for
formal a
nd actual parameter 1
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
=
and with it, it all builds OK.
- Steve
PS. Randy: How do you that stacktrace output that you've posted? Is
that using MSVC++, or something else?
--- mod_perl.c.orig 2003-09-11 19:10:39.0 +0100
+++ mod_perl.c 2003-09-15 12:00:30.273019100 +0100
@@ -22,7 +22,7 @@
#endif
/* see modperl_hash_seed_set() */
-static void modperl_hash_seed_init(apr_pool_t *p)
+static void modperl_hash_seed_init(pTHX_ apr_pool_t *p)
{
#ifdef MP_NEED_HASH_SEED_FIXUP
char *s;
@@ -63,7 +63,8 @@
if (s) {
int i = atoi(s);
if (i == 1) {
-fprintf(stderr, \nmod_perl: using init hash seed: %UVuf\n,
+PerlIO_printf(PerlIO_stderr(),
+ \nmod_perl: using init hash seed: %UVuf\n,
MP_init_hash_seed);
}
}
@@ -587,10 +588,12 @@
int modperl_hook_pre_config(apr_pool_t *p, apr_pool_t *plog,
apr_pool_t *ptemp)
{
+dTHX;
+
/* we can't have PerlPreConfigHandler without first configuring mod_perl */
/* perl 5.8.1+ */
-modperl_hash_seed_init(p);
+modperl_hash_seed_init(aTHX_ p);
return OK;
}
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
On Mon, 15 Sep 2003, Steve Hay wrote: PS. Randy: How do you that stacktrace output that you've posted? Is that using MSVC++, or something else? Hi Steve, I'm using MSVC++ ... When a problem like this occurs, an offer is made to call up the VC++ debugger, where the trace is then done. In order to get a more useful trace (with symbol information), I compiled Perl using some patches to perl-5.8.x/win32/Makefile that ActiveState introduced (http://aspn.activestate.com/ASPN/Downloads/ActivePerl/Source). This patch enables debug symbols in release builds, and involves using '-Zi' in $(OPTIMIZE) and '-debug -opt:ref,icf' for $(LINK_DBG). With this, one gets .pdb files corresponding to compiled libraries, which hold the symbol information (I had to manually copy perl58.pdb [corresponding to perl58.dll] to C:\Perl\bin). The Apache/2.0.47 sources have this also enabled for the release build, by default, and building mod_perl as 'perl Makefile.PL ... MP_DEBUG=1' will enable them in mod_perl as well. -- best regards, randy
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
Randy Kobes wrote: On Mon, 15 Sep 2003, Steve Hay wrote: PS. Randy: How do you that stacktrace output that you've posted? Is that using MSVC++, or something else? Hi Steve, I'm using MSVC++ ... When a problem like this occurs, an offer is made to call up the VC++ debugger, where the trace is then done. In order to get a more useful trace (with symbol information), I compiled Perl using some patches to perl-5.8.x/win32/Makefile that ActiveState introduced (http://aspn.activestate.com/ASPN/Downloads/ActivePerl/Source). This patch enables debug symbols in release builds, and involves using '-Zi' in $(OPTIMIZE) and '-debug -opt:ref,icf' for $(LINK_DBG). With this, one gets .pdb files corresponding to compiled libraries, which hold the symbol information (I had to manually copy perl58.pdb [corresponding to perl58.dll] to C:\Perl\bin). The Apache/2.0.47 sources have this also enabled for the release build, by default, and building mod_perl as 'perl Makefile.PL ... MP_DEBUG=1' will enable them in mod_perl as well. Sorry, I should have made my question more specific. I've actually rebuilt Perl and Apache as full debug builds so I have all these .pdb files already. mod_perl gets them too because it inherits Perl's debug build mode. My question was where in the DevStudio GUI do you get at the stacktrace that you posted, or how do you get DevStudio to dump it out for you? All I can find is a Context drop-down (in the panel showing variables' values) from which I have to manually copy down the information (hence I only posted a list of functions!) It doesn't look like you've done that! - Steve
[ANNOUNCE] Apache::IncludeHook
hi all...
I wanted to let everyone know that I have ported !-- #perl -- SSI tag
support to Apache 2.0. it should behave under both prefork and threaded
mpms, and work pretty much the same as it did in Apache 1.3, despite the
fact that mod_include is now an output filter.
while the support is fairly complete, the code is a bit messy and can be
refactored. however, I wanted to get something released for people to play
with before I needed to move on to something else.
--Geoff
The URL
http://www.modperlcookbook.org/~geoff/modules/Apache-IncludeHook-2.00_01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GE/GEOFF/Apache-IncludeHook-2.00_01.tar.gz
size: 7289 bytes
md5: 0753eda141bf886290fa872fbffaf580
from the README:
NAME
Apache::IncludeHook - #perl Server Side Include support
SYNOPSIS
PerlModule Apache::IncludeHook
Alias /ssi /usr/local/apache/htdocs
Location /ssi
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Options +Includes
/Location
DESCRIPTION
Apache::IncludeHook offers support for #perl tags in
documents parsed by the mod_include engine included in
the Apache 2.0 distribution. Supported formats include
!--#perl sub=My::PrintArgs --
!--#perl arg=fee sub=My::PrintArgs arg=fie --
!--#perl arg=foe sub=My::PrintArgs::handler --
!--#perl arg=fum sub=My::PrintArgs-method_handler -- here
!--#perl arg=I smell sub=sub { my $r = shift; print @_ } --
In Apache 1.3, mod_include supported #perl tags out of
the box. In 2.0, support for tags outside the standard
mod_include realm ('echo', 'flastmod', etc) have been removed,
having been replaced with an API that allows you to hook
your own functionality into mod_include's parsing engine.
The 'exec' tag is an example of one that is no longer natively
supported by mod_include - mod_cgi now supplies the base
implementaiton of this tag.
The current hope with this module is simply to carry over #perl tag
support from Apache 1.3 to 2.0. Apache::SSI-like support
for custom tags will (possibly come later). keep in mind
that while this module is not inteneded to replace the old
Apache::SSI for Apache 1.3, because the new Apache 2.0 API
includes a filtering mechansim,
you already have the ability to post-process SSI tags via
Perl (or C) output filters.
EXAMPLE
file.shtml:
perl !--#perl arg=one sub=My::PrintArgs -- here
PrintArgs.pm:
package My::PrintArgs;
use Apache::RequestRec ();
use Apache::Const -compile = 'OK';
use strict;
sub handler {
my ($r, @args) = @_;
print join ' ', '***', (join ' : ', @args), '***';
return Apache::OK;
}
which is almost identical to what you would see with mod_perl 1.0,
save the mod_perl 2.0 specific classes.
NOTES
This implementation is designed to hook into the mod_include
that ships with Apache 2.0. It will not work with Apache 2.1.
This is alpha ware, subject to massive API changes. Meaning,
the TIEHANDLE interface may go away and you may be forced to
use only the (currently non-existent) filter interface. so
get to know filters now before it's too late (they're really
cool anyway).
FEATURES/BUGS
Subrequests are still a work in progress - they still don't seem
to work properly from filters.
only print STDOUT and $r-print are supported. other methods
of sending content to the client still need to be implemented.
AUTHOR
Geoffrey Young Elt[EMAIL PROTECTED]gt
COPYRIGHT
Copyright (c) 2003, Geoffrey Young
All rights reserved.
This module is free software. It may be used, redistributed
and/or modified under the same terms as Perl itself.
Re: mod_perl v2 Forking
Cameron, Have you tried issuing the command to `at`? If you don't need to interact wih the report generator, and can pass all the parameters in the command line or via a tmp file, this is a great solution. at (and the corresponding atd) will preserve your environment vars and other niceties. regards, martin
Re: Apache::Session permissions problem
On Saturday, Sep 13, 2003, at 09:22 America/Denver, Perrin Harkins wrote: I found a pretty useful article at http://www.linuxjournal.com/article.php?sid=4143 on how to use Apache::Session with Mason. I'm afraid that is not a very good article. It's out of date, and shows poor error handling. If you want to use sessions with Mason, you should be using the session handler that Mason provides. That is available on CPAN and is supported on the Mason list. Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? I never asked for IPC locking; it somehow snuck in. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. I'm honestly trying to figure out how I can draw those conclusions for myself, so I'm not stuck asking this list about them. Suggestions are more than welcome; I'm not quite sure how Session::SysVSempaphoreLocker got involved in the first place, since I don't explicitly reference it. Apache::Session::DBI uses it for locking. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? -=Eric
Re: Apache::Session permissions problem
Eric, Sorry if I came off overly critical. Many people have had problems trying to use Mason with Apache::Session because of that article. This is why on the Mason website the link to that article describes it as outdated and steers people to newer documentation. (It probably should also steer them to the new handler...) Eric Schwartz wrote: Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Did you look on the Mason site, http://masonhq.com/? That's the best place to find information on Mason. A search for session on that site includes a reference to MasonX::Request::WithApacheSession, available from CPAN. This is mentioned in the administrator's manual that comes with Mason. It's possible that you have an old version of Mason that predates this. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? The latest Apache::Session on CPAN is version 1.54, released in October 2001. The last release that included a module called Apache::Session::DBI was version 1.03, released two years earlier. I'm not certain what CPAN.pm would do if you told it to install Apache::Session::DBI. It might install the old one, which would be very unfortunate. Is that how you installed it? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? By using Apache::Session::Flex. The configuration for MasonX::Request::WithApacheSession also lets you do this. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. Look at the source and you'll see it. It's all much clearer in the more recent release though. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. The Apache::Session::PosixFileLocker and Apache::Session::SysVSemaphoreLocker modules are included with Apache::Session (although both are obsolete and only part of the old version that you installed). They have no documentation, so perldoc will not find them. The later equivalents (Apache::Session::Lock::File) do have docs. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? The docs are wrong. You can see it refers to the semaphore locker if you look at the source. Basically, you stumbled across an old article that referred to an obsolete version of Apache::Session, and all of your problems stem from that. If you get a later version and check out the Mason handler and the newer documentation on masonhq.com, I think it will all start to make sense to you. - Perrin
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
On Mon, 15 Sep 2003, Steve Hay wrote: I've actually rebuilt Perl and Apache as full debug builds so I have all these .pdb files already. mod_perl gets them too because it inherits Perl's debug build mode. My question was where in the DevStudio GUI do you get at the stacktrace that you posted, or how do you get DevStudio to dump it out for you? All I can find is a Context drop-down (in the panel showing variables' values) from which I have to manually copy down the information (hence I only posted a list of functions!) It doesn't look like you've done that! Hi Steve, I see now; that's something I struggled with too, until Doug pointed this out; try Alt+7 to give a stacktrace window (look under View - Debug Windows). And perhaps also to save some grief, if you want to copy it, select+right-click within that window doesn't work; you have to select+Edit-Copy. -- best regards, randy
RE: Apache::Session permissions problem
I'm afraid that is not a very good article. It's out of date, ... Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. I stumbled upon this problem quite a few times. Trying to get the hang of using cookies for authentication and sessions there are tons of modules and (a bit less...) articles, but they all seem outdated or simply not useful. So I build something myself, but am not quite sure this was the way to go. I had the same experience when (OT, sorry) I looked into things about using XML in combination with (mod_)perl. Most of the articles are rather old and I have no clue if they are outdated. Here as well I made some choices of my own, still thinking I am at least reinventing part of the wheel. Is there a, or are there initiatives to keep an 'accurate' document repository? I personally like perl.apache.org as a starting point, but it is quite restricted to mod_perl and mod_perl alone. (This is not meant as a rude remark!). Should and could this be broader containing links to interesting articles on 'well known subjects'? Should we then need som (continuous) reviewing and rating mechanism to separate the good from the bad? Or is Google still the way to go? --Frank PS: Apache::Session::DBI might be ancient, when I did some research for this mail I stumbled upon http://perl.apache.org/docs/1.0/guide/snippets.html#An_example_of_using_Apac he__Session__DBI_with_cookies. Perhaps it is a good beginning to try to keep/get outdated and ancient stuff from Our Main Source of Information?
RE: Apache::Session permissions problem
Is there a, or are there initiatives to keep an 'accurate' document repository? The field of knowledge is too broad for any one person to maintain, especially since the main people who maintain the site docs are quite busy building mod_perl 2. This is why we count on individuals stepping up and sending in corrections to outdated things they find in the docs. I personally like perl.apache.org as a starting point, but it is quite restricted to mod_perl and mod_perl alone. (This is not meant as a rude remark!). Should and could this be broader containing links to interesting articles on 'well known subjects'? There are quite a few links to other sources on perl.apache.org. My basic rule of thumb is to start with the most specific source of documentation. In your case, since you are trying to use Mason, you should look on the Mason site. There you would have found a note that the article you read is outdated, and a link to the current docs:http://masonhq.com/user/adpacifico/ApacheSessionMason.html PS: Apache::Session::DBI might be ancient, when I did some research for this mail I stumbled upon http://perl.apache.org/docs/1.0/guide/snippets.html#An_example_of_using_Apac he__Session__DBI_with_cookies. Perhaps it is a good beginning to try to keep/get outdated and ancient stuff from Our Main Source of Information? Yes, it would definitely be good to update or remove that snippet. A patch would certainly be appreciated. - Perrin
Re: mp2 with perl-5.8.1 on Windows
On Fri, 12 Sep 2003, Steve Hay wrote: Hi, Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows? I've got it building, but I can't start the Apache server at all. (It's fine without the mod_perl bits in the httpd.conf file.) See this thread on p5p for what I'm getting: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html Cheers, - Steve I also found a problem, as below: == Perl_safesysmalloc(unsigned int 0x0010) line 70 + 21 bytes : perl-5.8.1/util.c modperl_hash_seed_init(apr_pool_t * 0x0026a7f0) line 44 + 7 bytes : modperl-2.0/src/modules/perl/mod_perl.c modperl_hook_pre_config(apr_pool_t * 0x0026a7f0, apr_pool_t * 0x00848100, apr_pool_t * 0x0084a108) line 594 + 9 bytes : modperl-2.0/src/modules/perl/mod_perl.c ap_run_pre_config(apr_pool_t * 0x00401441, apr_pool_t * 0x0026a7f0, apr_pool_t * 0x00848100) line 126 + 49 bytes main(int 0x00401d82, const char * const * 0x0008) line 575 + 19 bytes APACHE! mainCRTStartup + 227 bytes == which seems to be related to the safemalloc() call on line 44 of src/modules/perl/mod_perl.c. (by the way, I had to comment out the fprintf() call at line 66 to get it to compile, otherwise an error about my_perl being undeclared was found). This is with Apache/2.0.47, the current mod_perl 2 cvs, and === Summary of my perl5 (revision 5 version 8 subversion 1) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:C:\Perl\lib\CORE -machine:x86' libpth=\lib libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:C:\Perl\lib\CORE -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: MAINT21199 Built under MSWin32 Compiled at Sep 14 2003 14:32:50 @INC: C:/Perl/lib C:/Perl/site/lib . = -- best regards, randy
Re: Apache::Session permissions problem
I found a pretty useful article at http://www.linuxjournal.com/article.php?sid=4143 on how to use Apache::Session with Mason. I'm afraid that is not a very good article. It's out of date, and shows poor error handling. If you want to use sessions with Mason, you should be using the session handler that Mason provides. That is available on CPAN and is supported on the Mason list. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. Permission denied at /Library/Perl/Apache/Session/SysVSemaphoreLocker.pm line 46. Which seems to indicate it isn't. I STFW, and found several people who seem to have had the same problem I have, but the solutions proffered involve ipcs and ipcrm, which don't exist on my Mac OS X 10.2.6 system. You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. Suggestions are more than welcome; I'm not quite sure how Session::SysVSempaphoreLocker got involved in the first place, since I don't explicitly reference it. Apache::Session::DBI uses it for locking. - Perrin
DynDNS.org -- Press Releases -- Free DNS for the Perl Community
FYI: Free DNS for the Perl Community http://www.dyndns.org/news/releases/archives/2002/09/74.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi!
On Thu, Sep 11, 2003 at 10:24:20PM -0500, Randy Kobes wrote:
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32 - I've also put up a ppm package
Oh, great! Thanks Randy! I'll put this into the next release, which should
happen in a few days...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Thu, 11 Sep 2003, Geoffrey Young wrote: The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. ah, right. thanks randy. examples of this can be found in Apache::WinBitHack, for example, the format of which should probably go in Apache::Dispatch (as well as just about all Apache:: modules to make sure they are Win32 compliant :) Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? Anyway, Apache::Dispatch is now up and running for me. Thanks, Randy! - Steve
Errors in my scripts cause apache getting strange...
Hi all,
I use Apache 1.3.26, mod_perl 1
I use Apache directive
ErrorDocument 500 /error500.html
So, if any errors occure, my web-site inform it in nice form (showing page
/error500.html).
But suddenly i change something in my scripts and now, when error happens,
Apache do not give me /error500.html page, but instead of it apache gets
output like this:
IkH{9`z4'7!?INnIE~G!h?rxC
O|!
and so on
My browser tries to save or open it (it means ContentType is not text/html)
It happens whith errors like this:
[Fri Sep 12 17:16:16 2003] [error] Can't call method commit on an
undefined value at /usr/local/apache-new/htdocs/lib/perl/Model/profile.pl
line 94.
it seems like usual error...
What does it mean?
Where is the reason? I want apche to show me /error500.html again on errors!
Thanks,
Anton Permyakov.
Apache::AuthCookie causing strange-Use of uninitialized value.
I use Apache::AuthCookie 3.04, which seems to be the latest version, under Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2 mod_perl/1.26. When I use PerlFixupHandler Apache::AuthCookie-recognize_user, Apache writes Use of uninitialized value. in errorlog for each request and subrequest. I have tried editing AuthCookie.pm, checking everything with defined(), even substituting recognize_user with a stub function. Still it is there. I am not sure it comes from perl, because perl use to say at line X too. But from what else? This has been up before, but no one answered it then: http://www.jsw4.net/info/list-archives/mod_perl/02-08/msg00591.html /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Re: Apache::AuthCookie causing strange Use of uninitialized value.
Thanks for your response! You have to subclass Apache::AuthCookie. This should be something like: PerlFixupHandler Your::Sublass-recognize_user Well, I do. I just pasted the wrong text (from the 2002 mail). The actual configuration snippet is: Location / AuthType TAS::Cookie AuthName TAS PerlFixupHandler TAS::Cookie-recognize_user /Location Another observation: It does only appear when no cookie is received. When users are logged in, everything is fine. And, yes, I checked recognize_user and put in a defined() around the cookie check. No result. Even a bad cookie (manually deleting the session) makes it quiet. /Per Eric -- ^): Per Eric Rosén http://rosnix.nu/~per/ / [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Have you benchmarked some simple things on the boxes? So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) 73, Ged.
Re: AIX perfomance
On 9/12/03 at 2:07 PM, [EMAIL PROTECTED] (Rafael Garcia-Suarez) wrote: I've a mod_perl application we've developed on Linux and that we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX -- the httpd configuration being similar. And that's mod_perl 1.28. So I'm asking for the common wisdom about performance issues on AIX. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? (which I haven't succeeded to build on AIX 4 by now BTW -- but I'm working on it.) I've built many mod_perl applications on linux and moved them to AIX 4.3.3 with no detriment at all. What do you mean by strangely slow? BIll
Re: AIX perfomance
Ged Haywood wrote: Hi there, On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote: we're porting on AIX (4.3.3 and 5.2.0). The AIX boxes are supposed to be more powerful than their Linux equivalents, however the application is strangely slow on AIX You don't give much to go on. Are they really more powerful? What does 'powerful' mean anyway? What discs do you have and what interfaces do they use, how much memory, what processors, speeds, how many mod_perl processes, how big are they, are you getting into swap, etc...? Well, it's difficult to compare very different hardware, but basically the AIX boxen have SCSI discs, more memory, etc. and they're a lot more expensive ;-) Have you benchmarked some simple things on the boxes? Benchmarking simple CPU-intensive perl scripts shows that they tend to be consistently slower in user time on AIX. Moreover if I survey CPU/memory usage on Linux and AIX (resp. with top and vmstat / w) I see that the application doesn't swap memory and that the load averages remains 0.10. So I'm asking for the common wisdom about performance issues on AIX. I don't know anything worth writing about AIX but I'd look a little deeper into what you're doing before you start blaming the OS. Currently the perl I use is built with gcc and default settings. Should I set -Dusemymalloc=y ? Should I use the xlC or vac compilers ? Should I port everything to mod_perl 2 ? To all those questions at this stage, my answer would be 'I doubt it'. Find out about your systems first. There are lots of tools to help you do that. Start by checking the relevant sections of the Guide for more information about performance and benchmarking. (Or look at the little disc activity light. :) Thanks, I'll dig deeper.
Re: AIX perfomance
Hi there,
On Fri, 12 Sep 2003, Rafael Garcia-Suarez wrote:
Benchmarking simple CPU-intensive perl scripts shows that they
tend to be consistently slower in user time on AIX.
Assuming that the boxes aren't otherwise heavily loaded, I wonder
about the options used to compile your Perl. For x86 architecture,
things like -mcpu=i386 will make a binary that you could run on a
steam engine but it won't be able to take advantage of the richer
instruction set on newer processors. I don't have a great deal of
experience with other modern processors, but from the gcc 3.2.3
documentation:
GCC defaults to `-maix32'
and there's a '-maix64' that may be worth a look, along with the rest
of the section ('info gcc' if you have it).
Optimisation may also be an issue, but use caution. Many packages
(e.g. the Linux kernel sources :) warn against anything more than
using -O2 with gcc for example.
73,
Ged.
mp2 with perl-5.8.1 on Windows
Hi, Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows? I've got it building, but I can't start the Apache server at all. (It's fine without the mod_perl bits in the httpd.conf file.) See this thread on p5p for what I'm getting: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html Cheers, - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Fri, 12 Sep 2003, Steve Hay wrote: Randy Kobes wrote: [ .. ] Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. -- best regards, randy
Re: AIX perfomance
On 9/12/03 at 2:54 PM, [EMAIL PROTECTED] (Ged Haywood) wrote:
Benchmarking simple CPU-intensive perl scripts shows that they
tend to be consistently slower in user time on AIX.
Assuming that the boxes aren't otherwise heavily loaded, I wonder
about the options used to compile your Perl. For x86 architecture,
things like -mcpu=i386 will make a binary that you could run on a
steam engine but it won't be able to take advantage of the richer
instruction set on newer processors. I don't have a great deal of
experience with other modern processors, but from the gcc 3.2.3
documentation:
GCC defaults to `-maix32'
and there's a '-maix64' that may be worth a look, along with the rest
of the section ('info gcc' if you have it).
Optimisation may also be an issue, but use caution. Many packages
(e.g. the Linux kernel sources :) warn against anything more than
using -O2 with gcc for example.
I think it's pretty useless to speculate as to causes until he clarifies what
strangely slow means and what AIX and linux hardware he's comparing. I've got
a lot of experience with mod_perl on both linux and AIX and can state
categorically that there are no typical conditions which would cause AIX run
strangely slowly compared to linux on comparable hardware.
Bill
Re: AIX perfomance
Hi there, On Fri, 12 Sep 2003, William McCabe wrote: I've got a lot of experience with mod_perl on both linux and AIX and can state categorically that there are no typical conditions which would cause AIX run strangely slowly compared to linux on comparable hardware. That's useful information, thanks Bill. We don't see much about AIX here but it seems to me that it's been becoming more common recently. Roughly what hardware setups do you generally work with, and what differences are notable between Linux and AIX when running mod_perl servers? (If that's not too long a piece of string to measure:). Are there situations where you'd prefer one or the other, if so why? 73, Ged.
Re: AIX perfomance
On Fri, 2003-09-12 at 09:35, Rafael Garcia-Suarez wrote: Benchmarking simple CPU-intensive perl scripts shows that they tend to be consistently slower in user time on AIX. Are these mod_perl scripts or just Perl? If you benchmark some simple Perl scripts that don't run under mod_perl and they show the same trend, then you can eliminate mod_perl as a possible source of the problem. You should also verify that your versions of Perl, apache, and mod_perl are exactly the same on both systems. - Perrin
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Randy Kobes wrote:
[ .. ]
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32
Your patch does the trick for me, except that I had to
rebuild mod_perl too.
The problem is that my installed mod_perl setup (Apache in
C:\apache, Perl in C:\perl5) didn't contain the
mod_perl.lib required. The MODPERL_LIB entry in
Apache::MyConfig said
C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is,
of course, where it was when I was building mod_perl.
I believe that mod_perl 2 now installs the mod_perl.lib
somewhere to solve that kind of problem. Is there an
option in the mod_perl 1 build process to thave that
library installed, or could that be added to the next
release?
That's a good suggestion - you're right that mod_perl 2
installs the mod_perl.lib under the Apache2/ tree, and it
would make sense for mod_perl 1 to do the same, with
Apache::MyConfig adjusted to reflect that. I'll look into
putting together something to do that.
Does it? According to Apache::Build, it should be installed under the apache
tree's lib:
sub modperl_libs_MSWin32 {
my $self = shift;
# mod_perl.lib will be installed into MP_AP_PREFIX/lib
# for use by 3rd party xs modules
$self-{cwd}/src/modules/perl/$self-{MP_LIBNAME}.lib;
}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... -- best regards, randy
Forking w/ mod_perl 2
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Forking w/ mod_perl 2
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 + threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.
signature.asc
Description: This is a digitally signed message part
RE: Forking w/ mod_perl 2
Hi Richard,
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of
code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 +
threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
Thanks for you reply. The report code is in another perl program that I'm
trying to execute. The code I included below was from the v1 docs:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
Here is the code I ended up with:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This seems to work and no zombies are floating around. But I've not been
able to restart Apache while the forked program is running yet to see if
it's killed.
More comments or ideas welcome.
Thanks,
Cameron
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
Hi all,
I have a report creation perl script that takes about 15
minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
-send_http_header(text/plain);
{CHLD} = 'IGNORE';
defined (my = fork) or die Cannot fork: \n;
if () {
print Parent 25481 has finished, kid's PID: \n;
} else {
-cleanup_for_exec(); # untie the socket
chdir '/'or die Can't chdir to /: ;
open STDIN, '/dev/null' or die Can't read /dev/null: ;
open STDOUT, '/dev/null'
or die Can't write to /dev/null: ;
open STDERR, '/tmp/log' or die Can't write to /tmp/log: ;
setsid or die Can't start a new session: ;
select STDERR;
local $| = 1;
warn started\n;
# do something time-consuming
sleep 1, warn sh\n for 1..20;
warn completed\n;
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain
those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.
WE: Apache::AuthCookie causing strange-Use of uninitialized value.
It is a warning Perl gives on strict, if variables have 0 values or are
NULL.
The example below will trigger that warning:
###
#!/usr/sbin/perl -w
use strict;
Xyz (fist_value, second_value); # Here we call sub xyz with 2 arguments
Sub xyz {
my ($x,$y,$z)@_;
print $x;
print $y;
print $z; # This will trigger the warning, because $z has no value.
}
To arrest the warning, I may use something like this:
Print $z if $z;
###
-Ursprüngliche Nachricht-
Von: Per Eric Rosén [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 12. September 2003 13:46
An: [EMAIL PROTECTED]
Betreff: Apache::AuthCookie causing strange-Use of uninitialized
value.
I use Apache::AuthCookie 3.04, which seems to be the latest version,
under
Apache/1.3.26 Ben-SSL/1.48 (Unix) Debian GNU/Linux PHP/4.1.2
mod_perl/1.26.
When I use PerlFixupHandler Apache::AuthCookie-recognize_user, Apache
writes Use of uninitialized value. in errorlog for each request and
subrequest. I have tried editing AuthCookie.pm, checking everything with
defined(), even substituting recognize_user with a stub function.
Still it is there. I am not sure it comes from perl, because perl use to
say at line X too. But from what else?
This has been up before, but no one answered it then:
http://www.jsw4.net/info/list-archives/mod_perl/02-08/msg00591.html
/Per Eric
--
^): Per Eric Rosén http://rosnix.nu/~per/
/ [EMAIL PROTECTED] GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311
mod_perl v2 Forking
Hi all...
Sorry about the previous message getting screwed up... Not sure what
happened...
I have a report generator program written in Perl that I need to start from
a CGI. The program takes about 15 minutes to run, so I must fork or double
fork. I have two goals:
1) Have no zombies when the program completes
2) Fork in such a way that restarting Apache doesn't kill the forked
process.
I tried out the code here which is for mod_perl v1:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
There are two problems with the code listed in the example:
1) Apache::SubProcess doesn't seem to contain the same methods as the older
version.
2) open isn't working. (I've already been down this road and switched
another call to an external program to use IPC::Run, but that program
doesn't take long and needs no fork.)
I took out the parts of the code that caused problems and ended up with
this:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This works and accomplishes my first goal, but not the second. If I start
the program and restart Apache, the program is killed.
Does anyone have ideas as to how to solve this?
Thanks,
Cameron
Re: mod_perl v2 Forking
I've been following this just at a high level, so if I'm posting a method
that you've already tried and dismissed please forgive me.
You can try forking followed by separating from the parent session. I
think that will help keep your program from getting killed when apache is
restarted or stopped.
use POSIX;
# FORK
$pid = fork;
if (not defined $pid) {
# unable to fork
} elsif ($pid) {
# parent to exit, child continue
exit 0;
}
# Separate from parent
$status = 0;
POSIX::setsid() or $status = Couldn't start new session: $!;
if ($status) {
# unable to separate from parent session
} else {
# searated from parent
$status = 0;
}
On Fri, 12 Sep 2003, Cameron B. Prince wrote:
Hi all...
Sorry about the previous message getting screwed up... Not sure what
happened...
I have a report generator program written in Perl that I need to start from
a CGI. The program takes about 15 minutes to run, so I must fork or double
fork. I have two goals:
1) Have no zombies when the program completes
2) Fork in such a way that restarting Apache doesn't kill the forked
process.
I tried out the code here which is for mod_perl v1:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
There are two problems with the code listed in the example:
1) Apache::SubProcess doesn't seem to contain the same methods as the older
version.
2) open isn't working. (I've already been down this road and switched
another call to an external program to use IPC::Run, but that program
doesn't take long and needs no fork.)
I took out the parts of the code that caused problems and ended up with
this:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die Cannot fork: $!\n;
unless ($pid) {
exec $command;
CORE::exit(0);
}
This works and accomplishes my first goal, but not the second. If I start
the program and restart Apache, the program is killed.
Does anyone have ideas as to how to solve this?
Thanks,
Cameron
Apache::Session permissions problem
I found a pretty useful article at
http://www.linuxjournal.com/article.php?sid=4143 on how to use
Apache::Session with Mason. I followed the article, more or less, and
ended up with this bit of code in my handler.pl to tie() my $session
variable to an Apache::Session class:
eval {
tie %HTML::Mason::Commands::session, 'Apache::Session::DBI',
($cookies{$session_cookie_name} ?
$cookies{$session_cookie_name}-value() : undef),
{
DataSource = $dbsource,
UserName = $dbuser,
Password = $dbpass
};
};
All the database variables are correct; I use them elsewhere with no
problem. The problem is that the session seems to be intermittent--
some pages seem to recognize it, others don't. This smelled a lot like
a problem where the session was getting set in one Apache instance and
not others, so I wondered if the session was getting stored in the
database correctly; after the previous eval, all I ever get in $@ is:
Permission denied at
/Library/Perl/Apache/Session/SysVSemaphoreLocker.pm line 46.
Which seems to indicate it isn't. I STFW, and found several people who
seem to have had the same problem I have, but the solutions proffered
involve ipcs and ipcrm, which don't exist on my Mac OS X 10.2.6 system.
Suggestions are more than welcome; I'm not quite sure how
Session::SysVSempaphoreLocker got involved in the first place, since I
don't explicitly reference it.
Mightily confused,
-=Eric
Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi, I posted this problem the other day, deep inside a thread about something else, and didn't get any replies; maybe nobody spotted it? Does anybody have Apache::Dispatch working on Windows with Perl 5.8.0? Randy? I'm trying to build it on Windows XP (MSVC++ 6) with Perl 5.8.0 / Apache 1.3.27 / mod_perl 1.28, but I get these errors: [...] link -out:blib\arch\auto\Apache\Dispatch\Dispatch.dll -dll -nologo -node faultlib -release -libpath:C:\perl5\lib\CORE -machine:x86 Dispatch.obj C:\ perl5\lib\CORE\perl58.lib libeay32.lib oldnames.lib kernel32.lib user32.lib gdi 32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.li b netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o dbccp32.lib msvcrt.lib -def:Dispatch.def Creating library blib\arch\auto\Apache\Dispatch\Dispatch.lib and object blib\ arch\auto\Apache\Dispatch\Dispatch.exp Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_merge_dir_co nfig Dispatch.obj : error LNK2001: unresolved external symbol _perl_cmd_perl_TAKE1 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_register_clea [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_cmd_cleanup Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_null_cleanup Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_clear_symtab Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_remove_module @4 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_find_linked_m [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_get_startup_pool Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] blib\arch\auto\Apache\Dispatch\Dispatch.dll : fatal error LNK1120: 11 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Any ideas? - Steve
