Re: $r->args troubles...
It goes like this:
my $r = Apache->request;
my $apr = Apache::Request->new($r);
--
Doug Kyle - Information Systems
Grand Rapids Public Library
"We're superheros man, we don't have time to be charming . . . we're public
servants, not glamour boys" - The Tick.
Jason Murphy wrote:
> Dear Mod_Perl'lers
>
> I hate to bug the list with this simple problem, but I am at my wits end. I
> have The Good Book (Aka: Apache Modules with Perl and C. Aka: The Eagle
> Book) but have some questions that are just killing me.
>
> I would like to do something like the program on page 104 - 110 and also
> page 130 - 135 of The Eagle book. For those of you not blessed with this
> book, I am trying to recover the parameter from a GET request. Below is my
> code I correctly using, but my problem is the Apache::Request and
> Apache::Constant are not being found or used or whatever is the error (Error
> posted below).
>
> Some notes, I have tried adding "use Apache::Constants qw(:common)" but it
> also returns the same error. I have also replaced the last line with "my
> ($FirstInfo, $SecondInfo) = split /=/, $r->args;" with no success either. I
> have those modules installed, and I forced reinstalled them to make sure
> along with Bundle::Apache.
>
> If anyone could point me to a really good example of the r->args and GET
> requests I would really appreciate it.
>
> <---My Error--->
>
> Can't locate object method "new" via package "Apache::Request" at
> ./find_player.pl line 10.
>
> <---MY CODE--->
>
> use strict;
>
> use Apache::Request ();
> use CGI qw(:standard);
> use DBI;
>
> my $r = new Apache::Request; <---Where the error appears
> my $dbh ||= DBI->connect('dbi:mysql:Action', 'login', 'password') || die
> "Could not open Database: ";
>
> my ($person_id, $name, $totalkills, $totalkilled);
> my %arguments = $r->args;
>
> --
> Jason Murphy
> System Administrator
> Lawinfo.com
> 1-800-397-3743 ex: 133
Re: Site unique MAC secret
Matt Sergeant wrote: > On Wed, 09 Feb 2000, Doug Kyle wrote: > > > > What about generating some value from the MAC address of the server's > > NIC(s)? > > ifconifg ether, or arp will return MAC > > addresses. > > Doh! Just realised that producing a secret from something that's totally > *not* a secret is really dumb :) > > Next option? :) > > -- > > > Details: FastNet Software Ltd - XML, Perl, Databases. > Tagline: High Performance Web Solutions > Web Sites: http://come.to/fastnet http://sergeant.org > Available for Consultancy, Contracts and Training. Well, that's why I said "generating some value from", and you asked for something not affected by software upgrades. Since you're trying to grab such info from varous boxes with various OSs, how secret can you get? Interesting, but not really mod_perl, although I'm curious to know what you come up with. I'm certainly not an expert on such matters, but I've included an authoratative quote on the subject below. Good Luck. "Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin." - - John Von Nuemann
Re: Site unique MAC secret
Matt Sergeant wrote:
> Anyone got any good ideas on picking up a site-unique MAC secret. What I
> need is something that won't change over server software upgrades, but
> isn't hard coded. At the moment I've picked:
>
> use Config;
> my $secret = Config->myconfig;
>
> (output of perl -V)
>
> But it's sensitive to perl upgrades. I'm pretty certain there must be
> _something_ I can use. I'm thinking perhaps of join('', `ls -la
> $some_dir_created_on_install`), but again, the sysadmin could easily
> inadvertently touch something in that dir.
>
> --
>
>
> Details: FastNet Software Ltd - XML, Perl, Databases.
> Tagline: High Performance Web Solutions
> Web Sites: http://come.to/fastnet http://sergeant.org
> Available for Consultancy, Contracts and Training.
What about generating some value from the MAC address of the server's
NIC(s)?
ifconifg ether, or arp will return MAC
addresses.
--
Doug Kyle - Information Systems
Grand Rapids Public Library
"We're superheros man, we don't have time to be charming . . . we're public
servants, not glamour boys" - The Tick.
Re: Proxy example in eagle book does not work
Jason Bodnar wrote:
> On 19-Jan-00 Doug MacEachern wrote:
> > On Fri, 14 Jan 2000, Jason Bodnar wrote:
> >
> >> A line in the proxy example of the eagle book on page 380 does not seem to
> >> work
> >> (entirely):
> >>
> >> The line:
> >>
> >> $r->headers_in->do(sub {$request->header(@_);});
> >
> > what if you change that to:
> >
> > $r->headers_in->do(sub {$request->header(@_); 1});
> >
> > ?
>
> That sets all the headers including Connection which is a problem if it's
> Keep-Alive. It probably needs to be something like:
>
> $r->headers_in->do(sub {return 1 if $_[0] eq 'Connection';
> $request->header(@_); 1});
>
> ---
> Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems
>
> That boy wouldn't know the difference between the Internet and a hair net. --
> Jason Bodnar
I'm running a mod_perl proxy module similar to the one in the book. I'm curious
why you say
Keep-Alive is a problem? Is your concern performance because of timeout
settings, or something else?
--
Doug Kyle - Information Systems
Grand Rapids Public Library
"During my service in the United States Congress, I took the initiative in
creating the Internet."
-- Al Gore
Re: www.modperl.com
"Paul J. Lucas" wrote: > On Sun, 30 Jan 2000, Gunther Birznieks wrote: > > > Another question is why www.modperl.com at all? Why not store the material as > > part of the main mod_perl site? Or off of the apache site? > > > > I guess I am just not sure why the site which seems to be centered around the > > book is its own site anyway? > > Despite the fact that it's an amazing book, I have to agree > with his comments. IMHO, www.modperl.com, if it exists, should > be about the module (and not the book) just like www.modssl.org > is about the module. > > I agree with the request for an errata section. I don't agree with the comments about different sites and organization of mod_perl info. All the mod_perl sites I use link to the others - I don't care if I'm changing sites from page to page. Carping about the domain modperl.com being about a book about the Apache module rather than the module itself is like arguing about what the meaning of is is.
Re: problems with Apache::DBI
I have had the same error with mysql, which really had nothing to do with Apache::DBI. The problem was the shared library file, the .so, was not installed in the correct directory. Various ways exist fix this including recompiling the DBD module with -static, or, more simply, copying the .so file into the shared libraries directory. I hope this helps. -- Doug Kyle - Information Systems Grand Rapids Public Library "Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light." - Dr. Egon Spengler "Cere M. Davis" wrote: > I am trying to get the DBI::Ingres stuff to work with Apache::DBI. > > Once the server tries to open the inital connections through the > startup.pl file with the "Apache::DBI->connect_on_init" command it throws > an error message like this: > > 168 Apache::DBI PerlChildInitHandler > [Fri Jan 7 12:46:35 2000] [error] install_driver(Ingres) failed: Can't > load > '/uns/mind/usr/local/perl5/lib/site_perl/5.005/alpha-dec_osf/auto/DBD/Ingres/Ing > res.so' > for module DBD::Ingres: dlopen: cannot load > /uns/mind/usr/local/perl5/lib/site_perl/5.005/alpha-dec_osf/auto/DBD/Ingres/Ingr > es.so > at /uns/mind/usr/local/perl5/lib/5.00503/alpha-dec_osf/DynaLoader.pm > line 169. > > at (eval 15) line 3 > > at /uns/mind/usr/local/perl5/lib/site_perl/5.005/Apache/DBI.pm line 138 > > in the error_log when I run httpsd -X (single thread mode). > > I can run the DBI drivers to ingres with no problems outside > > of Apache just not with the Apache mod_perl stuff. > > Does anyone know what's going on here? I expect that DynaLoader > > is used to load the DBI standalone stuff - and that works fine - > > so why is it that DynaLoader would have trouble loading Ingres.so > > when requested through Apache::DBI? > > -Cere > > * > Cere Davis * > Systems Administrator * > MCIS University of Washington * > 206.221.4717* > [EMAIL PROTECTED] * > *
