[ANNOUNCE] Apache-AuthCookie 3.02
The uploaded file
Apache-AuthCookie-3.02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.02.tar.gz
size: 29015 bytes
md5: 107408d13a43cfbe2d2eccce40adffbe
Changes:
---
Version: 3.02
- Add support for AuthNameSatisfy directive (can be Any/All, default: Any)
- Move cookie path setting into get_cookie_path() so that users can
overload this function if they desire (Thanks Raj Chandran)
- POST - GET conversion was broken (r-content called twice). Fixed.
Version: 3.01
- adopted support for custom_errors() hook from [EMAIL PROTECTED]
- Fixed incorrect documentation in authorize() (thanks to David Young).
- login() handler changes:
o if destination isnt in posted data, set AuthCookieReason to
no_cookie and return to login_form (previously just returned
SERVER_ERROR).
o if authen_cred() returns false, set AuthCookieReason to
bad_credentials and return to the login form.
o try to handle POST - GET conversion.
- CGI::Util dependency removed (these are internal subroutines for CGI.pm)
- ${AuthName}Path will default to / if it is not specified (MSIE 6.0
wont set cookies without path)
- fix login() handler change so that destination doesnt get lost on
subsequent login attempts (thanks Phillip Molter)
---
As usual, it may take a few hours for this to propogate to the CPAN mirrors.
Regards,
Mike
Re: PerlSetVar WhatEverSecure
On Thu, 13 Jun 2002, Brian Reichert wrote: Apache::AuthTicket says: Finally, by using the Secure mode of Apache::AuthCookie, the ticket is not passed over unencrypted connections. Passed in what direction? Client - server. rfc2109 says: Secure Optional. The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie. The user agent (possibly under the user's control) may determine what level of security it considers appropriate for secure cookies. The Secure attribute should be considered security advice from the server to the user agent, indicating that it is in the session's interest to protect the cookie contents. see http://www.ietf.org/rfc/rfc2109.txt It would only go server-client if the client made a SSL request. No. Your browser should not return the cookie to the server if the connection is not secure (meaning encrypted via SSL in practicality). The converse is not true. The cookie *WILL* be sent from server to your browser. If your browser misbehaves with it by returning it over a non-ssl connection, then your browser is broken and theres nothing AuthCookie can do to prevent that. I suppose my real question is: How can I intercept a unencrypted request for a protected document, but have the login form be submitted over an encrypted channel? THere are lots of ways to do this. One way that comes to mind is using mod_rewrite to check of the user is in HTTPS mode or not, and if not, then redirect them to HTTPS. Mike
Re: Problems with Apache-AuthCookie mod_perl 1.99
On Thu, 2 May 2002, Per Einar Ellefsen wrote: At 21:25 02.05.2002, Peter Rothermel wrote: greetings, Has anybody had any luck getting Apache-AuthCookie going on an Apache 2.0 / mod_perl 1.99 setup? The first thing that I hit was $r-connection-user is deprecated. I've changed these to $r-user. The next hurdle is that the status code REDIRECT does not seen to be Apache::Constants. mod_perl 2 doesn't have Apache::Constants. You should use: use Apache::Const -compile = qw(... REDIRECT ..); Good luck on porting it to mod_perl 2! once you get it to work, it would be great if you could contribute it to the community! If you do get it working, feel free to forward patches to me as I am the AuthCookie maintainer. An apache 2.0 port is on my TODO list. Mike
CPAN Apache-AuthCookie-3.00.tar.gz (fwd)
The uploaded file
Apache-AuthCookie-3.00.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthCookie-3.00.tar.gz
size: 25399 bytes
md5: 5c94e0ced442653f229b39f4f1fcfe8c
Changes since v2.011:
- New maintiner: Michael Schout [EMAIL PROTECTED]
- changed to hard coded $VERSION rather than RCS Revision style.
- Revamped testing code to use Apache::test (with minor mods).
- Added support for ${AuthName}Expires parameter that can be used
to make your cookie persistent.
- CGI::Util is now used for parsing the Expires parameter. If you are
missing this package, you probably need to upgrade your CGI.pm package.
As usual, please allow time for this to propogate through the CPAN mirrors.
Regards,
Mike
Re: IPC:Open3 does not work under mod_perl/1.25, perl5.6.0?
I can verify for you that this is a problem.
You wouldnt happen to be using Apache::Filter would you?
I've posted this problem at least once over the past year, and I have seen it
posted by others. I had this porblem trying to oepn3() a pipe to gnupg and
encrypt some data. I later switched to the GnuPG::Tie package and had similar
problems.
After much head scratching I figured out that I was using Apache::Filter and I
needed to first untie STDIN and STDOUT before I could make things work.
My ugly hack around it basically was this:
my ($stdin, $stdout);
if (lc $this-request-dir_config('Filter') eq 'on') {
# undo Apache::Filter mess.
$stdin = tied *STDIN;
$stdout = tied *STDOUT;
untie *STDIN;
untie *STDOUT;
}
use GnuPG::Tie::Encrypt to encrypt data ...
if (lc $this-request-dir_config('Filter') eq 'on') {
# now retie STDIN, STDOUT for Apache::Filter
tie *STDIN, ref $stdin, $stdin;
tie *STDOUT, ref $stdout, $stdout;
}
I havent tried a similar solution for IPC::Open3, but you may want to try this
if you are using Apache::Filter.
Its not pretty, but it works for me :).
Mike
ANNOUNCE Apache::AuthTicket 0.31
The uploaded file Apache-AuthTicket-0.31.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthTicket-0.31.tar.gz size: 11958 bytes md5: b5224689b7823eb54b6e4f8190a20d69 No action is required on your part Request entered by: MSCHOUT (Michael Schout) Request entered on: Fri, 13 Apr 2001 16:28:54 GMT Request completed: Fri, 13 Apr 2001 16:29:53 GMT Virtually Yours, Id: paused,v 1.72 2000/12/26 15:12:53 k Exp k Changes: Release 0.31 o Removed an email address from Changes file via owners request. Release 0.30 o Changed calls from to Digest::MD5-md5_hex to just Digest::MD5::md5_hex() This causes md5 passwords generated with other md5() routines (PHP for example) to fail. Thanks to Steve Chadsey for spotting this. ** NOTE ** MD5 passwords that worked with previous versions will not work with this version due to the fact that md5_hex() was used incorrectly. Upgrading from previous versions will also invalidate any current tickets because the ticket generation routines also were using md5_hex incorrectly. --- As usual, please allow time for this release to propogate through the CPAN mirrors. Regards, Mike
bug in Perl section processing.
I have isolated a problem in Perl section processing that I have been
encountering. Basically there are situations where one particular entry in
%Location or %LocationMatch causes the *NEXT* entry to fail to configure
properly.
I have a standard httpd configuration, and then the following mod_perl
configuration (and no other mod_perl configuration items):
--- cut ---
PerlModule Apache::AuthTicket
Perl
$LocationMatch{'^/gen06/prologinform$'} = {
'PerlSetVar' = [
['ProtectedPath', '/gen06/protected'],
['ProtectedTicketLoginHandler', '/gen06/prologin']
],
'PerlHandler' = 'Apache::AuthTicket-login_screen Apache::SSI',
'AuthType'= 'Apache::AuthTicket',
'AuthName'= 'Protected',
'SetEnv' = [
['LANG', 'en'],
['HTML_TEMPLATE_ROOT', '/something/gen06']
],
'SetHandler' = 'perl-script'
};
$LocationMatch{'^/gen06/prologin$'} = {
'PerlSetVar' = [
['ProtectedPath', '/gen06/protected'],
['ProtectedLoginScript', '/gen06/prologinform']
],
'PerlHandler' = 'Apache::AuthTicket-login',
'AuthType' = 'Apache::AuthTicket',
'AuthName' = 'Protected',
'SetHandler' = 'perl-script'
};
/Perl
--- cut ---
If I start the web server with this config, then /gen01/prologinform URI works
as expected, but the /gen06/prologin URI returns NOT_FOUND. Running under
strace, it appears that the request is falling through to the default handler,
and mod_perl is not matching it against the configured handler. If I run with
MOD_PERL_TRACE enabled, I see it appears to configure both URIs:
perl_section: Location ^/gen06/prologinform$
handle_command (PerlSetVar ProtectedPath /gen06/protected): perl_cmd_var:
'ProtectedPath' = '/gen06/protected'
OK
handle_command (PerlSetVar "ProtectedTicketLoginHandler" "/gen06/prologin"):
perl_cmd_var: 'ProtectedTicketLoginHandler' = '/gen06/prologin'
OK
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::AuthTicket-login_screen'
pushing `Apache::AuthTicket-login_screen' into `PerlHandler' handlers
perl_cmd_push_handlers: @PerlHandler, 'Apache::SSI'
pushing `Apache::SSI' into `PerlHandler' handlers
PerlHandler Apache::AuthTicket-login_screen Apache::SSI (OK) Limit=no
AuthType Apache::AuthTicket (OK) Limit=no
AuthName Protected (OK) Limit=no
SetHandler perl-script (OK) Limit=no
handle_command (SetEnv "LANG" "en"): OK
handle_command (SetEnv HTML_TEMPLATE_ROOT /something/gen06): OK
perl_section: Location ^/gen06/prologin$
handle_command (PerlSetVar ProtectedPath /gen06/protected): perl_cmd_var:
'ProtectedPath' = '/gen06/protected'
OK
handle_command (PerlSetVar "ProtectedLoginScript" "/gen06/prologinform"):
perl_cmd_var: 'ProtectedLoginScript' = '/gen06/prologinform'
OK
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::AuthTicket-login'
pushing `Apache::AuthTicket-login' into `PerlHandler' handlers
PerlHandler Apache::AuthTicket-login (OK) Limit=no
AuthType Apache::AuthTicket (OK) Limit=no
AuthName Protected (OK) Limit=no
SetHandler perl-script (OK) Limit=no
perl_section: /Location
If I simply comment out the entry for $LocationMatch{'^/gen06/prologinform$'},
and change nothing else at all, then the /gen06/prologin URI works correctly. So
something must be going wrong while configuring
$LocationMatch{'^/gen06/prologinform$'} that causes mod_perl not to configure
$LocationMatch{'^/gen06/prologin$'} correctly.
I'm running apache 1.3.17, mod_perl 1.25 on a redhat linux 6.2 machine (kernel
2.2.16). Mod perl is compiled statically into the web server. Perl version is
5.6.0. Is this bug known, or has anyone else encountered something like this?
If you need any other information about my configuration or reproducing this,
please let me know and I will be happy to provide you with the information.
Mike
Perl sections / Location problems
I've been scratching my head on this for quite a while and I cant seem to
figure it out. I have a very stripped down configuration, which only contains
the following Perl section:
Perl
use Apache::Status;
$Location{"^/perl-status-1\$"} = {
SetHandler = 'perl-script',
PerlHandler = 'Apache::Status'
};
$Location{"^/perl-status-2\$"} = {
SetHandler = 'perl-script',
PerlHandler = 'Apache::Status'
};
/Perl
If I start the server up, it appears to configure correctly, however, if I
access /perl-status-1 I get a 404 Not Found error. If I access /perl-status-2,
then I get the expected Apache::Status output. This is very repeatable in that
no matter what I shove into the Location hash if its a regexp, the first entry
doesnt work.
I'm running Apache 1.3.17, mod_ssl 2.8.0, perl 5.6.0, Linux 2.2.16
Anyone have any ideas?
I ran the server with MOD_PERL_TRACE=all as:
httpd -X -f /nis.home/mschout/httpd.conf.bug
during startup, the perl trace output is as follows:
perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok
ok
loading perl module 'Tie::IxHash'...ok
perl_section: /Files
perl_section: Location ^/perl-status-1$
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::Status'
pushing `Apache::Status' into `PerlHandler' handlers
PerlHandler Apache::Status (OK) Limit=no
SetHandler perl-script (OK) Limit=no
perl_section: Location ^/perl-status-2$
init `PerlHandler' stack
perl_cmd_push_handlers: @PerlHandler, 'Apache::Status'
pushing `Apache::Status' into `PerlHandler' handlers
PerlHandler Apache::Status (OK) Limit=no
SetHandler perl-script (OK) Limit=no
perl_section: /Location
perl_section: /Files
perl_section: /Location
perl_section: /Directory
perl_section: /Directory
perl_section: /VirtualHost
.
At request time, this is what appears in the error_log
`PerlInitHandler' push_handlers() stack is empty
PerlInitHandler handlers returned -1
`PerlPostReadRequestHandler' push_handlers() stack is empty
PerlPostReadRequestHandler handlers returned -1
`PerlTransHandler' push_handlers() stack is empty
PerlTransHandler handlers returned -1
`PerlInitHandler' push_handlers() stack is empty
PerlInitHandler handlers returned -1
`PerlHeaderParserHandler' push_handlers() stack is empty
PerlHeaderParserHandler handlers returned -1
`PerlAccessHandler' push_handlers() stack is empty
PerlAccessHandler handlers returned -1
`PerlTypeHandler' push_handlers() stack is empty
PerlTypeHandler handlers returned -1
`PerlFixupHandler' push_handlers() stack is empty
PerlFixupHandler handlers returned -1
[Wed Feb 14 15:18:38 2001] [error] [client 209.246.133.20] File does not exist:
/nis.home/mschout/dev/gkgdrs/gkgweb/html/perl-status-1
`PerlLogHandler' push_handlers() stack is empty
PerlLogHandler handlers returned -1
and running under strace, this is what we see during the request:
write(2, "`PerlInitHandler\' push_handlers("..., 49) = 49
write(2, "PerlInitHandler handlers returne"..., 37) = 37
write(2, "`PerlPostReadRequestHandler\' pus"..., 60) = 60
write(2, "PerlPostReadRequestHandler handl"..., 48) = 48
write(2, "`PerlTransHandler\' push_handlers"..., 50) = 50
write(2, "PerlTransHandler handlers return"..., 38) = 38
stat("/nis.home/mschout/dev/gkgdrs/gkgweb/html/perl-status-1", 0xb6dc) = -1 ENOENT
(No such file or directory)
stat("/nis.home/mschout/dev/gkgdrs/gkgweb/html", {st_mode=S_IFDIR|S_ISGID|0775,
st_size=3072, ...}) = 0
open("/.htaccess", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/nis.home/.htaccess", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nis.home/mschout/.htaccess", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/nis.home/mschout/dev/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/nis.home/mschout/dev/gkgdrs/.htaccess", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/nis.home/mschout/dev/gkgdrs/gkgweb/.htaccess", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/nis.home/mschout/dev/gkgdrs/gkgweb/html/.htaccess", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0664, st_size=194, ...}) = 0
fstat(4, {st_mode=S_IFREG|0664, st_size=194, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(4, "#\n# $Id: .htaccess,v 1.13 2000/1"..., 4096) = 194
read(4, "", 4096) = 0
close(4)= 0
munmap(0x40018000, 4096)= 0
write(2, "`PerlInitHandler\' push_handlers("..., 49) = 49
write(2, "PerlInitHandler handlers returne"..., 37) = 37
write(2, "`PerlHeaderParserHandler\' push_h"..., 57) = 57
write(2, "PerlHeaderParserHandler handlers"..., 45) = 45
write(2, "`PerlAccessHandler\' push_handler"..., 51) = 51
write(2, "PerlAccessHandler handlers retur"..., 39) = 39
write(2,
HTML::Template - cant use shared cache with global_vars?
Hi. I'm using HTML::Template v2.0, IPC::SharedCache 1.3, IPC::ShareLite 0.08, Storable 1.0.6. I've discovered that if I turn on the "global_vars" option in HTML::Template, then Storable cant serialize the template so that it can be placed in the cache. e.g.: my $tmpl = HTML::Template-new_file( 'foo.tmpl', associate = $cgi, global_vars = 1 ); Then when this code runs, it crashes with: [Wed Dec 6 09:38:49 2000] [error] Can't store CODE items at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_freeze.al) line 234, at /usr/lib/perl5/site_perl/5.6.0/IPC/SharedCache.pm line 554 If I simply turn off global_vars, then everything works fine. Has anyone else experienced this? I would like to be able to use global_vars and shared_cache at the same time :). Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.24 to 1.24_01 spinning httpds on startup (solved)
About a month or 2 ago, I had posted a problem where I tried to upgrade from: Redhat Linux 6.2, perl 5.6.0 Apache 1.3.12 mod_perl 1.24 mod_ssl 2.6.6 to Redhat Linux 6.2 perl 5.6.0 Apache 1.3.14 mod_perl 1.24_01 mod_ssl 2.7.1 And reported that after doing this, my httpds would spin on startup. When I turned on MOD_PERL_TRACE=all, it was showing that it was stuck in an infinite loop processing configuration stuff. I posted the mod_perl trace for it as well. I have finally gotten a chance to revisit this and it turns out that what was causing problems was that I had in my httpd.conf: Perl $PerlRequire = '/some/path/file.pl'; /Perl Changing this to: Perl push @PerlRequire, '/some/path/file.pl'; /Perl Fixed the problem under 1.24_01 for me and everything appears to be kosher now. Maybe the behavior of PerlRequire has changed between 1.24 and 1.24_01? Anyways, I wanted to post this to the list in hopes that this might help others who may have stumbled onto this problem. Regards, Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
possible bug in mod_perl 1.24_01
I have had an application working under apache 1.3.12/mod_perl 1.24 for several months now with no problems. I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then try to start apache, it goes into an infinite loop proocessing perl sections. The stack trace from gdb looks like this: #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 1736vfprintf.c: No such file or directory. (gdb) bt #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 #1 0x40105966 in _IO_vfprintf (s=0x401aea20, format=0x8119d18 "loading perl module '%s'...", ap=0xbf801910) at vfprintf.c:1029 #2 0x4010e027 in fprintf (stream=0x401aea20, format=0x8119d18 "loading perl module '%s'...") at fprintf.c:32 #3 0x806d0c0 in perl_require_module () #4 0x806b40c in perl_section () #5 0x806b231 in perl_section_self_boot () #6 0x8068d8e in perl_cmd_require () #7 0x8081f29 in invoke_cmd () #8 0x80822ac in ap_handle_command () #9 0x806acb7 in perl_handle_command () #10 0x806b826 in perl_section () #11 0x806b231 in perl_section_self_boot () #12 0x8068d8e in perl_cmd_require () #13 0x8081f29 in invoke_cmd () #14 0x80822ac in ap_handle_command () #15 0x806acb7 in perl_handle_command () #16 0x806b826 in perl_section () #17 0x806b231 in perl_section_self_boot () #18 0x8068d8e in perl_cmd_require () #19 0x8081f29 in invoke_cmd () #20 0x80822ac in ap_handle_command () snip a whole bunch of repetitions of steps 15-20 #5889 0x806acb7 in perl_handle_command () #5890 0x806b826 in perl_section () #5891 0x806b231 in perl_section_self_boot () #5892 0x8068c6c in perl_cmd_module () #5893 0x8081f29 in invoke_cmd () #5894 0x80822ac in ap_handle_command () #5895 0x80822f8 in ap_srm_command_loop () #5896 0x80827ed in ap_process_resource_config () #5897 0x8085f28 in include_config () #5898 0x808206c in invoke_cmd () #5899 0x80822ac in ap_handle_command () #5900 0x806acb7 in perl_handle_command () #5901 0x806b043 in perl_handle_command_av () #5902 0x806b9d8 in perl_section () #5903 0x808206c in invoke_cmd () #5904 0x80822ac in ap_handle_command () #5905 0x80822f8 in ap_srm_command_loop () #5906 0x80827ed in ap_process_resource_config () #5907 0x8082e74 in ap_read_config () #5908 0x808a745 in main () #5909 0x400d89cb in __libc_start_main (main=0x808a560 main, argc=4, argv=0xb914, init=0x8062524 _init, fini=0x811741c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:92 And when I run with "MOD_PERL_TRACE=all" I get a whole bunch of output. It starts out like this: perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok SVt_PV: $Group = `mschout' handle_command (Group mschout): OK SVt_PV: $ServerAdmin = `[EMAIL PROTECTED]' handle_command (ServerAdmin [EMAIL PROTECTED]): OK perl_section: /Location perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files perl_section: /Files SVt_PV: $ServerRoot = `/nis.home/mschout/httpd' handle_command (ServerRoot /nis.home/mschout/httpd): OK SVt_PV: $User = `mschout' handle_command (User mschout): OK perl_section: /Directory loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok PORTS CONFIGURATION HTTP : 8531 HTTPS: 4531 `@Listen' directive is TAKE1, (2 elements) default: iterating over @Listen handle_command (Listen 8531): OK handle_command (Listen "4531"): OK perl_section: /Location perl_section: VirtualHost _default_:4531 SSLVerifyDepth 10 (OK) Limit=no SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key (OK) Limit=no SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt (OK) Limit=no SSLVerifyClient none (OK) Limit=no SSLEngine on (OK) Limit=no handle_command (SetEnvIf "User-Agent" ".*MSIE.*" "nokeepalive" "ssl-unclean-shutdown"): OK perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files SVt_PV: $Port = `8531' handle_command (Port 8531): OK perl_section: /Files perl_section: /Directory loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok SVt_PV: $DAVLockDB = `/var/tmp/DAVLock.mschout' handle_command (DAVLockDB /var/tmp/DAVLock.mschout): OK `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: /Location perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files perl_section: /Files perl_section: /Directory SVt_PV: $DAVMinTimeout = `600' handle_command (DAVMinTimeout 600): OK loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok
Re: possible bug in mod_perl 1.24_01
I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
RE: :Parse segmentation fault
On Tue, 10 Oct 2000, Matt Sergeant wrote: On Mon, 9 Oct 2000, Herrington, Jack wrote: This allows for XML parsing with no change to the Perl code. I'm just not sure what I am losing in Apache (which is where I make the change). What does losing EXPAT do to Apache? You lose mod_dav, and maybe future modules that use the built in expat support. But nothing serious. All of hte problems that you are seeing are essentially due to the fact that XML::Parser uses its own version of expat that has been patched. So the expat code from XML::Parser conflicts with the expat code from apache if you built with RULE_EXPAT=yes. Things get further complicated if you use php, which also pulls in a customized version of expat, causing more conflicts. There is work to fix this going on by maintaining expat so that it contains all of hte patches from these projects. This is on sourceforge at http://expat.sourceforge.net/ They have a preliminary release that I have built as a shared library and it works fine on our system. We use it this way: Compile apache with: RULE_EXPAT=no Build expat from sourceforge as a shared library fiddle with XML::Parser makefiles to cause it to link against libexpat.so instead of bulding its customized version. build mod_dav by linking with libexpat.so So XML::Parser and mod_dav can co-exist happily in this situation. I have .rpms and .src.rpm files of expat, XML::Parser, mod_dav which include the patches. If anyone is interested, please let me know and I will be happy to forward them to you (the rpms, or the patches). Mike
Re: crash in modperl-1.24
On Wed, 16 Aug 2000, Matt Sergeant wrote: On Tue, 15 Aug 2000, Mark D. Anderson wrote: The problem was the symbol conflict between XML::Parser and apache when built with expat. This has been apparently known for over a year, but has still not been fixed last i checked, presumably because it involves 4 different products interacting: apache builds with expat, modperl gets linked in, then modperl pulls in XML::Parser which pulls in expat again. [snip] name!!! Anyway, this is a much larger problem than you expect. Not only is XML::Parser pulling in a custom non-dso expat, but so is PHP, and so is Sablotron (XSLT processor), and so is some TCL module... We need a single DSO expat that is used by everyone, but I don't have the time or resources to fix it... :-( This problem has just bitten us as well. We were building apache with expat, and then loading XML::Parser 2.29 in. Things became unstable very quickly. As a quick fix, we just disabled EXPAT from our apache builds. So I guess there is no hope of running any combination of mod_dav, XML::Parser, PHP, Sablotron at the same time at this point? Bummer :). I suppose the issue is that expat needs to be maintained and someone needs to incorporate all of hte separate patches (e.g. XML::Parser patches expat, I assume PHP/Sablotron etc are doing the same) into a single expat and create a shared library? I may be able to devote some time to this, depending on how much merging is involved. I will try to take a look at it over the next few days. Mike
segmentation fault with CGI::Application
I have been trying to get CGI::Application to work under mod_perl today. So far with no success. Finally I removed everything except CGI::Application from the config files, and the server dumps core on startup. I have a very stripped odwn httpd.conf that basically loads the bare minimum apache modules, then does "PerlModule CGI::Appliation". Starting httpd dumps core when it tries to start up. Running it through the debugger produces this: This GDB was configured as "i386-redhat-linux"... Core was generated by `httpd -f /nis.home/mschout/dev/gkgdrs/gkgnsi/conf/redirect/httpd.conf'. Program terminated with signal 11, Segmentation fault. #0 0x80ad4d2 in Perl_gv_init () (gdb) bt #0 0x80ad4d2 in Perl_gv_init () #1 0x80ae690 in Perl_gv_fetchpv () #2 0x806a0a5 in perl_section_hash_init () #3 0x806a375 in perl_section () #4 0x806a16d in perl_section_self_boot () #5 0x8068033 in perl_cmd_module () #6 0x8080519 in invoke_cmd () #7 0x808089c in ap_handle_command () #8 0x80808e8 in ap_srm_command_loop () #9 0x8080c57 in ap_process_resource_config () #10 0x80812e4 in ap_read_config () #11 0x8088bc5 in main () #12 0x400d79cb in __libc_start_main (main=0x80889e0 main, argc=3, argv=0xb904, init=0x8062c24 _init, fini=0x8123e1c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb8fc) at ../sysdeps/generic/libc-start.c:92 Taking out the "PerlModule CGI::Application" line causes the server to start up normally. Taking a quick glance through Application.pm, I dont see anything that should be causing the interpreter to freak out. I suspect the problem is outside of CGI::Application somewhere, but CGI::Application is demonstrating some bug here ;). Anyone have any ideas? I'm using: perl 5.6.0 mod_perl 1.24 Linux 2.2.x Has anyone else gotten CGI::Application to run in this environment? Anyone else seen this? Mike
Re: segmentation fault with CGI::Application [SOLVED]
Ok. Turns out that what the real problem here was that CGI::Application uses CGI::Carp, and I needed a newer version of CGI::Carp. So I seem to have sovled this :) Mike On Wed, 19 Jul 2000, Michael J Schout wrote: I have been trying to get CGI::Application to work under mod_perl today. So far with no success. Finally I removed everything except CGI::Application from the config files, and the server dumps core on startup. I have a very stripped odwn httpd.conf that basically loads the bare minimum apache modules, then does "PerlModule CGI::Appliation". Starting httpd dumps core when it tries to start up. Running it through the debugger produces this: This GDB was configured as "i386-redhat-linux"... Core was generated by `httpd -f /nis.home/mschout/dev/gkgdrs/gkgnsi/conf/redirect/httpd.conf'. Program terminated with signal 11, Segmentation fault. #0 0x80ad4d2 in Perl_gv_init () (gdb) bt #0 0x80ad4d2 in Perl_gv_init () #1 0x80ae690 in Perl_gv_fetchpv () #2 0x806a0a5 in perl_section_hash_init () #3 0x806a375 in perl_section () #4 0x806a16d in perl_section_self_boot () #5 0x8068033 in perl_cmd_module () #6 0x8080519 in invoke_cmd () #7 0x808089c in ap_handle_command () #8 0x80808e8 in ap_srm_command_loop () #9 0x8080c57 in ap_process_resource_config () #10 0x80812e4 in ap_read_config () #11 0x8088bc5 in main () #12 0x400d79cb in __libc_start_main (main=0x80889e0 main, argc=3, argv=0xb904, init=0x8062c24 _init, fini=0x8123e1c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb8fc) at ../sysdeps/generic/libc-start.c:92 Taking out the "PerlModule CGI::Application" line causes the server to start up normally. Taking a quick glance through Application.pm, I dont see anything that should be causing the interpreter to freak out. I suspect the problem is outside of CGI::Application somewhere, but CGI::Application is demonstrating some bug here ;). Anyone have any ideas? I'm using: perl 5.6.0 mod_perl 1.24 Linux 2.2.x Has anyone else gotten CGI::Application to run in this environment? Anyone else seen this? Mike
Re: Installing mod_perl a dozen times ...
I guess I will chime in on this since we have dealt with this very same issue. The problem that we have is that there are a handful of production boxes, a handful of staging boxes (testing release candidates etc), and a handful of developer boxes. Our goal was to make it as easy as possible to get the machines in a state containing the exact versions of the required CPAN packages, perl, mod_perl, apache, system libraries etc. One idea that has been mentioned here was to use CPAN shell to create a Bundle of the modules you need. My personal experience was that this just didnt work quite right :). CPAN bundles only appear to care tha tyou have *at least* a particular version of a package installed. But if your system depends on a previous version than the latest and greatest of a particular package, you are pretty much out of luck there as far as I can tell. YMMV :). We also needed the ability to apply minor patches to a few modules / packages. CPAN shell didnt seem to be able to help us here. Also, CPAN shell requires a certain degree of user interaction to install all of the modules we need. The other problem was that several machines in the rotation get "loaned out" to other projects, and when we get them back, we dont know what state things are in on the machine. So we needed to be able to (relatively) quickly re-install all of the packages we needed on the machines if needed. What we finally settle on was to use RPMs to do it all. This allowed us to get exact versions of everything we needed, and we could blast new bits onto machines with a very simple one-liner: rpm -Uvh --force ftp://somehost/pub/proj/\*.rpm This was much faster than searching CPAN, and requires no human interaction. The only caveat here is that you need to maintain a set of RPMS. Luckily this is not to terribly difficult. We already had RPMS of apache+mod_perl, perl, etc. The tricky part is how can we make RPMS easily out of all of those CPAN modules we were using? Luckily someone has already done this :). On CPAN, Jochen Wiedmann has a script called "makerpm.pl". You can download this file from CPAN, copy it to /usr/src/redhat/SOURCES, cd to that directory, and make a new RPM/SRPM pair like this: makerpm.pl --specs --source Apache-AuthTicket-0.20.tar.gz Then, build the rpm/srpm from the .spec file you just made: rpm -ba -v Apache-AuthTicket.spec And thats it. Pretty simple. Of course you are limited to machines that can use .rpm here, but you can probably adopt a similar strategy for other package management systems. Anyways, this is how we solved this problem. Now with this in place, I just run the rpm install from ftp, then load our sorce tree for the particular project on the machine straight from CVS, and start working. Total setup of a new machine takes about 5-10 minutes tops :). Mike
ANNOUNCE: Apache-AuthTicket-0.20
The uploaded file
Apache-AuthTicket-0.20.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-AuthTicket-0.20.tar.gz
size: 11591 bytes
md5: e2f84546aa18b7afb1c8aead5ea3365f
Release 0.20
o Renamed module from Apache::TicketAccess to Apache::AuthTicket.
o Adapted module to Apache::AuthCookie v2.011. This module now
subclasses Apache::AuthCookie and relies on AuthCookie for all of the
cookie login logic. This was basically a complete rewrite.
o Split up query to fetch the server secret so that the LIMIT clause is
not needed (for Sybase ASE backends, thanks to Eivind Trondsen)
o Made DBI commit() only be called if AutoCommit is off.
(silences a warn() for MySQL)
o Added support for md5 style passwords.
o Added support for crypt() style passwords.
o Added way to retrieve reason for login using
$r-subprocess_env("AuthTicketReason").
o Added support for Idle Timeout logouts via TicketIdleTimeout
configuration.
o Added "sample" directory with sql examples for setting up pgsql and mysql
backends, as well as httpd.conf samples.
o Removed libapreq dependency (AuthCookie does this stuff now)
* it may take a few days for this to propogate to your favorite CPAN mirror.
Problems with Perl sections.
I'm having some issues with Perl sections. Basically what I have is a setup
like this:
httpd.conf:
Perl
my %handlers = (
'/foo' = { HANDLER = 'GKG::Foo', FILTER = 1 },
'/bar/foo' = { HANDLER = 'GKG::FooBar' }
);
for my $i (keys %handlers) {
my %conf = %{$handlers{$i}};
$Location{$i} = {
PerlHandler = $conf{HANDLER},
SetHandler = 'perl-script'
};
if (defined $conf{FILTER}) {
push @{ $Location{$i}-{PerlSetVar} }, ['Filter', 'On'];
}
}
/Perl
The problem is that when this gets configured it does not seem to correctly
deal with the URL locations. In my case, both /foo and /bar/foo execute
GKG::Foo. It seems to think that since location "/bar/foo" contains "/foo"
that it should use the handler "GKG::Foo" instead of handler "GKG::FooBar".
Also, standard static urls such as "/js/foo.js" end up getting caught by mod
perl and the output from "GET /js/foo.js" will be the content from the
perl-handler GKG::Foo, not the contents of the static file /js/foo.js!
If I configure it without perl-sections like this:
Location /foo
SetHandler perl-script
Perlhandler GKG::Foo
/Location
Location /bar/foo
SetHandler perl-script
Perlhandler GKG::FooBar
/Location
Then it works correctly. So there definately seems to either be a problem with
Perl sections, or the semantics of using %Location inside a Perl section does
not agree with the standard Location block.
Does anyone have any ideas what might be the problem here? Is this a bug, or
am I just using this incorrectly?
Thanks for any ideas :).
I'm using mod_perl 1.24, perl 5.6.0 Linux 2.2.x
Mike
Re: Problems with Perl sections.
Ok I think I might have figured this one out. If I treat the keys of %Location as regexps I sseem to get the desired results :). e.g.: '^/foo$', '^/bar/foo$' Maybe this shold be documented in the guide better? Mike
CHECK blocks under mod_perl?
Hi.
I would like to use a CHECK { } block under mod_perl, but have so far not had
any luck. It seems like mod_perl does not know how to deal with CHECK { }
blocks. Is this true? If so, can it be remedied? I cant use a BEGIN block
for what I am doing because it must happen after compilation is completed. I
know that CHECK blocks are a 5.6.0 feature so this is why I think maybe
mod_perl doesnt know how to deal with them.
I'm using mod_perl 1.24, apache 1.3.12, perl 5.6.0
Mike
Re: [OT] Making apps (un)available solution
On Mon, 19 Jun 2000, Matt Sergeant wrote:
On Sun, 18 Jun 2000, Michael J Schout wrote:
On Tue, 13 Jun 2000, Erich L. Markert wrote:
I'm trying to figure out the best way to make apps (un)available without
having to edit the apache config files.
We did something like this by making a handler like this:
package Foo::PerlHandler;
use Class::MethodMaker
new_with_init = 'new',
get_set = [qw/request/];
sub handler {
my ($class, $r) = @_;
You forgot prototypes here, otherwise handler always gets called with just
$r.
Yeah.. thats right.. the real one has prototypes.I should have just
cut/pasted it instead of reproducing it from memory :).
($class, $r) = (__PACKAGE__, $class) unless defined $r;
if (-f /tmp/foo.unavailable) {
$r-headers_out-add('Location', '/maintenance/index.html');
return REDIRECT;
}
my $this = $class-new($r);
$this-service;
You've also forgotten your exception handling code here. Always try and
wrap your dispatch code in an eval:
Yes.. our production version also has this.. actually, we use Error.pm from
CPAN to catch a variety of exceptions... e.g.:
try {
$this-sevice;
} catch Error::Foo with {
# do something
} catch Error::Foo2 with {
# do something else
} otherwise {
# uncaught exception
};
But I didnt feel it was worth showing all of that in my original msg :).
Mike
Re: [OT] Making apps (un)available solution
On Tue, 13 Jun 2000, Erich L. Markert wrote:
I'm trying to figure out the best way to make apps (un)available without
having to edit the apache config files.
We did something like this by making a handler like this:
package Foo::PerlHandler;
use Class::MethodMaker
new_with_init = 'new',
get_set = [qw/request/];
sub handler {
my ($class, $r) = @_;
($class, $r) = (__PACKAGE__, $class) unless defined $r;
if (-f /tmp/foo.unavailable) {
$r-headers_out-add('Location', '/maintenance/index.html');
return REDIRECT;
}
my $this = $class-new($r);
$this-service;
}
sub init {
my ($this, $r) = @_;
$this-request($r);
}
sub service {
die "service is virtual!\n";
}
__END__
Then in our actual apps, we inherit Foo::PerlHandler:
package Foo::MyApp;
use Foo::PerlHandler;
@ISA = qw(Foo::PerlHandler);
sub handler {
my ($class, $r) = @_;
($class, $r) = (__PACKAGE__, $class) unless defined $r;
# do pre-request things specific to Foo::MyApp
return $class-SUPER::handler($r);
}
sub service {
my ($this) = @_;
my $r = $this-request;
# do whatever here that you would do in your handler.
}
__END__
In httpd.conf:
Location /foo/myapp
SetHandler perl-script
PerlHandler Foo::MyApp
/Location
In actuality, we usually dont have to even define a handler() in our
application classes because the one provided by Foo::PerlHandler does
everything we need. Occasionally it is useful to do overload it though (which
is why I show the simple example above.
The benefit of this is that as long as all of our applications make use of
Foo::PerlHandler as their parent class, then we can shut down all applications
and make them redirect to /maintenance/index.html by simply doing "touch
/tmp/foo.unavailable" on the web server(s). No need to restart, no need to
fiddle with config files.
To make the applications available again, just "rm /tmp/foo.unavailable" and
requests are not redirected to the maintenance page anymore.
Anyways, this is how we decided to deal with this issue. Theres lots of other
ways I am sure :).
Mike
Re: IPC::Open2 v5.6.0 failures.
On Fri, 16 Jun 2000 [EMAIL PROTECTED] wrote: Hi, my open2 script failes to work under mod_perl with perl v5.6.0. Works correctly outside of the 5.6.0-mod_perl environment but works with mod_perl-5.005_03. ... I have the exact same problem using IPC::Open3 under perl 5.6.0/mod_perl 1.24 Its as if everything you write to the filehandle mysteriously disappears before getting to the opened process. I am not sure why this happens. Mike
ANNOUNCE: Apache-TicketAccess 0.10
Apache-TicketAccess-0.10.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MS/MSCHOUT/Apache-TicketAccess-0.10.tar.gz size: 9388 bytes md5: 42a00ba96205ead6a0d03cb25903bae6 This is the inital version of Apache::TicketAccess. This version does not yet subclass Apache::AuthCookie, but the next version probably will use AuthCookie to handle all cookie related logic. This was uploaded last week, so it should be on most of the CPAN mirrors by now :). Mike
[Slightly OT] IPC::Open3 broken in mod_perl/perl 5.6.0?
Sorry if this is slightly off topic. I seem to have run into problems using IPC::Open3 under mod_perl 1.22 and perl 5.6.0. This probelm only seems to have cropped up after I upgraded form perl 5.005 to perl 5.6.0. What happens is I have an exception handler that opens gpg and uses gpg to encrypt some data and email it to me in the case of an exception. The code looks like this: my $input = new IO::Handle; my $output = new IO::Handle; my $error = new IO::Handle; my $cmd = "gpg --homedir /etc/httpd/perl/gkgnsi/gpg -r $to -ea"; my $pid = IPC::Open3::open3($input, $output, $error, $cmd); THis worked fine when I was running perl 5.005, but now it dies here, and the apache error_log shows: [error] Can't locate object method "OPEN" via package "Apache" at /usr/lib/perl5/5.6.0/IPC/Open3.pm line 132. Strange... Has anyone seen anything like this? Anyone have any ideas? Thanks. Mike
Embperl segfaulting under perl 5.6.0
Hi. I seem to have run into some issues since I upgraded to perl 5.6.0. Since doing this, I recompiled all of my modules (I removed /usr/lib/perl5 and started fromscratch). I also recompiled apache/mod_perl so everything was linked against the properl libperl. Im using: apache 1.3.12 mod_perl 1.22 perl 5.6.0 HTML::Embperl 1.2.1 Everything worked fine under perl 5.00503, but now that I am running under 5.6.0, I get an apache segfault for every request. The problem seems to be in: XS_HTML__Embperl_GVFile() I get the entire document from the server before it crashes, so this seems to be a problem after the request has been served. XS_HTML__Embperl_GVFile() get entered lots of times after the page has been delivered before I get the segfault. Here is a stack after running httpd under the debugger and serving one request: Program received signal SIGSEGV, Segmentation fault. 0x80a9d60 in Perl_gv_fetchfile () (gdb) bt #0 0x80a9d60 in Perl_gv_fetchfile () #1 0x4038d434 in XS_HTML__Embperl_GVFile (cv=0x843bf24) at Embperl.xs:77 #2 0x80e6426 in Perl_pp_entersub () #3 0x80e138d in Perl_runops_standard () #4 0x80a7455 in S_call_body () #5 0x80a7221 in perl_call_sv () #6 0x8066acb in perl_call_handler () #7 0x8065f14 in mod_perl_cleanup_handler () #8 0x807d04a in run_cleanups () #9 0x807bf88 in ap_clear_pool () #10 0x807bfda in ap_destroy_pool () #11 0x807bf76 in ap_clear_pool () #12 0x8086812 in child_main () #13 0x8086cab in make_child () #14 0x8086da5 in startup_children () #15 0x808725e in standalone_main () #16 0x808784d in main () #17 0x400d1cb3 in __libc_start_main (main=0x80875d0 main, argc=5, argv=0xb9c4, init=0x8062c60 _init, fini=0x812089c _fini, rtld_fini=0x4000a350 _dl_fini, stack_end=0xb9bc) at ../sysdeps/generic/libc-start.c:78 (gdb) As you can see, it looks like Embperl is involved in the problem here. If I set a breakpoint at XS_HTML__Embperl_GVFile, I enter the break point about 42 times before the segmentation fault happens. Has anyone else seen this? Mike
