RE: PerlAuth DB configuration.
I end of with 4 DB connections for each web server thread (2 for Authen
and 2 for Authz). After a short time of inaction (about 30 secs), the
web server makes a new child, and the 4 DB connections just sit there.
Useless. And 4 more are created for the new thread.
Now this is starting to look a little inefficient, and I was wondering
if anyone who has any experience with this kind of problem could give me
a few pointers; some different (better) ideas on how to solve the problem.
I had a very similar problem using database authentication, a very useful reply I
received mentioned extra arguments for the ( not terribly well documented )
DBI-connect call
DBI-connect('dbi:mysql:dbname=db','user','pass',
{attr=value},
undef,
'connect');
This menas that for your authentication connections, Apache::DBI::connect is not used
as the connect method, but the "vanilla" connect is. So you will not have the (4)
connections lying around after their use...
I am assumimg that it is ok to fiddle with setup of the PerlAuth module to make these
changes...
Finally this will not help you at all with the elapsed time issues surrounding the
need for 4 connections ... but good luck
Mark
Out Of Memory While Running Apache_OWA
Dear list,
I am getting this error "Out of memory during large request for - bytes at OWA.pm
line 347" in the Apache error log when attempting to run any Oracle PLSQL procedure.
Even trivial procedures like :
procedure hello is
begin
htp.p('hello');
end;
give the above error.
There seems to be quite a lot of free memory available on the server. Is there some
mod_perl parameter I need to tweek ?
I am running Apache 1.3.12/Mod_perl 1.24/OWA-0.7 on HPUX 11.00
Thanks
Mark
RE: Disable/Enable Persistant Connections On Demand
Thanks Aaron,
The altered connect call was exactly what I was after...( and it worked as expected -
no more database sessions for the authenticating users ).
A little more background may explain the odd ( ? ) construction.
I wanted to make the design easily portable to different databases - so either I had
to code around the different ways that they store usernames and passwords, or create
my own user attributes table ( 2nd is not such a bad idea ). However the user
population already has database accounts for other stuff, so I thought I would
"leverage" off that( bad marketing speak alert just then it portrays the idea ok).
The security question I have currently ignored as the webapp is used on a closed lan,
however I plan to alter this by ensuring that the page that accepts username, passwd
is only callable via https. It will then ( optinally ) switch back to http when
redirecting to the continuation page
Thanks for your help
Mark
-Original Message-
From: Aaron [SMTP:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 1:55 AM
To: Mark Kirkwood
Cc: [EMAIL PROTECTED]
Subject: Re: Disable/Enable Persistant Connections On Demand
at a time earlier than now, Mark Kirkwood wrote:
Dear List,
This may be a stupid question... but anyway...
no way. Apache::DBI and DBI kind of cheat and automagically make stuff
happen. it's very cool, but it can also be hard to extend or modify for
specific situations.
This works great, because most of the web site uses a "generic" user to connect to
the database. However I do authentication via the database ( i.e : attempt a
connection using supplied user/pwd and if so set a cookie and continue on using the
generic user/pwd) , and these "once only" connections persist too.
would it be better to query a table, maybe a system table, to verify login?
i assume you are using ssl to encrypt these user/password pairs, but it
doesn't seem as though you have a need for a connection.
of course, it is probably just a political situation where the users who are
logging in already have accounts, you don't have access to system tables b/c
the dba doesn't want let you and so on.
*** i did not test i am not recommending i am not responsible ***
anyway... you could probably just get away with calling connect like this:
DBI-connect('dbi:mysql:dbname=db','user','pass',
{attr=value},
undef,
'connect');
which will set $connect_meth to it's default value
my $connect_via = "connect";
and set connect_meth to 'connect' and not 'Apache::DBI::connect'
$connect_via = "Apache::DBI::connect";
so that when this code runs you are good to go without Apache::DBI.
$drh-$connect_meth($dsn, $user, $pass, $attr)
he he. ugh. take a look at the DBI.pm source, you'll see what's going on.
aaron
let me know what happens
Thus after 100 folk have logged in there are 100 ( unused ) connections. I would
like to have these authentication once only connection not persist.
Is there any way to "by default" use persistent connections but on occasions not ?
Thanks in advance for your help
Mark
Disable/Enable Persistant Connections On Demand
Dear List, This may be a stupid question... but anyway... I am using mod_perl with persisent database connections enabled via Apache::DBI. This works great, because most of the web site uses a "generic" user to connect to the database. However I do authentication via the database ( i.e : attempt a connection using supplied user/pwd and if so set a cookie and continue on using the generic user/pwd) , and these "once only" connections persist too. Thus after 100 folk have logged in there are 100 ( unused ) connections. I would like to have these authentication once only connection not persist. Is there any way to "by default" use persistent connections but on occasions not ? Thanks in advance for your help Mark
RE: Building modperl as a DSO in Apache_1.3.12
I have not tried to build mod_perl as a DSO, but encountered these -Wl, +n flags during static module build of mod_perl 1.24 + Apache 1.3.12 on HPUX 11.00 - I edited them out of the Makefile... not terribly elegant but it did work Mark -Original Message- From: Kairam, Raj [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, August 23, 2000 5:16 AM To: '[EMAIL PROTECTED]' Cc: Kairam, Raj Subject: Building modperl as a DSO in Apache_1.3.12 I am trying to build modperl ( mod_perl-1.24 ) as DSO in to Apache ( apache_1.3.12 ) on a host running HP-UX 11.0 Uncompressed and untarred the source in two parallel directories. /opt/apache_1.3.12 /opt/mod_perl-1.24 Created a file in /opt directory that contained options to be passed on to Makefile.PL mod_perl.txt I am using the HP supplied ANSI C Compiler. In /opt/mod_perl-1.24 directory ran 'perl Makefile.PL `cat ../mod_perl.txt` . It went OK. ran 'make' and I am getting the following error ld: Unrecognized argument: -Wl -E ld: Usage: ld flags ... files ... The output of make is captured in the following attachment The last line in the above file indicates the 'ld' command and the arguments '-Wl -E' are in that long line halfway. When I look at the generated Makefile, I see the two lines CCCDLFLAGS = +z CCDLFLAGS = -Wl, E -Wl,-B,deferred How can I avoid this error ?. Any of you working with mod_perl on a HP-UX box encountered this situation ?. Any help would be greatly appreciated. Thanks
Install of mod_perl with perl+static Oracle DBD requires hacking ofApache configure process on HPUX 11
Hi, Thought ( or hoped ) this might be useful to any folk building on the HPUX 11 platform : Attempting to do this build causes Apache configure to fail with undefined symbols at sanity compile. This may be specific to the version of Oracle ( 8.1.6 ) that I used, as it seems to have several apparently vital object files not installed into libraries, just "lying around" there... In addition the mod_perl configure process writes -Aa -D_HPUX_SOURCE into various cflags . This causes the Apache make process to fail complaining about -Aa -D_HPUX_SOURCE +e or -Ae being required ( something about long integers ) By being a bit brutal with the Apache src/Configure script and then running a ( small ) sed script on all Makefiles I managed to get it to build just fine - but it took a while to work out what was going on... ( not being a "configure" or perl build expert ) Details are as follows : All builds were done using HP's ANSI C compiler Perl 5005_03 Build -- I installed perl + DBI-1.13 + DBD-Oracle-1.06. this required a STATIC build for DBD-Oracle the version of Oracle is 8.1.6 the os is HPUX 11 ( 32-bit ) mod_perl 1.24 build - 1 perl Makefile.PL APACHE_SRC=apache src DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 2 make 3 make install Apache 1.3.12 build --- 1 ./configure --prefix=prefix --activate-module=src/modules/perl/libperl.a this fails with many undefined symbols , this was due to "perl -MExtUtils::Embed -e ldotps" ( run by Configure ) removing the following object files from the library string : oracle_home/lib/nautab.o oracle_home/lib/naeet.o oracle_home/lib/naect.o oracle_home/lib/naedhs.o oracle_home/rdbms/lib/kpudfo.o 2 cp src/Makefile.config to src/Makefile.config.new 3 edit the .new adding in the libraries to LIBS1 that "perl -MExtUtils::Embed -e ldotps" ( in mod_perl.config.sh ) removes - see 1 4 edit src/Configure getting it to cp Makefile.config.new over Makefile.config just before the sanity compile 5 run configure again 6 run a sed script on each Makefile in the apache tree to change -Aa to -Ae ( sed 's/-Aa/-Ae/g' file1 file2 ) 7 run make 8 run make install 9 edit prefix/conf/httpd.conf to enable the mod perl bits 10 edit prefix/conf/httpd.conf to know about ORACLE_HOME ( SenEnv ORACLE_HOME oracle home ) Cheers Mark P.s : I know people are going to say " Use GCC and it will be ok" I did try this on a ( different ) HPUX 11 box and still Oracle-DBD would not run if built dynamically - it built ok but the loader refused to load Oracle.sl, something about threaded library... ! no such issue arises on HPUX 10.20 and Oracle 8.0.5...)
