Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Fri, 3 May 2002 22:02:18 -0700 "Jim Helm" <[EMAIL PROTECTED]> wrote: : I was having the exact same problem 2 days ago... Could it be a : difference in static vs. dso? I'm running mod_perl as a dso - how about : you two? I compiled httpd. Jacob Davies (author of Apache::AuthCookieDBI) confirmed the secret key file has to be set before the PerlModule directive, it is a bug in the documentation. -- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
Try my Apache::AccessCookie too. It provides the same ticketing interface for many different authenticating methods such as LDAP, IMAP, ftp, SMB, and (of course) DBI, plus a number of useful features. One can simply implement her own mechanism too. It can be downloaded at http://mod_perl.home.att.net. BTW, I tried to register the module in CPAN, but was kind of lost in the middle. Peter Bi - Original Message - From: "Jim Helm" <[EMAIL PROTECTED]> To: "'Fran Fabrizio'" <[EMAIL PROTECTED]>; "'F.Xavier Noria'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, May 03, 2002 10:08 PM Subject: RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood) > p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I > wanted (timeout, not just expiry), which CookieDBI didn't have), and it > worked as documented with zero hassle... > > Jim > > > > -Original Message- > > > From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, May 03, 2002 6:38 AM > > > To: F.Xavier Noria > > > Cc: [EMAIL PROTECTED] > > > Subject: Re: problems setting up Apache::AuthCookieDBI > > > (solved but no fully understood) > > > > > > > > > > > > > > > > > >Does the server load the module that way? > > > > > > > > > > > It's beyond my expertise at this point but my experience > > > would indicate > > > that it does not work this way since I have PerlModule before the > > > PerlSetVar and it works fine. > > > > > > -Fran > > > > > > > > > > > > >
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
RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
p.s. FWIW, I ended up using Apache::AuthTicket instead - has a feature I wanted (timeout, not just expiry), which CookieDBI didn't have), and it worked as documented with zero hassle... Jim > > -Original Message- > > From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 03, 2002 6:38 AM > > To: F.Xavier Noria > > Cc: [EMAIL PROTECTED] > > Subject: Re: problems setting up Apache::AuthCookieDBI > > (solved but no fully understood) > > > > > > > > > > > > >Does the server load the module that way? > > > > > > > > It's beyond my expertise at this point but my experience > > would indicate > > that it does not work this way since I have PerlModule before the > > PerlSetVar and it works fine. > > > > -Fran > > > > > > >
RE: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
I was having the exact same problem 2 days ago... Could it be a difference in static vs. dso? I'm running mod_perl as a dso - how about you two? I did basically the same troubleshooting (added some log_error statements to the BEGIN block) and noticed the same thing - SecretKey file wasn't getting read. For some reason the dir_config hash is empty (completely, not just of *DBI_* entries) when that BEGIN block is executed. I don't know enough about apache internals to understand why moving the PerlModule line to the end of the PerlSetVar *DBI_* directives makes a difference, but it does (for some at least). Jim > -Original Message- > From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 03, 2002 6:38 AM > To: F.Xavier Noria > Cc: [EMAIL PROTECTED] > Subject: Re: problems setting up Apache::AuthCookieDBI > (solved but no fully understood) > > > > > > > >Does the server load the module that way? > > > > > It's beyond my expertise at this point but my experience > would indicate > that it does not work this way since I have PerlModule before the > PerlSetVar and it works fine. > > -Fran > > >
Scope of Perl Special Variables
Hello,
The online mod_perl guide
(http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
ml) states:
"Special Perl variables like $| (buffering), $^T (script's start time), $^W
(warnings mode), $/ (input record separator), $\ (output record separator) and
many more are all true global variables; they do not belong to any particular
package (not even main::) and are universally available. This means that if you
change them, you change them anywhere across the entire program; furthermore you
cannot scope them with my()."
My question pertains the CGI %ENV hash. First, I'm assumong that this is a
global variable in the sense of a Perl Special Variable, and not just a main::
or other package global. My question is how is it the case that the %ENV
variable script instance might be working with doesn't get clobbered or "reset"
by the next incoming request. Are some variables, like %ENV treated differently
by mod_perl?
Also, how can special variables be reliably initialized? For example, if one
request provides a certain attribute, such as HTTP_IDENT, but a subsequent
request does not, how do I know that the value of $ENV{HTTP_IDENT} on the second
request will indeed be undefined?
Thanks.
Bill
[Win32] documentation on mod_perl-2
Hi, I've started a document on getting and configuring mod_perl-2 with Apache-2 on Win32 at http://theoryx5.uwinnipeg.ca/win32_apache2.html describing both building mod_perl-2 and getting binary packages. Comments, omissions, corrections, etc. are very welcome. Thanks. best regards, randy kobes
Re: Help with Method Handlers in mod_perl 1.99
I tried the mehod attribute and now I get this error:
Error message:
Can't locate object method "" via package "Apache::AuthDerivedHandler".
Geoffrey Young wrote:
> Peter Rothermel wrote:
>
> > Can somebody help me out with Method Handlers in
> > Apache2 - mod_perl 1.99? I'm new to windows and its
> > threading issues.
>
> [snip]
>
>
> > sub authenticate ($$) {
> > my ($self, $r) = @_;
> > return OK;
> > }
>
> I haven't played much with mod_perl 2.0 yet, but I know that this format is
>deprecated now.
>
> instead, try
>
> sub authenticate : method {
>...
> }
>
> and look for method handlers in design.pod and compat.pod
>
> HTH
>
> --Geoff
Re: Help with Method Handlers in mod_perl 1.99
Peter Rothermel wrote:
> Can somebody help me out with Method Handlers in
> Apache2 - mod_perl 1.99? I'm new to windows and its
> threading issues.
[snip]
> sub authenticate ($$) {
> my ($self, $r) = @_;
> return OK;
> }
I haven't played much with mod_perl 2.0 yet, but I know that this format is deprecated
now.
instead, try
sub authenticate : method {
...
}
and look for method handlers in design.pod and compat.pod
HTH
--Geoff
Help with Method Handlers in mod_perl 1.99
Can somebody help me out with Method Handlers in
Apache2 - mod_perl 1.99? I'm new to windows and its
threading issues.
Here's a simple authentication handler that shows where
I'm getting stuck. I need to initialize a AuthDerivedHandler
object but I'm not sure exactly how to do this.
package Apache::AuthBaseHandler;
use strict;
use Apache::Constants qw(:common);
use vars qw($VERSION);
$VERSION = '3.00';
sub authenticate ($$) {
my ($self, $r) = @_;
return OK;
}
sub new {
my $this = shift;
my $class = ref($this) || $this;
my $self = {};
bless $self, $class;
return $self;
}
1;
__END__
package Apache::AuthDerivedHandler;
use strict;
use Apache;
use Apache::Constants qw(:common);
use Apache::AuthBaseHandler;
use vars qw($VERSION @ISA);
$VERSION = "1.0";
@ISA = qw(Apache::AuthBaseHandler);
sub NonMethodAuthHandler($) {
my $r = shift;
my $authhandler = Apache::AuthDerivedHandler->new();
return $authhandler->authenticate($r);
}
1;
In my httpd.conf I have the following directives:
PerlOptions +GlobalRequest
SetHandler perl-script
AuthType Apache::AuthCookieHandler
PerlAuthenHandler Apache::AuthDerivedHandler->authenticate
PerlHandler Apache::hello
require valid-user
PerlOptions +GlobalRequest
SetHandler perl-script
AuthType Apache::AuthCookieHandler
PerlAuthenHandler Apache::AuthDerivedHandler->authenticate
PerlHandler Apache::hello
require valid-user
In my startup.pl in have:
$ENV{MOD_PERL} or die "not running under mod_perl!";
use Apache2 ();
use Apache::compat ();
use Carp ();
use CGI ();
CGI->compile(':all');
CGI->compile(':standard');
use CGI::Carp;
use Apache::AuthDerivedHandler;
1;
Re: SOAP and web services
"Bart Frackiewicz" <[EMAIL PROTECTED]> wrote: >Hi Ric, > >> >> I use mod_perl/apache/soap::lite to create an internal >> "application server" >> so that I can distribute processing load from the public >> webserver. This >> also allows me to expose a soap web service to the public if >> I wished to >> give them direct access to a method on this application server, but of >> course they would need a soap client to access this service. >> >> Do you want to just return an xml to your user, or do you >> want to do what I >> do which is do internal RPC using SOAP. > >in my opinion a web service has another great benefit - you can sperate the logic and >the front ends. we have here an application running on php/html, and all the logic is >inside this scripts, in case of running on another medium/language (like flash or php >for plain html) you must copy all the logic - you can call this a nightmare. > >in this case i think that a solution provides with PRC/SOAP is a good idea, but on >every article i read more, i realize that this technology is still young and just >experimental (e.g. php 4.x). To add to the fun :) (now that my semester is over...) I mention the following only so you are aware of the possibilities, not because I think the decision to use SOAP is wrong (I don't think it is or isn't). I am working on an application that involves inter-process communication, of which XML-RPC is an example. I've decided to break my IPC needs into two classes: many-to-one or one-to-one, and one-to-many or many-to-many. XML-RPC does okay for the first set, but can't handle in any reasonably scalable manner the second set. For that, I'm taking a look at Spread [1], which Stas mentioned in passing on this list a few weeks ago. Spread also can work reasonably well, afaik, for many-to-one or one-to-one when the connection overhead associated with XML-RPC/SOAP becomes significant (e.g., frequent requests where the return value is not very important such as log consolidation). SOAP is a more complicated extension of XML-RPC (don't let the `Simple' fool you - the spec is anything but simple compared to XML-RPC -- of course, XML-RPC doesn't support object-orientation). XML-RPC is actually a fairly mature technology, imho, since it is available in such a wide range of languages and implementations. The initial spec was drawn up in April 1998 [2]. The PHP 4.x implementation is new and immature [3], but the spec itself is fairly mature. That said, XML-RPC, SOAP, and Spread all have reasonably simple Perl interfaces. [1] http://www.spread.org/ [2] St. Laurent S., Johnston J. and E. Dumbill, _Programming Web Services with XML-RPC_, O'Reilly (2001). [3] http://www.php.net/manual/en/ref.xmlrpc.php -- James Smith <[EMAIL PROTECTED]>, 979-862-3725 Texas A&M CIS Operating Systems Group, Unix
Re: HELP - Trying to get mod_perl and Apache2 working together onWin32....
On Fri, 3 May 2002, Jean-Marc Paulin wrote: > Randy, > > Thanks a lot. I thought I was not the only one. > In fact, this is not the test apache\post that hangs, but when running the > test apache\conftree that apache.exe dies.what happens after is because I've > aborted the script via Ctrl+Brk. I didn't have a problem with apache\conftree the last time I checked, but this was several days ago, with the cvs versions of apache/mod_perl. Did this problem arise for you with the cvs versions? If not, it may be worth trying these to see if your problem persists. > Regarding the Pb with Apache itself, I did copy the mod_perl.so to the > modules folder with nmake install (so they said in the book) > > Are you running Apache 2.00.35 ? > does the test (via nmake test) works for you ? or others ? Running the individual tests as, eg, perl -Mblib t/TEST t/apache/post.t works in running the tests individually for me, although some do fail (eg, some in modperl/dir_config). best regards, randy
Re: HELP - Trying to get mod_perl and Apache2 working together on Win32....
Randy, Thanks a lot. I thought I was not the only one. In fact, this is not the test apache\post that hangs, but when running the test apache\conftree that apache.exe dies.what happens after is because I've aborted the script via Ctrl+Brk. Regarding the Pb with Apache itself, I did copy the mod_perl.so to the modules folder with nmake install (so they said in the book) Are you running Apache 2.00.35 ? does the test (via nmake test) works for you ? or others ? Regards, JM - Original Message - From: "Randy Kobes" <[EMAIL PROTECTED]> To: "Jean-Marc Paulin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, May 03, 2002 3:41 PM Subject: Re: HELP - Trying to get mod_perl and Apache2 working together on Win32 > On Fri, 3 May 2002, Jean-Marc Paulin wrote: > > > Hi there, > > > > I am runing Win2000 SP2, and Apache 2.0.35 > > > > I have managed to build mod_perl (perl Makefile.PL and then nmake) but the > > test part fails: Apache crashes (Memory at 0x0018 cannot be read). Bug > > Maybe ? > > It seems so ... However, as you note below, it hang on > apache\post: > > > apache\cgihandlerok > > apache\compatok > > apache\compat2...ok > > apache\conftree..FAILED before any test output arrived > > apache\constants.ok > > apache\post..*** : > > halting tests > > and yet, on my system, running > > nmake t/TEST t/apache/post.t > > has this test running successfully. So it may be a problem in the > way the tests are being run via 'nmake test', as opposed to a > problem with individual tests. Further to this, if you run 'nmake > test' and skip apache/post.t, it then hangs at the next test. > > > > > Ok, I believe that configuration has been tryed before, so I must be missing > > a point somewhere. > > > > Oh, BTW, I have tried the nmake install anyway, but that does not go very > > well either as Apache fails to start if I include the PerlModule handler in > > the httpd.conf. > > Myself, and others, have got mod_perl to load OK ... What is > your configuration that's failing? Did you copy the generated > mod_perl.so to $APACHE/modules? > > best regards, > randy kobes >
Re: Can mod_perl help me use ENV variables in httpd.conf?
What I was really looking for was $r->server_root_relative. =) Thanks
Geoff!
That's to all for your help.
-Fran
> You'll also need to use a PerlPassEnv directive prior to your
> block.
>
> For debug purposes, try adding the following inside your block:
>
> print join("\n", map { "$_ => $ENV{$_}" } (keys %ENV)), "\n";
>
> OR, my personal quick-debugging catch-all:
>
> use Data::Dumper;
> print Dumper \%ENV;
>
> You'll be able to see what is available in %ENV when running under
> mod_perl. See also Chapter 9, page 498 of the Eagle.
>
> jason
>
> Ken Williams wrote:
>
>>
>> On Wednesday, May 1, 2002, at 05:04 AM, Fran Fabrizio wrote:
>>
>>>
>>> I spoke too soon.
>>>
>>> I need:
>>>
>>>
>>> push @Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-
>>> bin/chimpkit/) ];
>>>
>>>
>>> This does not appear to be possible because there's no way to pass
>>> in SERVER_ROOT to the apache startup.
>>
>>
>>
>> I think the problem is your Perl syntax, not the value of the
>> variable. Scalars do not interpolate in qw() constructs. Try this
>> instead:
>>
>>
>> push @Alias, '/cgi-bin/chimpkit/', "$ENV{SERVER_ROOT}/cgi-
>> bin/chimpkit/";
>>
>>
>> or even
>>
>>
>> push @Alias, '/cgi-bin/chimpkit/',
>>$r->server_root_relative . '/cgi-bin/chimpkit/';
>>
>>
>> -Ken
>>
>
Re: SOAP and web services
that too :) - Original Message - From: "Bart Frackiewicz" <[EMAIL PROTECTED]> To: "Richard Clarke" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, May 03, 2002 4:15 PM Subject: Re: SOAP and web services Hi Ric, > > I use mod_perl/apache/soap::lite to create an internal > "application server" > so that I can distribute processing load from the public > webserver. This > also allows me to expose a soap web service to the public if > I wished to > give them direct access to a method on this application server, but of > course they would need a soap client to access this service. > > Do you want to just return an xml to your user, or do you > want to do what I > do which is do internal RPC using SOAP. in my opinion a web service has another great benefit - you can sperate the logic and the front ends. we have here an application running on php/html, and all the logic is inside this scripts, in case of running on another medium/language (like flash or php for plain html) you must copy all the logic - you can call this a nightmare. in this case i think that a solution provides with PRC/SOAP is a good idea, but on every article i read more, i realize that this technology is still young and just experimental (e.g. php 4.x). bart
Re: SOAP and web services
Hi Ric, > > I use mod_perl/apache/soap::lite to create an internal > "application server" > so that I can distribute processing load from the public > webserver. This > also allows me to expose a soap web service to the public if > I wished to > give them direct access to a method on this application server, but of > course they would need a soap client to access this service. > > Do you want to just return an xml to your user, or do you > want to do what I > do which is do internal RPC using SOAP. in my opinion a web service has another great benefit - you can sperate the logic and the front ends. we have here an application running on php/html, and all the logic is inside this scripts, in case of running on another medium/language (like flash or php for plain html) you must copy all the logic - you can call this a nightmare. in this case i think that a solution provides with PRC/SOAP is a good idea, but on every article i read more, i realize that this technology is still young and just experimental (e.g. php 4.x). bart
Re: Cheap and unique
David Jacobs wrote:
>
> Good morning.
>
> Ken is correct - I am not looking for random, I am looking for unique.
>
> Unique and sequenced would be ideal, but it's tricky because if I use
>
> $i++.$IP_address.$parameter.$PID
> {$i is global, $IP_address is the server address, $parameter is a
> parameter that was just passed in, $PID is the apache process ID.}
>
> That's a decent solution, but it's not quite sequential because one
> Apache process could handle far more many requests than another, and so
> a later request could have a lower $i.
>
> Are there any code examples out there that use mod_unique_id.c ? I am
> new to mod_perl and couldn't quite get that. Looking at the code, it
> looks like mod_unique_id does basically the same thing but with a shared
> counter between the different servers.
>
> Also what is the cheapest way to get a datestamp? (I'm assuming it's not
> `date %Y%M%D%H%S`)
>
> --
>
> I'm sorry to be such a noob, but when I've got a little more mod_perl
> under my belt I'll be answering questions up a storm!
It looks like you didn't see my replies to your post. Please read them
first.
http://marc.theaimsgroup.com/?l=apache-modperl&m=102022922719057&w=2
http://marc.theaimsgroup.com/?l=apache-modperl&m=102023259920560&w=2
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: HELP - Trying to get mod_perl and Apache2 working together onWin32....
On Fri, 3 May 2002, Jean-Marc Paulin wrote: > Hi there, > > I am runing Win2000 SP2, and Apache 2.0.35 > > I have managed to build mod_perl (perl Makefile.PL and then nmake) but the > test part fails: Apache crashes (Memory at 0x0018 cannot be read). Bug > Maybe ? It seems so ... However, as you note below, it hang on apache\post: > apache\cgihandlerok > apache\compatok > apache\compat2...ok > apache\conftree..FAILED before any test output arrived > apache\constants.ok > apache\post..*** : > halting tests and yet, on my system, running nmake t/TEST t/apache/post.t has this test running successfully. So it may be a problem in the way the tests are being run via 'nmake test', as opposed to a problem with individual tests. Further to this, if you run 'nmake test' and skip apache/post.t, it then hangs at the next test. > > Ok, I believe that configuration has been tryed before, so I must be missing > a point somewhere. > > Oh, BTW, I have tried the nmake install anyway, but that does not go very > well either as Apache fails to start if I include the PerlModule handler in > the httpd.conf. Myself, and others, have got mod_perl to load OK ... What is your configuration that's failing? Did you copy the generated mod_perl.so to $APACHE/modules? best regards, randy kobes
Re: Cheap and unique
Good morning.
Ken is correct - I am not looking for random, I am looking for unique.
Unique and sequenced would be ideal, but it's tricky because if I use
$i++.$IP_address.$parameter.$PID
{$i is global, $IP_address is the server address, $parameter is a
parameter that was just passed in, $PID is the apache process ID.}
That's a decent solution, but it's not quite sequential because one
Apache process could handle far more many requests than another, and so
a later request could have a lower $i.
Are there any code examples out there that use mod_unique_id.c ? I am
new to mod_perl and couldn't quite get that. Looking at the code, it
looks like mod_unique_id does basically the same thing but with a shared
counter between the different servers.
Also what is the cheapest way to get a datestamp? (I'm assuming it's not
`date %Y%M%D%H%S`)
--
I'm sorry to be such a noob, but when I've got a little more mod_perl
under my belt I'll be answering questions up a storm!
David
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
> > >Does the server load the module that way? > > It's beyond my expertise at this point but my experience would indicate that it does not work this way since I have PerlModule before the PerlSetVar and it works fine. -Fran
[ANNOUNCE] Apache::GuessCharset
Apache::GuessCharset is a PerlFixupHandler to demonstrate bleeding edge perl's powerful encoding detection, thanks to Encode module. It's now going on its way to CPAN, or also on http://bulknews.net/lib/archives/ NAME Apache::GuessCharset - adds HTTP charset by guessing file's encoding SYNOPSIS PerlModule Apache::GuessCharset SetHandler perl-script PerlFixupHandler Apache::GuessCharset # how many bytes to read for guessing (default 512) PerlSetVar GuessCharsetBufferSize 1024 # list of encoding suspects PerlSetVar GuessCharsetSuspects euc-jp PerlAddVar GuessCharsetSuspects shiftjis PerlAddVar GuessCharsetSuspects 7bit-jis DESCRIPTION Apache::GuessCharset is an Apache handler which adds HTTP charset attribute by automaticaly guessing file' encodings via Encode::Guess. CONFIGURATION This module uses following configuration variables. GuessCharsetSuspects a list of encodings for "Encode::Guess" to check. See the Encode::Guess manpage for details. GuessCharsetBufferSize specifies how many bytes for this module to read from source file, to properly guess encodings. default is 512. AUTHOR Tatsuhiko Miyagawa <[EMAIL PROTECTED]> This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO the Encode::Guess manpage, the Apache::File manpage -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Fri, 03 May 2002 09:09:08 -0400
Fran Fabrizio <[EMAIL PROTECTED]> wrote:
: >
: >
: >Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile
: >has solved the problem. I am doing something wrong or the example in the
: >manual page would need to be modified?
: >
: That's odd, I load my module first before setting the secret key (or any
: of the other variables) and it works fine for me.
If the module was loaded when the server sees the "PerlModule" directive
I think this code from Apache::AuthCookieDBI (version 1.18) implies that
variable in particular needs to be set before:
#===
# S E R V E R S T A R T I N I T I A L I Z A T I O N
#===
BEGIN {
my @keyfile_vars = grep {
$_ =~ /DBI_SecretKeyFile$/
} keys %{ Apache->server->dir_config() };
foreach my $keyfile_var ( @keyfile_vars ) {
my $keyfile = Apache->server->dir_config( $keyfile_var );
my $auth_name = $keyfile_var;
$auth_name =~ s/DBI_SecretKeyFile$//;
unless ( open( KEY, "<$keyfile" ) ) {
Apache::log_error( "Could not open keyfile for $auth_name in
file $keyfile" );
} else {
Apache::warn("Adding key for realm $auth_name");
$SECRET_KEYS{ $auth_name } = ;
close KEY;
}
}
}
Does the server load the module that way?
-- fxn
Re: problems setting up Apache::AuthCookieDBI (solved but no fullyunderstood)
> > >Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile >has solved the problem. I am doing something wrong or the example in the >manual page would need to be modified? > That's odd, I load my module first before setting the secret key (or any of the other variables) and it works fine for me. -Fran
Re: Apache::Reload question...
> The question I had regards where to put the 'Apache::Reload' directive. > The documentation suggests something like: > > > > PerlInitHandler Apache::Reload > PerlSetVar ReloadAll Off > > PerlSetVar ReloadTouchFile /tmp/reload_modules > > > > The problem I see in a production machine is that each child process > will see this on the next request, and attempt to reload it's modules. > At that point, you'll loose the shared memory the modules use between > child processes. that sounds right to me > > > > On top of this, the parent process will never get this, so it will never > reload modules in the parent. The next time a new child is forked, on > the first request it receives it will again attempt to reload the > changed modules. Is this correct? Or am I missing something? I'm not sure about that. > > > > The alternative I've used is this: > > > > PerlRestartHandler Apache::Reload > PerlSetVar ReloadAll Off > PerlSetVar ReloadTouchFile /tmp/reload_modules > > > > Then when I've uploaded any changes, I touch the change file, and do an > 'apachectl graceful' to restart the backend. I think this works nicely > because: [snip] > > 2) Doing it in the restart handler means that the parent process reloads > the modules, and all the newly forked children have shared copies. > > > > Can anyone tell me if I'm missing something here? > that sounds right to me. I've not tested it with Apache::Reload specifically, but I did test using Apache::RegistryLoader with a PerlRestartHandler to reload Registry scripts in the parent process on restart and it seemed to work as we both suspected (recipe 17.4 bears the fruit of this labor :) I suspect that it is the same with Apache::Reload unless there is something specific to the reloading logic that prevents it. --Geoff
Re: problems setting up Apache::AuthCookieDBI (solved but no fully understood)
On Thu, 2 May 2002 20:10:15 +0200
F. Xavier Noria <[EMAIL PROTECTED]> wrote:
: I am having problems configuring Apache::AuthCookieDBI and am a bit
: lost, since it seems there is something wrong with the secret key
: file I cannot see, I attach below the configuration in case it can
: help. I have checked the permissions of the file (the server runs
: in by box as "fxn"):
The problem, it seems, was that I was setting the variables used by the
module _after_ loading it, as in the example of its manual page:
PerlModule Apache::AuthCookieDBI
PerlSetVar BuscaWAPPath /
PerlSetVar BuscaWAPLoginScript "/cgi/login.pl"
# These must be set
PerlSetVar BuscaWAPDBI_DSN "dbi:Oracle:BW_CATALOG"
PerlSetVar BuscaWAPDBI_SecretKeyFile "/home/fxn/prj/bw/buscawap/etc/auth.key"
Apache::AuthCookieDBI reads its config variables in a BEGIN block. I
inserted a trace there and keys %{ Apache->server->dir_config() };
returned no variable set via PerlSetVar after that PerlModule directive.
So the hash %SECRET_KEYS, initialized there, had no entries.
Moreover, when I tried to access a protected URL as localhost/docs I was
redirected to /cgi/login.pl as configured (as you see, after PerlModule
as well), which confused me. I suppose this is so because the module
sees the variable at runtime, where the config file has been already
fully read.
Loading Apache::AuthCookieDBI after setting WhatEverDBI_SecretKeyFile
has solved the problem. I am doing something wrong or the example in the
manual page would need to be modified?
-- fxn
HELP - Trying to get mod_perl and Apache2 working together on Win32....
Hi there,I am runing Win2000 SP2, and Apache 2.0.35I have managed to build mod_perl (perl Makefile.PL and then nmake) but thetest part fails: Apache crashes (Memory at 0x0018 cannot be read). BugMaybe ?Ok, I believe that configuration has been tryed before, so I must be missinga point somewhere.Oh, BTW, I have tried the nmake install anyway, but that does not go verywell either as Apache fails to start if I include the PerlModule handler inthe httpd.conf.Any hints ?Thanks a lotJM= STDOUT D:\Perl\PerlModules\modperl-2.0>nmake testMicrosoft (R) Program Maintenance Utility Version 6.00.8168.0Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd "src/modules/perl" && NMAKEMicrosoft (R) Program Maintenance Utility Version 6.00.8168.0Copyright (C) Microsoft Corp 1988-1998. All rights reserved. D:\Perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean D:\Perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST*** : cannot build c-modules without apxsD:\PROGRA~1\APACHE~1\Apache2/bin/Apache.exe -dD:/Perl/PerlModules/modperl-2.0/t -fD:/Perl/PerlModules/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADSusing Apache/2.0.35 (winnt MPM)waiting for server to start: 00:00[Fri May 03 08:39:05 2002] [info] 12Apache:: modules loaded[Fri May 03 08:39:05 2002] [info] 5 APR:: modules loaded[Fri May 03 08:39:05 2002] [info] base server + 6 vhosts ready to run tests[Fri May 03 08:39:05 2002] [info] 11 Apache:: modules loaded[Fri May 03 08:39:05 2002] [info] 5 APR:: modules loaded[Fri May 03 08:39:05 2002] [info] base server + 6 vhosts ready to run testswaiting for server to start: 00:01END in modperl_extra.pl, pid=5084END in modperl_extra.pl, pid=5084END in modperl_extra.pl, pid=5084END in modperl_extra.pl, pid=5084END in modperl_extra.pl, pid=5084END in modperl_extra.pl, pid=5084END in modperl_extra.pl, pid=5084waiting for server to start: ok (waited 1 secs)server zola.dev.net:8529 startedserver zola.dev.net:8530 listening (TestDirective::perlmodule)server zola.dev.net:8531 listening (TestDirective::perlrequire)server zola.dev.net:8532 listening (TestProtocol::echo)server zola.dev.net:8533 listening (TestProtocol::echo_filter)server zola.dev.net:8534 listening (TestProtocol::eliza)server zola.dev.net:8535 listening (TestFilter::input_msg)apache\cgihandlerokapache\compatokapache\compat2...okapache\conftree..FAILED before any test output arrivedapache\constants.okapache\post..*** :halting testsNMAKE : fatal error U1058: terminated by userStop.
Re: problems setting up Apache::AuthCookieDBI
On Thu, 02 May 2002 15:22:59 -0400 Fran Fabrizio <[EMAIL PROTECTED]> wrote: : Do you have this in httpd.conf (or mod_perl.conf) : : PerlSetVar BuscaWAPDBI_SecretKeyFile /home/fxn/prj/bw/buscawap/etc/auth.key : : ? I have all mod_perl-related things in mod_perl.conf, and httpd.conf ends with this line: Include /home/fxn/prj/bw/buscawap/etc/mod_perl.conf Could that matter? -- fxn
Apache::Reload question...
I've got a "reality check" question for people to see that I'm not missing something obvious with our Apache::Reload mod_perl setup. We've recently install Apache::Reload at our site in production and it's working great. In what is probably not the best 'software engineering' style, we've been known to upload several small patches in a single day and used to have to do short restarts to integrate the new code. We now use Apache::Reload instead. Rather than putting 'use Apache::Reload' in each of our modules, I've created a touch file, which after looking through the Apache::Reload code, I noted that you could put a list of modules into it which would be reloaded. On top of this, we use mod_accel as a front end to our mod_perl backend. This combination seems to work great as well for anyone curious. The question I had regards where to put the 'Apache::Reload' directive. The documentation suggests something like: PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadTouchFile /tmp/reload_modules The problem I see in a production machine is that each child process will see this on the next request, and attempt to reload it's modules. At that point, you'll loose the shared memory the modules use between child processes. On top of this, the parent process will never get this, so it will never reload modules in the parent. The next time a new child is forked, on the first request it receives it will again attempt to reload the changed modules. Is this correct? Or am I missing something? The alternative I've used is this: PerlRestartHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadTouchFile /tmp/reload_modules Then when I've uploaded any changes, I touch the change file, and do an 'apachectl graceful' to restart the backend. I think this works nicely because: 1) The mod_accel front end will buffer any long file uploads, and any long file downloads. So the actual length of connections from the frontend to the backend is only as long as it takes to process the request and tunnel the data betwen the front->back or back->front. Thus the 'graceful' restart only ever takes a few seconds, and no connections are ever lost, only blocked for a few seconds at the most (the length of the longest request to process). 2) Doing it in the restart handler means that the parent process reloads the modules, and all the newly forked children have shared copies. Can anyone tell me if I'm missing something here? Rob
HELP !!! Trying to get mod_perl and Apache2 working together on Win32....
Hi there, I am runing Win2000 SP2, and Apache 2.0.35 I have managed to build mod_perl (perl Makefile.PL and then nmake) but the test part fails: Apache crashes (Memory at 0x0018 cannot be read). Bug Maybe ? Ok, I believe that configuration has been tryed before, so I must be missing a point somewhere. Oh, BTW, I have tried the nmake install anyway, but that does not go very well either as Apache fails to start if I include the PerlModule handler in the httpd.conf. Any hints ? Thanks a lot JM = STDOUT D:\Perl\PerlModules\modperl-2.0>nmake test Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd "src/modules/perl" && NMAKE Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. D:\Perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST -clean D:\Perl\bin\perl.exe -Iblib\arch -Iblib\lib t/TEST *** : cannot build c-modules without apxs D:\PROGRA~1\APACHE~1\Apache2/bin/Apache.exe -d D:/Perl/PerlModules/modperl-2.0/t -f D:/Perl/PerlModules/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREA DS using Apache/2.0.35 (winnt MPM) waiting for server to start: 00:00[Fri May 03 08:39:05 2002] [info] 12 Apache:: modules loaded [Fri May 03 08:39:05 2002] [info] 5 APR:: modules loaded [Fri May 03 08:39:05 2002] [info] base server + 6 vhosts ready to run tests [Fri May 03 08:39:05 2002] [info] 11 Apache:: modules loaded [Fri May 03 08:39:05 2002] [info] 5 APR:: modules loaded [Fri May 03 08:39:05 2002] [info] base server + 6 vhosts ready to run tests waiting for server to start: 00:01END in modperl_extra.pl, pid=5084 END in modperl_extra.pl, pid=5084 END in modperl_extra.pl, pid=5084 END in modperl_extra.pl, pid=5084 END in modperl_extra.pl, pid=5084 END in modperl_extra.pl, pid=5084 END in modperl_extra.pl, pid=5084 waiting for server to start: ok (waited 1 secs) server zola.dev.net:8529 started server zola.dev.net:8530 listening (TestDirective::perlmodule) server zola.dev.net:8531 listening (TestDirective::perlrequire) server zola.dev.net:8532 listening (TestProtocol::echo) server zola.dev.net:8533 listening (TestProtocol::echo_filter) server zola.dev.net:8534 listening (TestProtocol::eliza) server zola.dev.net:8535 listening (TestFilter::input_msg) apache\cgihandlerok apache\compatok apache\compat2...ok apache\conftree..FAILED before any test output arrived apache\constants.ok apache\post..*** : halting tests NMAKE : fatal error U1058: terminated by user Stop.
Re: Cheap and unique
On Wednesday, May 1, 2002, at 06:46 AM, OCNS Consulting wrote: > Of course "srand" seeds "rand". And yes, it is a good way to generate > random numbers for a one time application RUN. The original poster is not looking for "random", he's looking for "unique". These are in many ways *opposite* requirements, as the only reliable way to get unique IDs is to use a very deterministic procedure - a simple iterator is one of the easiest and best. If you have the additional requirement that the unique values shouldn't be easily *guessable*, that becomes a very hard problem, precisely because "random" and "unique" are such poor friends. Usually people just cheat by generating a large random ID such that the probability of it being already-used is low, and then they check all the previous IDs to make sure. -Ken
