RE: Multiple authentication methods
At 17:21 13.02.2002 -0600, you wrote:
File::Spec is in included with the standard perl mods I believe
so dependencies shouldn't be a problem.
I see. You're right, this is actually much nicer!
Sorry for the misinformation. On debian it return : also. I made a
mistake checking it.
But with the suggested code by Per it works just fine:
sub load {
my $module=@_[0];
$module = File::Spec-catfile(split /::/, $module);
$module .= '.pm';
eval { require $module; };
return $@ ? 1 : 0;
}
Of course one has to put a use File::Spec at the beginning and a Per
Finar Ellefsen
That's Per Einar :)
I think this module is a great idea. You should get it on CPAN as soon as
possible.
--
Per Einar Ellefsen
[EMAIL PROTECTED]
Re: Custom Logging and User Tracking
At 15:22 13.02.2002 -0800, Ryan Parr wrote: Nothing special to the way these sites work. You can check out http://www.rileyjames.com and http://www.ryanparr.com (the programming on the latter will leave you in awe :) I want to host my sites and have a decent usage statistics location, but I just can't seem to get the logging part down. I've got a long road ahead of me :) For instance, the code below logs the following on entrance to rileyjames.com (setup as PerlFixupHandler): www.rileyjames.com / Wed Feb 13 16:17:15 2002 www.rileyjames.com /index.html Wed Feb 13 16:17:15 2002 www.rileyjames.com /topnavigation.htm Wed Feb 13 16:17:15 2002 www.rileyjames.com /white.htm Wed Feb 13 16:17:15 2002 www.rileyjames.com /green.htm Wed Feb 13 16:17:15 2002 www.rileyjames.com /index1.htm Wed Feb 13 16:17:15 2002 www.rileyjames.com /topnav.css Wed Feb 13 16:17:15 2002 www.rileyjames.com /graphics/redarrow.gif Wed Feb 13 16:17:15 2002 www.rileyjames.com /border.css Wed Feb 13 16:17:15 2002 www.rileyjames.com /text.css Wed Feb 13 16:17:15 2002 www.rileyjames.com /graphics/frontpaglogo.gif Wed Feb 13 16:17:15 2002 The problem you seem to be having is that: 1) The client is sent the main page as HTML (index.html) 2) As this file includes many references to other URLs, for images, CSS, frames, etc.., the client knows that it'll need these files, so sends out new requests for these files, many of them at the same time. 3) Apache processes these new requests, without knowing that they came from one other request. You're faced with one problem (and feature) of the HTTP protocol: it's stateless, so the httpd could not possibly know that any requests are linked. You have some ways of working around this, though. It's been tried over and over again, and as many people know, getting reliable statistics on visits (etc) is pretty hard. Here are some possible solutions: 1) as you're using frames on rileyjames.com, you could log only visits on /topnavigation.htm, which would be loaded only once. Of course, logging the number of visits is not really what you want. 2) Say that one IP can only be counted visiting when it visits within a certain amount of time: for example, all visits after the first one from a specific IP are ignored for 5 seconds.. One problem here is that: - IPs aren't reliable enough as a method (there is no IP-computer match, because of NAT and proxies) - You might not have reached the logging phase of the first page when the other pages are requested (although this is unlikely) 3) What I think is the best solution: declare only some pages as loggable. Either log only specific pages, say the HTML files of your choice and some big pictures, *or* add a query string to the pages you want logged/don't want logged... Say: /graphics/frontpaglogo.gif?log=yes would still get you the image, but you can get the query string in the logger, and check whether to log or not. There are probably many other solutions... But just remember that while the line return DECLINED unless($r-is_main()); is useful for subrequests, it won't help you a bit in your situation here, because of the fact that the requests you're seeing are indeed separate. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Multiple authentication methods
Hi Darren Would you submit the current version? If you need help with the Documentation just let me know. For the makefile, I do not have any experience. Marcel Am Mittwoch den, 13. Februar 2002, um 21:01, schrieb darren chamberlain: Quoting Marcel Weber [EMAIL PROTECTED] [13 Feb-02 14:53]: Why not submitting this somewhere? I think this could be usefull for quite a lot of people. I think this is cool, as you do not have to worry wether the module returns DECLINED or AUTH_REQUIRED. I can package this up and put it on CPAN as version 0.01 tomorrow morning, if that seems reasonable to everyone involved. I'll need to add some docs and a Makefile.PL, of course. (darren) -- To believe is very dull. To doubt is intensely engrossing. To be on alert is to live, to be lulled into security is to die. -- Oscar Wilde --- PGP / GPG Key: http://www.ncpro.com/GPG/mmweber-at-ncpro-com.asc
How to step over the STDIN, while input redirection is not given at commandline
Hello Gurus,
Source code: of printFile.pl
# File: printFile.pl ##
#! /usr/bin/perl -w
my (@data, $user);
# Input rediretion file
$user = (defined @ARGV) ? shift @ARGV : Anonymous;
# I don't wish to prompt by program, but it's still waiting how to Step Over
here
@data = STDIN if ( defined STDIN);
die perl $0 data.txt if (@data);
print User: $user \n;
foreach (@data){
print $_;
}
1;
### EOF #
I have a perl scripts, which expects the input file as redirection at
command line.
i.e.,
[user3@Linux] # perl printFile.pl data.txt
= This will display the inputed file content, if file name is piped as
redirection.
= Otherwise, program will wait to accept the file.
= So, I don't want program prompt for the file name,
= I would like to check the file name is given or not.
= But, becuase of STDIN statement in program to dump the content of the
file into Array, will cause to wait ifdata.txt is missing at command
line.
= It's very easy, if @ARGV checking, will have the command line parameters.
But, it 's not in command line paramenters list.
= It is input redirection.
= How to check the input direction is given or not in perl, @ = STDIN;
= like @ = STDIN if ( defined STDIN ); But this will not full fill
the requirement, because, it's prompting
for input, if redirection missing at commandline.
Please, kindly give me suggestions to proceed.
Thanks in advance.
Regards,
~ SubbaReddy .M
Sr. Programmer, Frontlinesoft, Hyderabad
http://www.frontlinesoft.com
Ph: 91-40-3392147, 3391683 (O)
91-40-3307980 ( R)
w3page: http://www.geocities.com/msubbareddy/
ICQ: 56093095
Re: Cookie as session store
Jeffrey - interesting point! What did you have in mind to encrypt the cookie data? Perhaps you could use Storable to serialize data structure then convert, crypt to scramble and then MIME64 to text encode? I agree with you on processing delays - that is probably the biggest drawback to needing to send cookies as part of response header. Using Template Toolkit a lot myself, I have to make a workaround to handle the cookie situation as well. I've got a tied interface to Apache::Cookie's mostly completed - it would be easy to add the encryption that you describe above to them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie. Featuring tied interface and lazy (demand) loading of cookie data. Jay - Original Message - From: Jeffrey W. Baker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 13, 2002 3:00 PM Subject: Cookie as session store I have sometimes proposed or recommended schemes of storing session information in an HTTP cookie, encoded and protected by cryptographic digest. I know some people on this list have implemented similar schemes, but I have never actually had occasion to do so. Now I am doing that, and I realize the chief drawback to this scheme: all session information has to be set before generating any HTML output. The chief advantage is no requirement for server-side storage of session. For certain applications, saving all output until the session is serialized may significantly increase the latency of the first data packet in the HTTP response. -jwb
Re: How to step over the STDIN, while input redirection is not given at commandline
On Thu, Feb 14, 2002 at 03:34:56PM +0530, SubbaReddy M wrote:
= How to check the input direction is given or not in perl, @ = STDIN;
= like @ = STDIN if ( defined STDIN ); But this will not full fill
the requirement, because, it's prompting
for input, if redirection missing at commandline.
#!/usr/bin/perl
unless (-t STDIN) {
@a = STDIN;
} else {
print No file\n;
}
HTH!
--
Dan Boger
Linux MVP
brainbench.com
mod_perl compile problem
Hi: I'm attempting to make httpd apache-1.3.23 with mod_perl-1.26 and ActiveState Perl 5.6.1 Build 631. This is a simple build with no other modules or EAPI references. Unfortunately, I'm encountering the following error when the compile of the http_core.c routine is attempted: gcc -c -I.. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/CO RE -I../os/unix -I../include -DLINUX=22 - I/usr/include/db1 -DDEV_RANDOM=/dev/random -DMOD_PERL -DUSE_PERL_SSI -DUSE_R EENTRANT_API -D_POSIX_C_SOURCE=199506L - _REENTRANT -fno-strict-aliasing -DUSE_HSREGEX -D_XOPEN_SOURCE -DUSE_REENTRA NT_API -D_POSIX_C_SOURCE=199506L - D_REENTRANT -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL http_core.c http_core.c: In function `default_handler': http_core.c:3775: `caddr_t' undeclared (first use in this function) http_core.c:3775: (Each undeclared identifier is reported only once http_core.c:3775: for each function it appears in.) http_core.c:3775: parse error before mm http_core.c:3839: `mm' undeclared (first use in this function) make[2]: *** [http_core.o] Error 1 make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/dist/apache_1.3.23/src' make: *** [apache_httpd] Error 2 I was told that building ActiveState from source versus using the RPM would fix the problem but, this did not work. Any suggestions? Below is the entire mod_perl build session: Thanks, RB === mod_perl BUILD SESSION === perl Makefile.PL Configure mod_perl with ../src ? [y] Shall I build httpd in ../src for you? [y] Appending mod_perl to src/Configuration Using config file: /usr/dist/apache_1.3.23/mod_perl-1.26/src/Configuration Creating Makefile + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End + using -lndbm for DBM support enabling DBM support for mod_rewrite o db_auth_module uses ConfigStart/End using Berkeley-DB/3.x for mod_auth_db (-ldb) o digest_auth_module uses ConfigStart/End using /dev/random for the random seed o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/v5.6.1 (linux) [perl] Note (probably harmless): No library found for -lposix + adjusting Apache build environment + enabling Perl support for SSI (mod_include) + using system Expat + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in modules/standard Creating Makefile in modules/experimental Creating Makefile in modules/proxy Creating Makefile in modules/example Creating Makefile in modules/perl EXTRA_CFLAGS: -DLINUX=22 -I/usr/include/db1 -DDEV_RANDOM=/dev/random -DMOD_P ERL -DUSE_PERL_SSI -DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_REENTRAN T -fno-strict-aliasing -DUSE_HSREGEX PerlDispatchHandler.disabled (enable with PERL_DISPATCH=1) PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..disabled (enable with PERL_POST_READ_REQUEST=1) PerlTransHandlerdisabled (enable with PERL_TRANS=1) PerlHeaderParserHandler.disabled (enable with PERL_HEADER_PARSER=1) PerlAccessHandler...disabled (enable with PERL_ACCESS=1) PerlAuthenHandler...disabled (enable with PERL_AUTHEN=1) PerlAuthzHandlerdisabled (enable with PERL_AUTHZ=1) PerlTypeHandler.disabled (enable with PERL_TYPE=1) PerlFixupHandlerdisabled (enable with PERL_FIXUP=1) PerlHandler.enabled PerlLogHandler..disabled (enable with PERL_LOG=1) PerlInitHandler.disabled (enable with PERL_INIT=1) PerlCleanupHandler..disabled (enable with PERL_CLEANUP=1) PerlRestartHandler..disabled (enable with PERL_RESTART=1) PerlStackedHandlers.disabled (enable with PERL_STACKED_HANDLERS=1) PerlMethodHandlers..disabled (enable with PERL_METHOD_HANDLERS=1) PerlDirectiveHandlers...disabled (enable with PERL_DIRECTIVE_HANDLERS=1) PerlTableApidisabled (enable with PERL_TABLE_API=1) PerlLogApi..disabled (enable with PERL_LOG_API=1) PerlUriApi..disabled (enable with PERL_URI_API=1) PerlUtilApi.disabled (enable with PERL_UTIL_API=1) PerlFileApi.disabled (enable with PERL_FILE_API=1) PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsdisabled (enable with PERL_SECTIONS=1) PerlSSI.disabled (enable with PERL_SSI=1) Will run tests as User: 'nobody' Group: 'root'
Re: mod_perl compile problem
On Thu, 14 Feb 2002, OCNS Consulting wrote: I'm attempting to make httpd apache-1.3.23 with mod_perl-1.26 and ActiveState Perl 5.6.1 Build 631. This is a simple build with no other modules or EAPI references. Unfortunately, I'm encountering the following error when the compile of the http_core.c routine is attempted: http_core.c: In function `default_handler': http_core.c:3775: `caddr_t' undeclared (first use in this function) [ ... ] Can you compile apache separately OK, not through mod_perl? If so, you might try compiling mod_perl the flexible way described in INSTALL.apaci in the mod_perl sources. best regards, randy kobes
Re: Cookie as session store
On Thu, 2002-02-14 at 06:17, Jay Lawrence wrote:
Jeffrey - interesting point!
What did you have in mind to encrypt the cookie data? Perhaps you could use
Storable to serialize data structure then convert, crypt to scramble and
then MIME64 to text encode?
I am not encrypting the session data in this system, because the
contents are not sensitive. I base64 encode a gzipped Storable-frozen
object, which contains another Storable-frozen object and the SHA1
digest of itself.
When the cookie is recovered, I simply decode, uncompress, thaw, check
the digest, and thaw the inner object. The code is simple:
sub realize_session {
my ($foo) = @_;
my ($i, $s);
$i = thaw(uncompress(decode_base64($foo)));
if (sha1_hex($i-{content} . BIG_SECRET) eq $i-{hash}) {
$s = thaw($i-{content});
return $s;
}
return undef;
}
sub serialize_session {
my ($s) = @_;
my ($i, $frz, $foo);
$frz = nfreeze($s);
$i = {
content = $frz
, hash= sha1_hex($frz . BIG_SECRET)
};
$foo = encode_base64(compress(nfreeze($i)));
return $foo;
}
It's fortunate that all of these functions are fast. Base64, Zlib,
Storable, and SHA1 are all implemented in C.
I agree with you on processing delays - that is probably the biggest
drawback to needing to send cookies as part
of response header. Using Template Toolkit a lot myself, I have to make a
workaround to handle the cookie situation
as well.
My strategy for document generation is to build a DOM tree and then
create the output by serializing the DOM to XML or HTML. So, it is
natural in this application to just set everything up before sending the
response. But I can imagine that if you wanted an intermediate page,
progress indications, and so forth you might have to jump through hoops.
I've got a tied interface to Apache::Cookie's mostly completed - it would be
easy to add the encryption that you describe above to
them. See: http://www.infonium.com/perl/ for a link to Apache::Tie::Cookie.
Featuring tied interface and lazy (demand) loading of cookie data.
Thanks!
-jwb
Re: Cookie as session store
When the cookie is recovered, I simply decode, uncompress, thaw, check the digest, and thaw the inner object. It's really a good idea to do this even when the cookie is nothing but a session ID. A standard module for this like the one Jay mentioned would definitely be nice. My strategy for document generation is to build a DOM tree and then create the output by serializing the DOM to XML or HTML. So, it is natural in this application to just set everything up before sending the response. Since I usually structure my applications to do all the work and then pass some data to a template, they also follow this order. The main problem I see with sending some HTML before the work is complete is that if something goes wrong later on you have no way to send a nice error page out. I sometimes see people having this problem on sites I visit: I get an OK response and some HTML and then a second set of headers with an error code and it looks like garbage in a browser. - Perrin
RE: mod_perl compile problem
Randy, Unfortunately, the same results were yielded using the flexible way. Below is the perl Makefile.PL, make Build session. I look forward to your response. RB == Build Session == [mod_perl-1.26]# perl Makefile.PL APACHE_SRC=/dist/apache_1.3.23/src DO_HTTPD=1 USE_ACAPI=1 PREP_HTTPD=1 EVERYTHING=1 Appending mod_perl to src/Configuration Using config file: /usr/dist/apache_1.3.23/mod_perl-1.26/src/Configuration Creating Makefile + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End + using -lndbm for DBM support enabling DBM support for mod_rewrite o db_auth_module uses ConfigStart/End using Berkeley-DB/3.x for mod_auth_db (-ldb) o digest_auth_module uses ConfigStart/End using /dev/random for the random seed o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/v5.6.1 (linux) [perl] Note (probably harmless): No library found for -lposix + adjusting Apache build environment + enabling Perl support for SSI (mod_include) + using system Expat + checking sizeof various data types + doing sanity check on compiler and options Creating Makefile in support Creating Makefile in regex Creating Makefile in os/unix Creating Makefile in ap Creating Makefile in main Creating Makefile in modules/standard Creating Makefile in modules/experimental Creating Makefile in modules/proxy Creating Makefile in modules/example Creating Makefile in modules/perl EXTRA_CFLAGS: -DLINUX=22 -I/usr/include/db1 -DDEV_RANDOM=/dev/random -DMOD_P ERL -DUSE_PERL_SSI -DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_REENTRAN T -fno-strict-aliasing -DUSE_HSREGEX PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'nobody' Group: 'root' Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Checking if your kit is complete... Looks good 'USE_ACAPI' is not a known MakeMaker parameter name. Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl [root@posiden mod_perl-1.26]# make (cd /dist/apache_1.3.23/src PERL5LIB=/usr/dist/apache_1.3.23/mod_perl-1.26/lib make CC=gcc;) make[1]: Entering directory `/usr/dist/apache_1.3.23/src' === regex make[2]: Nothing to be done for `all'. === regex === os/unix gcc -c -I../.. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi /CORE -I../../os/unix -I../../include -DLINUX=22 -I/usr/include/db1 -DDEV_ RANDOM=/dev/random -DMOD_PERL -DUSE_PERL_SSI -DUSE_REENTRANT_API -D_POSIX_C_ SOURCE=199506L -D_REENTRANT -fno-strict-aliasing -DUSE_HSREGEX -DUSE_REENTR ANT_API -D_POSIX_C_SOURCE=199506L -D_REENTRANT -fno-strict-aliasing -D_LARGE FILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/ActivePerl-5.6/lib/5.6.1/i68 6-linux-thread-multi/CORE -I. -I../.. -DUSE_PERL_SSI -DUSE_REENTRANT_API -D _POSIX_C_SOURCE=199506L -D_REENTRANT -fno-strict-aliasing -D_LARGEFILE_SOURC E -D_FILE_OFFSET_BITS=64 -DMOD_PERL os.c In file included from /usr/include/sys/sem.h:28, from ../../include/ap_config.h:495, from os.c:6: /usr/include/sys/ipc.h:25:3: warning: #warning Files using this header must be compiled with _SVID_SOURCE or _XOPEN_SOURCE gcc -c -I../.. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi /CORE -I../../os/unix -I../../include -DLINUX=22 -I/usr/include/db1
Re: mod_perl compile problem
OCNS Consulting [EMAIL PROTECTED] on Feb 14, 2002: [mod_perl-1.26]# perl Makefile.PL APACHE_SRC=/dist/apache_1.3.23/src DO_HTTPD=1 USE_ACAPI=1 PREP_HTTPD=1 EVERYTHING=1 ^ Make that USE_APACI=1 Now, I may be missing something and somebody already asked you earlier about this: You are using ActiveState Perl on Linux? I always thought ActiveState Perl is for Windows boxen. No? Hans
RE: mod_perl compile problem
Hans: Thanks for the TYPO catch. Yes ActiveState Perl is available for Linux. See: - RPM - http://downloads.activestate.com/ActivePerl/Linux/5.6/ActivePerl-5.6.1.631-i 686-linux.rpm Once again, I performed the flexible way Build method, creating the libperl.a ar library. I then changed to the Apache Home Directory and performed the configure and make but the original problem returns. Below is the Apache Build Session. Thanks, RB === Apache Build Session with libperl.a module === [apache_1.3.23]#env SSL_BASE=/dist/openssl-0.9.6c EAPI_MM=SYSTEM LIBS=-ltcl8.3 -lm ./configure --verbose --enable-rule=EAPI --enable-module=status --enable-mod ule=so --enable-module=ssl --enable-module=headers --enable-module=info --en able-module=speling --activate-module=src/modules/php4/libphp4.a --activate- module=src/modules/extra/mod_auth_pam.o --activate-module=src/modules/mod_dt cl/mod_dtcl.a --activate-module=src/modules/perl/libperl.a Configuring for Apache, Version 1.3.23 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) + activated auth_pam module (modules/extra/mod_auth_pam.o) + activated dtcl module (modules/mod_dtcl/mod_dtcl.a) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src + Rule SSL_COMPAT=yes + Rule SSL_SDBM=default + Rule SSL_EXPERIMENTAL=no + Rule SSL_CONSERVATIVE=no + Rule SSL_VENDOR=no + Rule EAPI=yes + Rule SHARED_CORE=default + Rule SHARED_CHAIN=default + Rule SOCKS4=no + Rule SOCKS5=no + Rule IRIXNIS=no + Rule IRIXN32=yes + Rule PARANOID=no + Rule EXPAT=default + Rule CYGWIN_WINSOCK=no + Rule DEV_RANDOM=default + Rule WANTHSREGEX=default + Module mmap_static: no + Module vhost_alias: no + Module env: yes + Module define: no + Module log_config: yes + Module log_agent: no + Module log_referer: no + Module mime_magic: no + Module mime: yes + Module negotiation: yes + Module status: yes + Module info: yes + Module include: yes + Module autoindex: yes + Module dir: yes + Module cgi: yes + Module asis: yes + Module imap: yes + Module actions: yes + Module speling: yes + Module userdir: yes + Module alias: yes + Module rewrite: no + Module access: yes + Module auth: yes + Module auth_anon: no + Module auth_dbm: no + Module auth_db: no + Module digest: no + Module auth_digest: no + Module proxy: no + Module cern_meta: no + Module expires: no + Module headers: yes + Module usertrack: no + Module example: no + Module unique_id: no + Module so: yes + Module setenvif: yes + Module ssl: yes + Module php4: yes + Module auth_pam: yes + Module dtcl: yes + Module perl: yes + id: mod_perl/1.26 + id: Perl/v5.6.1 (linux) [perl] Note (probably harmless): No library found for -lposix cd ..; gcc -DLINUX=22 -DMOD_SSL=208106 -I/dist/php-4.1.1 -I/dist/php-4.1.1/main -I /dist/php-4.1.1/main -I/dist/php-4.1.1/Zend -I/dist/php-4.1.1/Zend -I/dist/p hp-4.1.1/TSRM -I/dist/php-4.1.1/TSRM -I/dist/php-4.1.1 -DMOD_PERL -DUSE_PERL _SSI -DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_REENTRANT -fno-strict- aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEAPI -DEAPI_MM `./apaci` -I. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/ CORE -I/usr/local/include -L/dist/openssl-0.9.6c -L/usr/local/lib -o helpers/dummy helpers/dummy.c -ltcl8.3 -lm -Wl,-rpath,/usr/local/BerkeleyDB.3.3/lib -rdy namic -L/usr/local/BerkeleyDB.3.3/lib -Lmodules/php4 -L../modules/php4 -L../ ../modules/php4 -lmodphp4 -lpam -ldl -ldb -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -lm -lcrypt -lssl -lcrypto -rdynamic -L/usr/local/lib /usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/auto/DynaLoader/ DynaLoader.a -L/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/C ORE -lperl -lnsl -ldl -lm -lpthread -lc -lcrypt -lutil -lmm -lexpat Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o ssl_module uses ConfigStart/End + SSL interface: mod_ssl/2.8.6 + SSL interface build type: OBJ + SSL interface compatibility: enabled + SSL interface experimental code: disabled + SSL interface conservative code: disabled + SSL interface vendor extensions: disabled + SSL interface plugin: Built-in SDBM + SSL library path: /dist/openssl-0.9.6c + SSL library version: OpenSSL 0.9.6c 21 dec 2001 + SSL library type: source tree only (stand-alone) o php4_module uses ConfigStart/End o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + adjusting Apache build environment + enabling Perl support for SSI (mod_include) + enabling Extended API (EAPI) using MM library for EAPI:
RE: mod_perl compile problem
Kevin, Configured Apache with --enable-rule=SHARED_CORE; make - same results. RB -Original Message- From: Cheung, Kevin [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 11:47 AM To: 'OCNS Consulting' Subject: RE: mod_perl compile problem did you try --enable-rule=SHARED_CORE to see if that helps? -Original Message- From: OCNS Consulting [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 04:48 To: Hans Juergen von Lengerke Cc: Randy Kobes; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: mod_perl compile problem Hans: Thanks for the TYPO catch. Yes ActiveState Perl is available for Linux. See: - RPM - http://downloads.activestate.com/ActivePerl/Linux/5.6/ActivePe rl-5.6.1.631-i 686-linux.rpm Once again, I performed the flexible way Build method, creating the libperl.a ar library. I then changed to the Apache Home Directory and performed the configure and make but the original problem returns. Below is the Apache Build Session. Thanks, RB === Apache Build Session with libperl.a module === [apache_1.3.23]#env SSL_BASE=/dist/openssl-0.9.6c EAPI_MM=SYSTEM LIBS=-ltcl8.3 -lm ./configure --verbose --enable-rule=EAPI --enable-module=status --enable-mod ule=so --enable-module=ssl --enable-module=headers --enable-module=info --en able-module=speling --activate-module=src/modules/php4/libphp4.a --activate- module=src/modules/extra/mod_auth_pam.o --activate-module=src/modules/mod_dt cl/mod_dtcl.a --activate-module=src/modules/perl/libperl.a Configuring for Apache, Version 1.3.23 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) + activated auth_pam module (modules/extra/mod_auth_pam.o) + activated dtcl module (modules/mod_dtcl/mod_dtcl.a) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src + Rule SSL_COMPAT=yes + Rule SSL_SDBM=default + Rule SSL_EXPERIMENTAL=no + Rule SSL_CONSERVATIVE=no + Rule SSL_VENDOR=no + Rule EAPI=yes + Rule SHARED_CORE=default + Rule SHARED_CHAIN=default + Rule SOCKS4=no + Rule SOCKS5=no + Rule IRIXNIS=no + Rule IRIXN32=yes + Rule PARANOID=no + Rule EXPAT=default + Rule CYGWIN_WINSOCK=no + Rule DEV_RANDOM=default + Rule WANTHSREGEX=default + Module mmap_static: no + Module vhost_alias: no + Module env: yes + Module define: no + Module log_config: yes + Module log_agent: no + Module log_referer: no + Module mime_magic: no + Module mime: yes + Module negotiation: yes + Module status: yes + Module info: yes + Module include: yes + Module autoindex: yes + Module dir: yes + Module cgi: yes + Module asis: yes + Module imap: yes + Module actions: yes + Module speling: yes + Module userdir: yes + Module alias: yes + Module rewrite: no + Module access: yes + Module auth: yes + Module auth_anon: no + Module auth_dbm: no + Module auth_db: no + Module digest: no + Module auth_digest: no + Module proxy: no + Module cern_meta: no + Module expires: no + Module headers: yes + Module usertrack: no + Module example: no + Module unique_id: no + Module so: yes + Module setenvif: yes + Module ssl: yes + Module php4: yes + Module auth_pam: yes + Module dtcl: yes + Module perl: yes + id: mod_perl/1.26 + id: Perl/v5.6.1 (linux) [perl] Note (probably harmless): No library found for -lposix cd ..; gcc -DLINUX=22 -DMOD_SSL=208106 -I/dist/php-4.1.1 -I/dist/php-4.1.1/main -I /dist/php-4.1.1/main -I/dist/php-4.1.1/Zend -I/dist/php-4.1.1/Zend -I/dist/p hp-4.1.1/TSRM -I/dist/php-4.1.1/TSRM -I/dist/php-4.1.1 -DMOD_PERL -DUSE_PERL _SSI -DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_REENTRANT -fno-strict- aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEAPI -DEAPI_MM `./apaci` -I. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/ CORE -I/usr/local/include -L/dist/openssl-0.9.6c -L/usr/local/lib -o helpers/dummy helpers/dummy.c -ltcl8.3 -lm -Wl,-rpath,/usr/local/BerkeleyDB.3.3/lib -rdy namic -L/usr/local/BerkeleyDB.3.3/lib -Lmodules/php4 -L../modules/php4 -L../ ../modules/php4 -lmodphp4 -lpam -ldl -ldb -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -lm -lcrypt -lssl -lcrypto -rdynamic -L/usr/local/lib /usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/au to/DynaLoader/ DynaLoader.a -L/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/C ORE -lperl -lnsl -ldl -lm -lpthread -lc -lcrypt -lutil -lmm -lexpat Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o ssl_module uses ConfigStart/End + SSL interface: mod_ssl/2.8.6 + SSL interface
[upload@p11.speed-link.de: CPAN Upload: D/DA/DARREN/Apache-MultiAuth-0.04.tar.gz]
- Forwarded message from PAUSE [EMAIL PROTECTED] - Date: Thu, 14 Feb 2002 19:13:11 +0100 Reply-To: [EMAIL PROTECTED] Subject: CPAN Upload: D/DA/DARREN/Apache-MultiAuth-0.04.tar.gz From: PAUSE [EMAIL PROTECTED] To: Darren Chamberlain [EMAIL PROTECTED], [EMAIL PROTECTED] The uploaded file Apache-MultiAuth-0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DA/DARREN/Apache-MultiAuth-0.04.tar.gz size: 2514 bytes md5: 8c703e8ac418ff46886220a52153b079 No action is required on your part Request entered by: DARREN (Darren Chamberlain) Request entered on: Thu, 14 Feb 2002 18:11:49 GMT Request completed: Thu, 14 Feb 2002 18:13:11 GMT Virtually Yours, Id: paused,v 1.74 2001/05/20 14:59:52 k Exp k - End forwarded message - -- Everybody wants to go to heaven, but nobody wants to die. -- Peter Tosh
inheritance and Apache::Request
I am slowly learning about OO from Tom's tutorial, and was able to do inheritance with
two dummy classes I wrote, including adding methods to the subclass and have them work
too. However, when I tried to inherit from Apache::Request, it doesn't seem to work
right. Maybe this isn't an Apache::Request issue, so forgive me if that's the case,
but here's what I got:
FooBar.pm
-
package FooBar;
use strict;
use Apache::Request();
@FooBar::ISA = qw(Apache::Request);
sub fooey {
print hello world, I'm in FooBar;
}
-
Handler.pm
-
sub handler {
my $r = shift;
$r-send_http_header('text/html');
my $form = FooBar-new($r);
$form-fooey;
$r-exit(OK);
}
Here's the error I get:
[Thu Feb 14 12:35:14 2002] [error] Can't locate object method fooey via package
Apache::Request (perhaps you forgot to load Apache::Request?) at
/path/modified/Handler.pm line 21.
Re: inheritance and Apache::Request
Alex Porras wrote: I am slowly learning about OO from Tom's tutorial, and was able to do inheritance with two dummy classes I wrote, including adding methods to the subclass and have them work too. However, when I tried to inherit from Apache::Request, it doesn't seem to work right. Maybe this isn't an Apache::Request issue, so forgive me if that's the case, but here's what I got: we have a few examples of how to subclass Apache::Request... http://www.modperlcookbook.org/code/ch10/Cookbook/TransformRequest.pm http://www.modperlcookbook.org/code/ch13/Cookbook/CookieAuthentication.pm unfortunately, the explanations are not online. recipe 10.8 talks about this in a fair amount of detail... --Geoff
Re: inheritance and Apache::Request
Hi Alex,
The problem is that package FooBar doesn't have a new method. Here's what
happened as a result.
When you called 'FooBar-new($r), perl looked for a sub called new in package
FooBar. Since it didn't find one, it looked at FooBar's @ISA, and looked in
Apache::Request for a new method. There it presumably found one, so that
statement didn't return an error. But, the new() in Apache::Request probably
returned an Apache::Request object instead of a FooBar object, so when you
called $form-fooey, it only looked in Apache::Request and any modules in it's
@ISA.
You might want to look at using the universal isa and can methods while
you're debugging and trying stuff out. Good luck!
Wes Sheldahl
Alex Porras [EMAIL PROTECTED] on 02/14/2002 01:44:20 PM
To: mod perl list [EMAIL PROTECTED]
cc:(bcc: Wesley Sheldahl/Lex/Lexmark)
Subject: inheritance and Apache::Request
I am slowly learning about OO from Tom's tutorial, and was able to do
inheritance with two dummy classes I wrote, including adding methods to the
subclass and have them work too. However, when I tried to inherit from
Apache::Request, it doesn't seem to work right. Maybe this isn't an
Apache::Request issue, so forgive me if that's the case, but here's what I got:
FooBar.pm
-
package FooBar;
use strict;
use Apache::Request();
@FooBar::ISA = qw(Apache::Request);
sub fooey {
print hello world, I'm in FooBar;
}
-
Handler.pm
-
sub handler {
my $r = shift;
$r-send_http_header('text/html');
my $form = FooBar-new($r);
$form-fooey;
$r-exit(OK);
}
Here's the error I get:
[Thu Feb 14 12:35:14 2002] [error] Can't locate object method fooey via
package Apache::Request (perhaps you forgot to load Apache::Request?) at
/path/modified/Handler.pm line 21.
Re: FW: mod_perl compile problem
Hi there, On Thu, 14 Feb 2002, IEEE Consulting wrote: Any other thoughts on this issue? I really would like to use mod_perl. What's your Linux installation? You _have_ got the Linux sources and things like that installed? 73, Ged. PS: you don't need to circulate to the dev list.
RE: FW: mod_perl compile problem
Ged, The Server is installed with Redhat Linux 7.2 with latest the kernel sources. Here's the output from #rpm -q -a | grep kernel kernel-doc-2.4.9-21 kernel-source-2.4.9-21 kernel-pcmcia-cs-3.1.27-10 kernel-2.4.7-10 kernel-headers-2.4.9-21 kernel-2.4.9-21 What else can I check? RB -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 1:59 PM To: IEEE Consulting Cc: mod_perl Mailing List Subject: Re: FW: mod_perl compile problem Hi there, On Thu, 14 Feb 2002, IEEE Consulting wrote: Any other thoughts on this issue? I really would like to use mod_perl. What's your Linux installation? You _have_ got the Linux sources and things like that installed? 73, Ged. PS: you don't need to circulate to the dev list.
Re: Cookie as session store
Perrin Harkins wrote: When the cookie is recovered, I simply decode, uncompress, thaw, check the digest, and thaw the inner object. It's really a good idea to do this even when the cookie is nothing but a session ID. A standard module for this like the one Jay mentioned would definitely be nice. I dunno... That sounds lie a LOT of overhead for just a session ID that's gonna result in server lookups too... Issac
Re: Cookie as session store
I dunno... That sounds lie a LOT of overhead for just a session ID that's gonna result in server lookups too... It's really not. It adds a negligeble amount of time to the request. As Jeffrey pointed out, the functions he's using are all in C and very fast. Why verify session IDs? To make it hard to hijack sessions. This way it isn't enough to just guess someone else's session ID: you also have to know how to generate the proper digest for it. This is also useful to prevent people from screwing up your stats with bogus IDs. Many people log the session ID for use in calculating people's path through the site and similar things. Often this is done for pages that don't actually retrieve the session data from the backend store. Being able to verify that you have a valid session without hitting your data store can be very useful. - Perrin
RE: FW: mod_perl compile problem
Hi there, On Thu, 14 Feb 2002, OCNS Consulting wrote: The Server is installed with Redhat Linux 7.2 with latest the kernel Sorry if this has been covered, I haven't read all the thread: did you get the sources for Perl, Apache and mod_perl as tarballs or did you use RPMs? If you used RPMS I'd say 1. Grab the .tar.gz files for each - I'd suggest Perl 5.6.1, or 5.7.2 if you like to live a fuller life. 2. Create a directory /home/src (or something like that) 3. Unpack the lot in there, i.e. $ cd ~/src $ tar xzf perl... $ tar xzf apache-1.3.23.tar.gz $ tar xzf mod_perl-1.26.tar.gz $ cd perl... $ ./configure $ make $ make test $ su # make install # exit $ cd ~/src/mod_perl... etc etc, don't forget to su each time to 'make install' and don't forget to exit from the root shell each time afterwards. If that doesn't do it then we'll have to think again. 73, Ged.
RE: mod_perl compile problem
Ged, Yes, I have installed all three (Apache 1.3.23, Perl 5.6.1, mod_perl 1.2.6) from the tarball sources, tried to build and received the same results. I haven't tried Perl 5.7.2. Now, because the same result was yielded, I revert back to the ActiveState rpm version 5.6.1 Build 631. Do you believe that the version of PERL or APACHE has something to do with it? Thanks for the help - this is so frustrating. RB -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 2:16 PM To: OCNS Consulting Cc: mod_perl Mailing List Subject: RE: FW: mod_perl compile problem Hi there, On Thu, 14 Feb 2002, OCNS Consulting wrote: The Server is installed with Redhat Linux 7.2 with latest the kernel Sorry if this has been covered, I haven't read all the thread: did you get the sources for Perl, Apache and mod_perl as tarballs or did you use RPMs? If you used RPMS I'd say 1. Grab the .tar.gz files for each - I'd suggest Perl 5.6.1, or 5.7.2 if you like to live a fuller life. 2. Create a directory /home/src (or something like that) 3. Unpack the lot in there, i.e. $ cd ~/src $ tar xzf perl... $ tar xzf apache-1.3.23.tar.gz $ tar xzf mod_perl-1.26.tar.gz $ cd perl... $ ./configure $ make $ make test $ su # make install # exit $ cd ~/src/mod_perl... etc etc, don't forget to su each time to 'make install' and don't forget to exit from the root shell each time afterwards. If that doesn't do it then we'll have to think again. 73, Ged.
RE: inheritance and Apache::Request
Ok, that makes sense. But the reason I didn't include a new method for FooBar was because I don't know what A::R's new method does, so I didn't want to override it. What if it does some init stuff to the object? I'm assuming that's what's happening because, after adding a new method to FooBar, when I try to call $foobar-param (which I have not overridden), the child process segfaults. Oh well, I guess at this point I need to go back to reading more on perl OO since it's not sinking. Thanks for your help! --Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] The problem is that package FooBar doesn't have a new method. Here's what happened as a result. When you called 'FooBar-new($r), perl looked for a sub called new in package FooBar. Since it didn't find one, it looked at FooBar's @ISA, and looked in Apache::Request for a new method. There it presumably found one, so that statement didn't return an error. But, the new() in Apache::Request probably returned an Apache::Request object instead of a FooBar object, so when you called $form-fooey, it only looked in Apache::Request and any modules in it's @ISA. You might want to look at using the universal isa and can methods while you're debugging and trying stuff out. Good luck! Wes Sheldahl
mod_perl, mod_gzip, incredible suckage
Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? I installed it on a Slackware machine using the source code and apxs. It loads but segfaults on every request. I installed it on a Debian machine via apt-get and it segfaults at startup. Seems like a nasty hack. -jwb
Re: inheritance and Apache::Request
On Thu, Feb 14, 2002 at 01:55:34PM -0600, Alex Porras wrote:
Ok, that makes sense. But the reason I didn't include a new
method for FooBar was because I don't know what A::R's new method
does, so I didn't want to override it. What if it does some init
stuff to the object? I'm assuming that's what's happening because,
after adding a new method to FooBar, when I try to call
$foobar-param (which I have not overridden), the child process
segfaults. Oh well, I guess at this point I need to go back to
reading more on perl OO since it's not sinking.
I believe that Apache::Request doesn't really do inheritence properly.
If you look you'll see that the new() method is written in C. It
should be blessing itself into the passed in class, not using
Apache::Request. My XS is a little foggy, but it appears that these
lines should be modified to use the passed in class:
CLEANUP:
apreq_add_magic(ST(0), robj, RETVAL);
which ends up as:
ST(0) = sv_newmortal();
sv_setref_pv(ST(0), Apache::Request, (void*)RETVAL);
In any case all you need to do to get around this is define your own
new method and call the Apache::Request object directly and store it
as the value 'r'.. Here's an example:
sub new {
my ($class, $r) = @_;
return bless { r = Apache::Request-new($r),
}, $class;
}
Thanks for your help!
--Alex
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
The problem is that package FooBar doesn't have a new
method. Here's what happened as a result.
When you called 'FooBar-new($r), perl looked for a sub
called new in package
FooBar. Since it didn't find one, it looked at FooBar's @ISA,
and looked in
Apache::Request for a new method. There it presumably found
one, so that
statement didn't return an error. But, the new() in
Apache::Request probably
returned an Apache::Request object instead of a FooBar
object, so when you
called $form-fooey, it only looked in Apache::Request and
any modules in it's
@ISA.
You might want to look at using the universal isa and can
methods while
you're debugging and trying stuff out. Good luck!
Wes Sheldahl
--
Paul Lindner[EMAIL PROTECTED] | | | | | | | | | |
mod_perl Developer's Cookbook http://www.modperlcookbook.org/
Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: mod_perl, mod_gzip, incredible suckage
On Thursday 14 February 2002 20:59, Jeffrey W. Baker wrote: Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? I installed it on a Slackware machine using the source code and apxs. It loads but segfaults on every request. I installed it on a Debian machine via apt-get and it segfaults at startup. I got it to work once, but I confirm this was painful. I don't use it anymore though so I can't remember the magic that it took to get it to run. As an alternative (probably incomplete) solution, you might want to look inside one of the templating/publishing modules out there that support gzip output natively. I know AxKit does, and iirc TT does too (but I'm not sure). -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- The human brain is a wonderful thing, but it is also a result of three billion years' worth of good enough implementation. As a result, it is a giant hack with more than a few quirks.
RE: mod_perl compile problem
Hi again, On Thu, 14 Feb 2002, OCNS Consulting wrote: I revert back to the ActiveState rpm version 5.6.1 Build 631. Do you believe that the version of PERL or APACHE has something to do with it? No, I don't think it's a Perl problem, but it's a very complex bunch of software and an awful lot of the Perl, Apache and mod_perl stuff relies on an awful lot of other stuff so I'd always recommend that you stay with the tried-and-tested things to start off with. If you have a need for something a little exotic then you can start to throw in the unknowns (I'd include ActiveState in that:) one by one later to see what, if anything, breaks. Easier to delouse. The problem seems to me to be missing or misplaced files. That generally means an unusual build of something which is why I suggested starting from scratch with the tarballs. Can you describe how you set up the directories for your build? 73, Ged.
FW: mod_perl compile problem
Any other thoughts on this issue? I really would like to use mod_perl. Regards, RB -Original Message- From: OCNS Consulting [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 11:48 AM To: Hans Juergen von Lengerke Cc: Randy Kobes; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: mod_perl compile problem Hans: Thanks for the TYPO catch. Yes ActiveState Perl is available for Linux. See: - RPM - http://downloads.activestate.com/ActivePerl/Linux/5.6/ActivePerl-5.6.1.631-i 686-linux.rpm Once again, I performed the flexible way Build method, creating the libperl.a ar library. I then changed to the Apache Home Directory and performed the configure and make but the original problem returns. Below is the Apache Build Session. Thanks, RB === Apache Build Session with libperl.a module === [apache_1.3.23]#env SSL_BASE=/dist/openssl-0.9.6c EAPI_MM=SYSTEM LIBS=-ltcl8.3 -lm ./configure --verbose --enable-rule=EAPI --enable-module=status --enable-mod ule=so --enable-module=ssl --enable-module=headers --enable-module=info --en able-module=speling --activate-module=src/modules/php4/libphp4.a --activate- module=src/modules/extra/mod_auth_pam.o --activate-module=src/modules/mod_dt cl/mod_dtcl.a --activate-module=src/modules/perl/libperl.a Configuring for Apache, Version 1.3.23 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) + activated auth_pam module (modules/extra/mod_auth_pam.o) + activated dtcl module (modules/mod_dtcl/mod_dtcl.a) + activated perl module (modules/perl/libperl.a) Creating Makefile Creating Configuration.apaci in src + Rule SSL_COMPAT=yes + Rule SSL_SDBM=default + Rule SSL_EXPERIMENTAL=no + Rule SSL_CONSERVATIVE=no + Rule SSL_VENDOR=no + Rule EAPI=yes + Rule SHARED_CORE=default + Rule SHARED_CHAIN=default + Rule SOCKS4=no + Rule SOCKS5=no + Rule IRIXNIS=no + Rule IRIXN32=yes + Rule PARANOID=no + Rule EXPAT=default + Rule CYGWIN_WINSOCK=no + Rule DEV_RANDOM=default + Rule WANTHSREGEX=default + Module mmap_static: no + Module vhost_alias: no + Module env: yes + Module define: no + Module log_config: yes + Module log_agent: no + Module log_referer: no + Module mime_magic: no + Module mime: yes + Module negotiation: yes + Module status: yes + Module info: yes + Module include: yes + Module autoindex: yes + Module dir: yes + Module cgi: yes + Module asis: yes + Module imap: yes + Module actions: yes + Module speling: yes + Module userdir: yes + Module alias: yes + Module rewrite: no + Module access: yes + Module auth: yes + Module auth_anon: no + Module auth_dbm: no + Module auth_db: no + Module digest: no + Module auth_digest: no + Module proxy: no + Module cern_meta: no + Module expires: no + Module headers: yes + Module usertrack: no + Module example: no + Module unique_id: no + Module so: yes + Module setenvif: yes + Module ssl: yes + Module php4: yes + Module auth_pam: yes + Module dtcl: yes + Module perl: yes + id: mod_perl/1.26 + id: Perl/v5.6.1 (linux) [perl] Note (probably harmless): No library found for -lposix cd ..; gcc -DLINUX=22 -DMOD_SSL=208106 -I/dist/php-4.1.1 -I/dist/php-4.1.1/main -I /dist/php-4.1.1/main -I/dist/php-4.1.1/Zend -I/dist/php-4.1.1/Zend -I/dist/p hp-4.1.1/TSRM -I/dist/php-4.1.1/TSRM -I/dist/php-4.1.1 -DMOD_PERL -DUSE_PERL _SSI -DUSE_REENTRANT_API -D_POSIX_C_SOURCE=199506L -D_REENTRANT -fno-strict- aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEAPI -DEAPI_MM `./apaci` -I. -I/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/ CORE -I/usr/local/include -L/dist/openssl-0.9.6c -L/usr/local/lib -o helpers/dummy helpers/dummy.c -ltcl8.3 -lm -Wl,-rpath,/usr/local/BerkeleyDB.3.3/lib -rdy namic -L/usr/local/BerkeleyDB.3.3/lib -Lmodules/php4 -L../modules/php4 -L../ ../modules/php4 -lmodphp4 -lpam -ldl -ldb -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt -lm -lcrypt -lssl -lcrypto -rdynamic -L/usr/local/lib /usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/auto/DynaLoader/ DynaLoader.a -L/usr/local/ActivePerl-5.6/lib/5.6.1/i686-linux-thread-multi/C ORE -lperl -lnsl -ldl -lm -lpthread -lc -lcrypt -lutil -lmm -lexpat Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o ssl_module uses ConfigStart/End + SSL interface: mod_ssl/2.8.6 + SSL interface build type: OBJ + SSL interface compatibility: enabled + SSL interface experimental code: disabled + SSL interface conservative code: disabled + SSL interface vendor extensions: disabled + SSL interface plugin: Built-in SDBM + SSL library path: /dist/openssl-0.9.6c + SSL library version: OpenSSL 0.9.6c 21 dec 2001 + SSL library type: source tree only
Re: mod_perl, mod_gzip, incredible suckage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 11:59:02AM -0800, Jeffrey W. Baker wrote: Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? Compile it. Install it. Works brilliantly. Don't know what your problem might be. Please share offlist, perhaps I can help debug it. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxsMtIACgkQA4aoazQ9p2colACguj32YcweRfM7iOy66v8505Hb mSgAn1o4z1N19iDwO8TutmpX93OBxkJ7 =6v+i -END PGP SIGNATURE-
Re: mod_perl, mod_gzip, incredible suckage
On February 14, 2002 01:57 pm, Stephen Clouse wrote: On Thu, Feb 14, 2002 at 11:59:02AM -0800, Jeffrey W. Baker wrote: Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? Compile it. Install it. Works brilliantly. Don't know what your problem might be. Please share offlist, perhaps I can help debug it. Ditto here. Working quite well on fairly high volume servers. -- Jay yohimbe Thorne [EMAIL PROTECTED] Mgr Sys Tech, Userfriendly.org MS should publish history books. Each two years, you get a nice revision ;) - Jean Francois Pare
RE: mod_perl, mod_gzip, incredible suckage
:: Does mod_gzip suck or what? Some of you claim to use it. :: Now is the :: time to confess. How do you get it to work? :: :: Compile it. Install it. Works brilliantly. Hell I even got it to work under Win32. Agree with the other replies, it works brilliantly. Jonathan M. Hollin - WYPUG Co-ordinator West Yorkshire Perl User Group http://wypug.pm.org/
Re: mod_perl, mod_gzip, incredible suckage
On Thu, 2002-02-14 at 14:32, Jay Thorne wrote: On February 14, 2002 01:57 pm, Stephen Clouse wrote: On Thu, Feb 14, 2002 at 11:59:02AM -0800, Jeffrey W. Baker wrote: Does mod_gzip suck or what? Some of you claim to use it. Now is the time to confess. How do you get it to work? Compile it. Install it. Works brilliantly. Don't know what your problem might be. Please share offlist, perhaps I can help debug it. Ditto here. Working quite well on fairly high volume servers. Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on every single request. -jwb
RE: mod_perl, mod_gzip, incredible suckage
Ditto here. Working quite well on fairly high volume servers. Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on every single request. have you looked at the work at http://www.apachetoolbox.com/ ? This guy has an automated system for choosing what modules/packages to install, then download/extract/patch/compile/install automatically. He seems to be able to get ssl, php, gzip, and mod_perl all working at the same time. That might not be what you need, but if perhaps you were to review how he handled gzip/php/etc, you might see what obscure flag or switch might be affecting things poorly. Good luck! L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Re: mod_perl, mod_gzip, incredible suckage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 02:44:53PM -0800, Jeffrey W. Baker wrote: Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on every single request. We have (other than the standard modules) mod_perl, mod_php, mod_ssl, mod_gzip, mod_rewrite, and mod_auth_db, all statically linked. (At one point mod_fastcgi was in this cocktail as well, but was removed once everything was converted to mod_perl.) I do now recall having similar segfaults initially. The trick was reordering the modules in Configuration so mod_gzip came last (which actually puts it first, Apache processes the Configuration file from bottom to top). So the relevant portions of our configure line are: SSL_BASE=/usr ./configure \ --enable-module=rewrite \ --enable-module=ssl --disable-rule=SSL_COMPAT \ --enable-module=auth_db \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a \ --add-module=src/modules/extra/mod_gzip.c With this setup we have never had a problem. And with the most recent mod_gzip (I believe it's 1.3.19.1a) it now properly plays along with mod_perl/mod_php, and compresses their post-processing output as well. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxsQ0MACgkQA4aoazQ9p2fUFwCeKOeIKDEuRR6361UpIc+PMCY1 X+gAnis3HX0X6GanHfovTCvQmejIL7be =Dzyq -END PGP SIGNATURE-
Re: mod_perl, mod_gzip, incredible suckage
On Thu, 2002-02-14 at 15:07, Stephen Clouse wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 02:44:53PM -0800, Jeffrey W. Baker wrote: Hrmm how interesting. My Apache is built with PHP (with DOM, MySQL, and Postgres) and mod_perl. With mod_gzip enabled it simply segfaults on every single request. We have (other than the standard modules) mod_perl, mod_php, mod_ssl, mod_gzip, mod_rewrite, and mod_auth_db, all statically linked. (At one point mod_fastcgi was in this cocktail as well, but was removed once everything was converted to mod_perl.) I do now recall having similar segfaults initially. The trick was reordering the modules in Configuration so mod_gzip came last (which actually puts it first, Apache processes the Configuration file from bottom to top). So the relevant portions of our configure line are: SSL_BASE=/usr ./configure \ --enable-module=rewrite \ --enable-module=ssl --disable-rule=SSL_COMPAT \ --enable-module=auth_db \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a \ --add-module=src/modules/extra/mod_gzip.c With this setup we have never had a problem. And with the most recent mod_gzip (I believe it's 1.3.19.1a) it now properly plays along with mod_perl/mod_php, and compresses their post-processing output as well. Okay, I'll take a run at compiling everything statically. I've had no end of problems though with Expat, MySQL, PostgreSQL, and Zlib libraries being linked in multiple times by multiple modules or even Apache itself. Especially expat. Grr. -jwb
RE: mod_perl compile problem
On Thu, 14 Feb 2002, OCNS Consulting wrote: Ged, Yes, I have installed all three (Apache 1.3.23, Perl 5.6.1, mod_perl 1.2.6) from the tarball sources, tried to build and received the same results. I haven't tried Perl 5.7.2. Now, because the same result was yielded, I revert back to the ActiveState rpm version 5.6.1 Build 631. Do you believe that the version of PERL or APACHE has something to do with it? Thanks for the help - this is so frustrating. As Ged mentioned, unless you need Linux ActivePerl for some reason, it's probably better to compile your own Perl, and with as few non-default compile-time options as possible (eg, multi-threading). You mentioned earlier that a vanilla Apache compiles OK (without mod_perl support), so your problem is probably something to do with ActivePerl's compile-time flags, perhaps in combination with the other non-standard modules you're trying to build at the same time. If you do need ActivePerl, you might try building just mod_perl alone to see if that works, and then add mod_ssl and the others incrementally to see when it breaks. Or perhaps try building mod_perl as a DSO outside the Apache source tree - this is described in the INSTALL.apaci file in the mod_perl sources. best regards, randy kobes
Re: mod_perl, mod_gzip, incredible suckage
On Friday 15 February 2002 00:18, Jeffrey W. Baker wrote: Okay, I'll take a run at compiling everything statically. I've had no end of problems though with Expat, MySQL, PostgreSQL, and Zlib libraries being linked in multiple times by multiple modules or even Apache itself. Especially expat. Grr. The latest apache should normally use the system's expat lib instead of its own (conflicting) version, unless there's a module that requires it explicitly. That helped a *lot* for the conflicts with XML::Parser and friends. -- ___ Robin Berjon [EMAIL PROTECTED] -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Oh no not again ! said the bowl of petunias
Re: mod_perl, mod_gzip, incredible suckage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Feb 14, 2002 at 03:18:37PM -0800, Jeffrey W. Baker wrote: Okay, I'll take a run at compiling everything statically. First, just try loading mod_gzip before any other (non-static) module. You might save yourself the trouble of recompiling everything. (Although personally, I've never been able to get a DSO Apache working under any circumstances, but that's probably my problem :) - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxsSTgACgkQA4aoazQ9p2dkRwCfZugAi6UkO2JQUnxBhnw9LxQn lB0AniJ4v074YkVZmHgKtKPZxCxmOTl5 =WJ2b -END PGP SIGNATURE-
Re: Perl Section Bug?
On Wed, 2002-02-13 at 20:44, Salvador Ortiz Garcia wrote: Ok, I found it. Right now all Location, Directory and Files are afected by being upgraded at random to the Match versions. Ugly. Can you please test the following patch for perl_config.c: snip / Yes, that does indeed correct the problem. Thank you. Right now I'm working in a more radical patch to fix other minor problems related to Perl sections handling. Can I assume that the fixes will be in 1.27? Does Doug have plans for another release soon? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: mod_perl compile problem
Ged, I Unzip/Untar the Apache tarball and change to the Apache top level distribution directory. I then Unzip/Untar the module dists and one by one prep each module for a static build and then finally build mod_perl as per my previous messages. FYI: I dumped ActiveState Perl, built the regular 5.6.1 Perl distribution from www.perl.org (./configure -de, make install). and I still encounter the same problems building just vanilla Apache and mod_perl. What other debugging technique could I use in this effort? RB -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 3:08 PM To: OCNS Consulting Cc: mod_perl Mailing List Subject: RE: mod_perl compile problem Hi again, On Thu, 14 Feb 2002, OCNS Consulting wrote: I revert back to the ActiveState rpm version 5.6.1 Build 631. Do you believe that the version of PERL or APACHE has something to do with it? No, I don't think it's a Perl problem, but it's a very complex bunch of software and an awful lot of the Perl, Apache and mod_perl stuff relies on an awful lot of other stuff so I'd always recommend that you stay with the tried-and-tested things to start off with. If you have a need for something a little exotic then you can start to throw in the unknowns (I'd include ActiveState in that:) one by one later to see what, if anything, breaks. Easier to delouse. The problem seems to me to be missing or misplaced files. That generally means an unusual build of something which is why I suggested starting from scratch with the tarballs. Can you describe how you set up the directories for your build? 73, Ged.
Re: Question...
Actually, you can use the onUnload handler in the body tag. http://developer.netscape.com/docs/manuals/communicator/jsref/evnt24.htm Rodney Hampton Jon Robison wrote: On page leave? Well I think you can of course use javascript on all the links on the page, but I don't believe you can do much about the user typing in a new url in the browser. . . but that's just IMHO. --Jon Ryan Parr wrote: I think I'm missing something... If you set a session cookie (i.e. one with no expiry time) then the cookie will be deleted immediately upon browser close, forcing the user to login again if they've closed their browser instance. If you don't use cookies and allow basic auth then the exact same behavior is called, forcing the user to re-login only if they've closed that browser instance. Is there someway to expire cookies on page leave, or is this the smartass thing you were referring to? :) -- Ryan Parr - Original Message - From: Jon Robison [EMAIL PROTECTED] To: Ron Beck [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 12, 2002 12:28 PM Subject: Re: Question... Cookies! /me is in smartass mode today. --Jon Ron Beck wrote: Hello all, I need to know how to clear the $ENV variables. For example, I use a .htaccess file for specific directories which requires the user to enter userID and password. When they exit the page, I want them to have to re-enter userID and passwd if they enter the page again. Does anyone know how this is accomplished? TIA, Ron
Re: mod_perl documentation
On Wed, 13 Feb 2002, peteman wrote: What format are the documentation files (INSTALL, README, SUPPORT, etc) in, and why are they not in plain text format?? It's giving me a headache trying to read them. This is horidly evil(IMO), might i suggest that you distribute documentation in standard text format, so that everyone can read them(without getting a headache). They are in standard POD format. Try perldoc INSTALL or pod2text INSTALL. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Custom Logging and User Tracking
On Wed, 13 Feb 2002, Ryan Parr wrote: I checked it out and it's a good mod. I've already got the ability to log the data however. The issue that I'm having is that I can't seem to only get 1 log per hit. I can't seem to get around the fact that wherever I put my mod (PerlFixupHandler,PerlHandler,PerlLogHandler) or whatever statement I use ($r-is_main(), $r-is_initial_req()) I'm getting not only the requested page but every other request from the inital request. For instance, I'm getting and logging every graphic, css, javascript, or any other file that's linked in. But for my user tracking I want *just* the initial request, not that and all subrequests. I just can't seem to figure out how to do that. $r-is_main() and $r-is_initial_req() return true for everything. Maybe i'm wrong, but is_initial_req, is just there, to keep track of INTERNAL redirects, like, if you internaly redirect a file to another one, and you don't want to process the redirected one (because you don't care anymore). I think the best one for you problem should be something like this... 1.) use a shared hash (IPC::SharedCache or something like this) 2.) compute a MD5-Hash, with some data from the user, like IP and Browser-string 3.) put the MD5, or whatever in the hash, and set a timeoutvalue for this one 4.) on every request, lookup for the key, and check/update the timeout-value, and log the request, if it doesn't exists inside of the hash, or the timeout occured 5.) run a cleanup every 50/100 request, and clear the cache from timeouted values (for shared memory, this could also be done by a script running from crontab) i hope you get what i mean, and i hope it helps ;))) ciao nico
Re: mod_perl, mod_gzip, incredible suckage
Robin Berjon wrote: I got it to work once, but I confirm this was painful. I don't use it anymore though so I can't remember the magic that it took to get it to run. As an alternative (probably incomplete) solution, you might want to look inside one of the templating/publishing modules out there that support gzip output natively. I know AxKit does, and iirc TT does too (but I'm not sure). http://www.egurucool.com Works fine with mod_gzip as a DSO Dont even recall having to do anything fancy just followed the documentation. Mithun
