Re: SSI Lost with Mod Perl?

[Perrin Harkins]

> I've given Filter and SSI a shot according to the perldocs.
>
> It didn't work.  I stated to hhack on some of the problems, which first
involved
> in the make install depositing them in the wrong diretory, and then they
SSI
> needed use Apache::Filter statements added.
>
> Finally, Filter cam back with an error that something or other $r wasn't a
> hash reference, which would not be a quick fix.
>
> So I've sort of hacked up my own little SSI for the time being and
> deposited it in the modules.

Sorry it didn't work for you.  I've never used Filter, but I used
Apache::SSI with great success.  You weren't trying to use Filter with
mod_include (i.e. not Apache::SSI) were you?

Anyway, there's another CPAN module you can use called CGI::SSI_Parser which
might fit your needs.

> I'm definetely bathing in a Brooklyn Larger Bath when this is done.

I prefer the IPA, taken orally.

- Perrin

Re: mod_perl install

[Randy Kobes]

On Tue, 26 Jun 2001, Purcell, Scott wrote:

> Hello,
> I am trying a new install of mod_perl on my NT box here which is running
> apache. The last install I used Ron Savages NT binary distribution. And it
> was easy to install and worked. But I feel that I need to install mod_perl
> from scratch (I have to begin supporting it here at my shop). I downloaded
> the cpan package, gziped and extracted tar.  The install directions for NT
> look a little gray. Maybe there is a step by step guide somewhere? If anyone
> knows I would appreciate.
>
> Thanks
>
> Scott Purcell

Do you mean to compile it on your own? You'll have to have Visual C++ 6
on your system (assuming you're using ActivePerl), and you should
check that your Perl is configured properly to work with it by
compiling some simpler XS-based module. If that's OK, read through
INSTALL.win32 (if it's a little unclear, patches are welcome ...) -
basically one first compiles and installs Apache (or get a
binary distribution that contains the header and lib files) and
then does

perl Makefile.PL APACHE_SRC=\Apache\Sources INSTALL_DLL=\Apache\modules
nmake
nmake test
nmake install

where "\Apache\Sources" are where the Apache sources are and
"\Apache\Modules" is where you want to put the mod_perl.so dll.

best regards,
randy kobes

RE: missing mtime in request rec?

[Geoffrey Young]

I did some more digging...

it seems that any request that is served by the default Apache content
handler is ok - only those that are processed by mod_perl (well, anything
that isn't the default) seem to be affected.

this doesn't seem quite right to me - if Apache can determine r->filename
and stat the file for r->finfo, then it ought to be setting r->mtime, right?
so maybe somewhere in http_request.c/get_path_info there needs to be a fix?

or maybe I'm missing some history here...

--Geoff

-Original Message-
From: Geoffrey Young
To: '[EMAIL PROTECTED]'
Sent: 6/26/01 2:18 PM
Subject: missing mtime in request rec?

hi all...

  can somebody check the results of $r->mtime for me?  something like

PerlCleanupHandler 'sub {warn "*** time***",
Apache::Util::ht_time(shift->mtime)};'

ought to do the trick.  I have yet to see a case today where that reads
other than the start of the epoch.  some minmial searching through the
Apache code seems to indicate that r->mtime is never populated in the
request record, but I am most certainly missing something...

I was really trying to get $r->set_last_modified() to work as
documented,
then traced it back to an empty $r->mtime...

thanks...

--Geoff

Re: mod_perl install

[Ron Savage]

Scott

See below.

Cheers
Ron  Savage
[EMAIL PROTECTED]
http://savage.net.au/index.html

- Original Message - 
From: Purcell, Scott <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 27, 2001 8:12 AM
Subject: mod_perl install


> Hello,
> I am trying a new install of mod_perl on my NT box here which is running
> apache. The last install I used Ron Savages NT binary distribution. And it

I can't tell from this exactly which 'last install' you used!

I understand your concerns though.

If you go here http://savage.net.au/Perl/Html/configure-apache.html
you'll have all the info you need to install the latest Apache V 1.3.20 and mod_perl V 
1.25_01-dev.

pass cookie along with the POST request?

[Islandman]

The small code segment below will get the contents of a web page using a
perl script. The site I want to access wants a cookie sent as well. 

There is a cookie for this site is in my ~/.netscape/cookies file.  How
do I change the code below so I can fake pass the cookie along with the
POST request?

Will I need to modify the format of what is in ~/.netscape/cookies?

--
use strict;
use LWP::UserAgent;
use HTTP::Request::Common;
my $URL = 'http://www.yahoo.com';
my $ua = LWP::UserAgent->new;
my $response = $ua->request(POST "$URL");

if ($response->is_success) {
   print $response->content;
} else {
   print "Bad luck this time\n";
}

Thanks!
 -Brian

mod_perl install

[Purcell, Scott]

Hello,
I am trying a new install of mod_perl on my NT box here which is running
apache. The last install I used Ron Savages NT binary distribution. And it
was easy to install and worked. But I feel that I need to install mod_perl
from scratch (I have to begin supporting it here at my shop). I downloaded
the cpan package, gziped and extracted tar.  The install directions for NT
look a little gray. Maybe there is a step by step guide somewhere? If anyone
knows I would appreciate.

Thanks

Scott Purcell

Re: RFC: new module: Apache::FakeEnv

[Andrew Ho]

Hello,

GY>there was a more advanced Apache::FakeRequest floating around somewhere...

TK>I knew this script (it was posted here, too), and while it is definitly
TK>better than Apache::FakeRequest, it still doesn't handle dir_config
TK>calls.

That's my script. The caveat is, that it will *never* be possible to
simulate mod_perl entirely--that would be so complex that you might as
well have everybody run a single-child Apache with mod_perl instead.

We do this for our mod_perl developers. There is perl -wc for simple
syntax checking, the apr script for running dead-simple mod_perl scripts
for debugging, and then everybody runs a small Apache against their own
conf file to test stuff.

GY>any chance you can expand the existing Apache::FakeRequest
GY>and offer a patch?

TK>Sure I could try to patch Apache::FakeRequest, but I think the
TK>changes are quite fundamental. What to the mantainers of
TK>Apache::FakeRequest (or mod_perl) think of this?

I agree that the changes are quite fundamental. I haven't really found
Apache::FakeRequest terribly useful. It doesn't really make debugging
mod_perl handlers any easier by itself. Rather than patching it, perhaps
you could subclass it or replace it altogether.

TK>Is it possible to subclass mod_perl or Apache::Request from
TK>outside of Apache (i.e. in a plain perl environment) ?

Nope, as you guessed. :(

TK>If not (which it seems to be), what would be the best way to
TK>implement all (more or less..) mod_perl methods and subclasses
TK>(Apache::Request et.al) ? Can one use the C code that mod_perl
TK>is based on? (Well, I guess I can't because I've never done any real
TK>C coding ...) ?

The "best" way to do it would probably just be to write code for 'em all.
I think many web developers have many of the pieces lying around anyway
from web client libraries. The hard work is in faking out everything and
matching the API. But then you run into the problem that the code you're
making isn't really mod_perl and Apache anyway.

I'd say that having something "pretty good" for doing fast testing of
mod_perl scripts is good, but you'll never be 100% mod_perl unless you're
using mod_perl itself. :)

Humbly,

Andrew

--
Andrew Ho   http://www.tellme.com/   [EMAIL PROTECTED]
Engineer   [EMAIL PROTECTED]  Voice 650-930-9062
Tellme Networks, Inc.   1-800-555-TELLFax 650-930-9101
--

Re: Reload Modules on NT Apache

[Tim Gardner]

>I am using mod-perl, and I am in the development stages of coding. Each time
>I make a code change to a module, I must restart apache. I know there must
>be docs for this, but I cannot find them from the apache web site. Could
>someone assist me in finding those? Or if someone knows of a simple way to
>accomplish this task, please advise.

Scott,

There is a module called StatINC which is supposed to solve this 
problem.  I've had trouble with it but it is probably something I am 
doing wrong as I never fully investigated.

Alternatively, depending what you are doing, you might be able to add 
the packages to the script which would otherwise "use" them during 
development so that they get recompiled every time.  This wouldn't 
work very well if you are sharing the modules between a bunch of 
programs, obviously, but if you are trying to debug something it 
might help.

Tim

[ANNOUNCE] Apache::DnsZone 0.2

[Thomas Eibner]

Hi Folks,

The URL

http://dnszone.org/dist/Apache-DnsZone-0.2.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/T/TH/THOMAS/Apache-DnsZone-0.2.tar.gz
  size: 47032 bytes
   md5: 8cc9ef56ae9c1ef481801c01b2212d00

What's new:

 and PTR records are now supported.
Much work has been done on the Oracle and Postgresql parts of DnsZone,
thanks to Michael Legart.
Portuguese Brazilian support by Felipe Tonioli
Minor bugfixes.

--

DnsZone is a webbased multiuser interface for managing dns zones in
Bind running under Apache/mod_perl.
   
   
Specifics: 
   
   
   
DnsZone allows users to change their own zones without actually having
access to the nameserver on which their zone is located. It is a
multiuser application where each user will have his/her own login and
password. From the interface you can add, update and delete individual
records for the domain you are managing. Records are instantly updated
in the nameserver and changes will be visible instantly.
Currently DnsZone supports MySQL|Oracle|Postgresql as the backend
database. Oracle and Postgresql support is still experimental and is
likely a bit broken.
Types of dns records currently supported: SOA, A, CNAME, MX, NS, TXT.
The user interface supports multiple languages and currently comes with
English, Danish, German, Swedish, Italian and French language files.
The user interface can be tailored to fit your needs by the use of
templates (using CGI::FastTemplate).

How:

It uses the features of RFC2136 (Dynamic Updates) to maintain the zones
in a nameserver running BIND. This means that it does not need to have
anything running on the actual nameserver other than BIND itself.
   
   
Website: http://www.dnszone.org/   
   
   
   
Demo: http://demo.dnszone.org/ (Please keep the language in English so
others can read it too)
   
   
Download: http://www.dnszone.org/dist/ 
   


-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

Reload Modules on NT Apache

[Purcell, Scott]

Hello,
I am using mod-perl, and I am in the development stages of coding. Each time
I make a code change to a module, I must restart apache. I know there must
be docs for this, but I cannot find them from the apache web site. Could
someone assist me in finding those? Or if someone knows of a simple way to
accomplish this task, please advise. 

Thanks
Scott Purcell

missing mtime in request rec?

[Geoffrey Young]

hi all...

  can somebody check the results of $r->mtime for me?  something like

PerlCleanupHandler 'sub {warn "*** time***",
Apache::Util::ht_time(shift->mtime)};'

ought to do the trick.  I have yet to see a case today where that reads
other than the start of the epoch.  some minmial searching through the
Apache code seems to indicate that r->mtime is never populated in the
request record, but I am most certainly missing something...

I was really trying to get $r->set_last_modified() to work as documented,
then traced it back to an empty $r->mtime...

thanks...

--Geoff

Re: push_handlers and PerlAuthenHandler troubles [second try]

[Bolt Thrower]

Rodney Broom wrote:
> 
> > 
> >   AuthType Apache::AuthTicket
> >   AuthName HomeIntranet
> >   PerlAuthenHandler Intranet::CheckSiteAuthen
> >   #PerlAuthenHandler Apache::AuthTicket->authenticate
> >   PerlAuthzHandler Apache::AuthTicket->authorize
> >   require valid-user
> > 
> 
> 
> mod_auth supplies the "Auth*" dirrectives. Since he sees 'require
> valid-user', he's looking for the rest of the Auth* directives.
> Specifically, "AuthUserFile".

Thanks for the reply Rodney.  Anyway, I guess I just don't understand
why I'm getting the user file error with the above config, but if I
uncomment the PerlAuthenHandler Apache::AuthTicket->authenticate line,
it works as it should (gives me a login page).  All I want to do is have
authentication start at my Intranet::CheckSiteAuthen module, then hop to
the AuthTicket module if some condition is met.  If I uncomment both
PerlAuthenHandler Intranet::CheckSiteAuthen
PerlAuthenHandler Apache::AuthTicket->authenticate
lines, I get my login page, but authentication goes to
Apache::AuthTicket->authenticate regardless of what happens in
Intranet::CheckSiteAuthen.

Thanks,
-- 
Steve Chadsey <[EMAIL PROTECTED]>

Re: Persistant data accross processes

[Joshua Chamas]

> Rodney Broom wrote:
> 
> Hi all,
> 
> I'd like a way to store complex data structures across Apache processes. I've looked 
>at Apache::DBI for an example: my tests say that he has to
> create a new dbh for every process. I've looked at IPC::Shareable, but it has to 
>copy data. Meaning that I can only have a certain amount
> of complexity to my data structures.
> 

I you like MLDBM, I created MLDBM::Sync for the purpose
of using in Apache like environments.  MLDBM::Sync creates
a file locking wrapper around underlying dbms like DB_File,
GDBM_File, or SDBM_File.

Try the bench/bench_sync.pl on your platform for some comparison
numbers.  Below are the numbers I get on my platform, 
Linux PIII-450x2

--Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks <- Web Link Checking  Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

=== INSERT OF 50 BYTE RECORDS ===
  Time for 100 writes + 100 reads for  SDBM_File  0.15 seconds 
12288 bytes
  Time for 100 writes + 100 reads for  MLDBM::Sync::SDBM_File 0.17 seconds 
12288 bytes
  Time for 100 writes + 100 reads for  GDBM_File  3.30 seconds 
18066 bytes
  Time for 100 writes + 100 reads for  DB_File4.32 seconds 
20480 bytes

=== INSERT OF 500 BYTE RECORDS ===
  Time for 100 writes + 100 reads for  SDBM_File  0.18 seconds
771072 bytes
  Time for 100 writes + 100 reads for  MLDBM::Sync::SDBM_File 0.58 seconds
110592 bytes
  Time for 100 writes + 100 reads for  GDBM_File  3.42 seconds 
63472 bytes
  Time for 100 writes + 100 reads for  DB_File4.32 seconds 
81920 bytes

=== INSERT OF 5000 BYTE RECORDS ===
 (skipping test for SDBM_File 1024 byte limit)
  Time for 100 writes + 100 reads for  MLDBM::Sync::SDBM_File 1.39 seconds   
1850368 bytes
  Time for 100 writes + 100 reads for  GDBM_File  4.63 seconds
832400 bytes
  Time for 100 writes + 100 reads for  DB_File5.73 seconds
839680 bytes

=== INSERT OF 2 BYTE RECORDS ===
 (skipping test for SDBM_File 1024 byte limit)
  Time for 100 writes + 100 reads for  MLDBM::Sync::SDBM_File 4.83 seconds   
8304640 bytes
  Time for 100 writes + 100 reads for  GDBM_File  4.65 seconds   
2063912 bytes
  Time for 100 writes + 100 reads for  DB_File6.48 seconds   
2068480 bytes

=== INSERT OF 5 BYTE RECORDS ===
 (skipping test for SDBM_File 1024 byte limit)
  Time for 100 writes + 100 reads for  MLDBM::Sync::SDBM_File12.86 seconds  
16192512 bytes
  Time for 100 writes + 100 reads for  GDBM_File  5.68 seconds   
5337944 bytes
  Time for 100 writes + 100 reads for  DB_File6.87 seconds   
5345280 bytes

Re: push_handlers and PerlAuthenHandler troubles [second try]

[Rodney Broom]

- Original Message -
From: Bolt Thrower <[EMAIL PROTECTED]>

> 
>   AuthType Apache::AuthTicket
>   AuthName HomeIntranet
>   PerlAuthenHandler Intranet::CheckSiteAuthen
>   #PerlAuthenHandler Apache::AuthTicket->authenticate
>   PerlAuthzHandler Apache::AuthTicket->authorize
>   require valid-user
> 

> But when I try to access a location under that configuration,
> I see in my error log:
> [Mon Jun 25 18:33:55 2001] [crit] [client 192.168.10.15] configuration
> error:  couldn't
> check user.  No user file?: /u/IntranetLoginForm

mod_auth supplies the "Auth*" dirrectives. Since he sees 'require
valid-user', he's looking for the rest of the Auth* directives.
Specifically, "AuthUserFile".

I have a handler doing just what  you are describing, and  have the same
problem. My solution was to mandate that my mudule was the only thing
allowed to use Auth* configureation in the server config file and that
everybody else had to use .htaccess. But I still see that message
occasionally. My suggestion: if it work, then ignore the error message. :-)



> Of course, everything works with the configuration
> 
>   AuthType Apache::AuthTicket
>   ...
> 
> Any suggestions for me?

Yep, Auth* happens at the Directory level. From the docs:
AuthUserFile
Context: directory, .htaccess

So, if you have an other set of Auth* directives in the same scope, then
that can cause conflicts

---
Rodney Broom
Programmer: Desert.Net

Re: Persitant data accross processes

[Rodney Broom]

Hi all,

Thanks for  the input. I've replied to three messages in this one. In order,
they are Joachim, Olivier and Aaron. In my reply to Aaron, I've outlined in
better specificity what I'm actually after. One further note on my needs,
I'm not after session data. I've got a big information caching systems that
sits in memory between my database everything else. What I'm looking for is
some heavy performance improvements.

-

From: Joachim Zobel <[EMAIL PROTECTED]>
JZ> We are using Data::Dumper to put the data structures as TEXT into a
MySQL
JZ> table, where they can retrieved via an id.

JZ> This is pretty fast for low to medium traffic and has the advantage that
JZ> the data is persistent (restarting apache won't zap the carts) and human
JZ> readable (debugging is easy).

Wow, ouch! Here's a performance gain for you:
- use Storable qw{freeze thaw store retrieve};
- Take your
'$dumpered = Dumper($ref)' statement and changed it to
'$frozen = freeze($ref)'
- Take your
'eval $dumpered' and changed it to
'$data = thaw($frozen)'
- For a human to read frozen data: print Dumper(thaw($frozen))

MUCH better gains than what I've just shown you are available. But this is
sure to be cheaper than evaling text.


-
From: Olivier Poitrey <[EMAIL PROTECTED]>
OP> I'm working on two modules that can help you to do this job. There names
are
OP> Apache::SharedMem and Apache::Cache. You can find them on :


-
From: Aaron E. Ross <[EMAIL PROTECTED]>
AER>  why is a new dbh for each process a problem? how else would it work?

Well, every new connection is overhead. So any reuse is good.


RB> >it has to copy data. Meaning that I can only have a certain amount of
RB> >complexity to my data structures.

AER>  I'm not sure why IPC::Shareable doesn't work, but maybe if you explain
the problem
AER>  we can help.

Hmm, you're right. I wasn't specific enough. What I'm after is having Perl
namespace level access to specific slots in memory. Not just the data that
~was~ once in that variable, but the variable itself. So, with two processes
I could say:

  pid 1
   $superclass::thing = "Here is PID $$";
  pid 2
   print $superclass::thing,"\n";   # This would contain PID 1

I can emulate this with any number of devices that look at a third location
for data and return the value. Options include IPC::Shareable, Berkley DB
files, RDBMSs and stone tables manged by carrier pigeons. Depending on the
transient data device, this works for any type of data, including simple
scalars and multi-level hashes and arrays. But the variables returned are
only copies of the data, not the actual variable itself.

- For example:
When you use IPC::Shareable to tie() a var to a chunk of shared memory, you
aren't accessing the memory that Perl has allocated for that variable, you
are accessing a chunk of "Shared Memory" allocated via your system's shmget
function. That means that IPC::Shareable has to do things like checking the
shared memory segment every time the var is accessed. And complex vars don't
get updated in shared memory in some circumstances.
  # Process 1
  tie %big_hash, 'IPC::Shareable",...
  $big_hash{x} = {hr => \%really_deap_hash}

  # Process 2
  tie %big_hash, 'IPC::Shareable",...
  $big_hash{x}->{this}->{that}->{the_other} = 'Not visible to PID 1';

I know, my example is wrong since IPC::Shareable ~does~ handle this
properly. But that package has some serious shared memory management
problems. So I've implimented a version that doesn't. But, I digress. The
IPC::Shareable example also has this problem:

  # Process 1
  tie %hash, 'IPC::Shareable",...
  $hash{x} = {simpe => 'data'}

  # Process 2
  tie %hash, 'IPC::Shareable",...
  $key_ref = $hash{x};

In process 2, $key_ref will maintain it's data even once $hash{x} changes.
That's because IPC::Shareable isn't really presenting me with Perl's memory
location, he's copied a frozen data structure out of shared memory and
letting me have a copy of it.


Again, thanks for all of the replies. It seems as though I never get replies
to my questions. ;-P

---
Rodney Broom
Programmer: Desert.Net

Re: Directory Restrictions

[will trillich]

On Tue, Jun 26, 2001 at 01:00:00AM -0400, Brooklyn Linux Solutions CEO wrote:
> I found it, quite be accident in the Eagle Book
> 
> Lost the page number, but it was in Chapter 4.

i know i ran across something like that at once time myself, but
scanning chapter 4 for twenty minutes didn't find it. (not that
i'm error-free when it comes to finding things, tho... :)

anybody got a more specific pointer to help us fuzzy searchers
find 'how to have mod_perl handle directory requests'?

-- 
I figure: if a man's gonna gamble, may as well do it
without plowing.   -- Bama Dillert, "Some Came Running"

[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

Re: Persistant data accross processes

[Olivier Poitrey]

I'm working on two modules that can help you to do this job. There names are
Apache::SharedMem and Apache::Cache. You can find them on :

ftp://ftp.rhapsodyk.net/pub/devel/perl/

thx to report bugs to me

- Original Message -
From: "Rodney Broom" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 25, 2001 11:54 PM
Subject: Persistant data accross processes


Hi all,

I'd like a way to store complex data structures across Apache processes.
I've looked at Apache::DBI for an example: my tests say that he has to
create a new dbh for every process. I've looked at IPC::Shareable, but it
has to copy data. Meaning that I can only have a certain amount of
complexity to my data structures.

Thoughts?

---
Rodney Broom
Programmer: Desert.Net

Re: looking for a few good stats

[Brian Reichert]

On Tue, Jun 26, 2001 at 08:22:25AM -0700, Islandman wrote:
> I'm looking for a good stats package for presenting basic stats, normal
> distributions, percentiles, and similar off of database queries.  Not
> seeing much on CPAN.

Statistics::Descriptive does me just fine.  What kind of stuff are you
looking for?

> Thanks in advance!
> -Brian

-- 
Brian 'you Bastard' Reichert<[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path

Re: mod_Perl 1.25, CGI.pm and POST

[darren chamberlain]

Anthony Brock <[EMAIL PROTECTED]> said something to this effect on 06/26/2001:
> At 12:48 AM 06/26/2001 -0700, [EMAIL PROTECTED] wrote:
> >At 15:50 25.06.2001 -0700, you wrote:
> >There has been a change in 1.25 concerning reading of STDIN (this is what
> >POST does). Dough MacEachern mentioned this some days ago.
> >
> >IIRC $r->read() now returns nothing instaed of hanging if STDIN has
> >already
> >been read. I would conjecture that somehow your CGI.pm reads STDIN twice,
> >overwriting the first read with said nothing.
> 
> Okay, after testing, I have narrowed the problem to existing ONLY when I 
> add our PHP 4.0.5 module into the server configuration.

This makes sense. PHP takes all the parameters and turns them
into PHP variables. PHP4 must do this at an earlier stage than
PHP3, sometime before the response phase (PHP3 did this during
the repsonse phase).

(darren)

-- 
I accept chaos. I'm not sure whether it accepts me. I know some people
are terrified of the bomb. But then some people are terrified to be
seen carrying a modern screen magazine. Experience teaches us that
silence terrified people the most.
-- Bob Dylan

Re: Cookies and redirection

[darren chamberlain]

Glen Small <[EMAIL PROTECTED]> said something to this effect on 06/26/2001:
> I'm having some problem setting a cookie in a logon script i
> have.  The code work fine as a CGI, and also under mod)perl,
> however, I want to set a cookie during the login script, and
> then redirect the browser to another page.  

http://perl.apache.org/guide/snippets.html#Sending_Cookies_in_REDIRECT_Resp

-- 
The kind of thinking we do sets the stage for the action we are likely
to take. Because of this, a man who refuses to develop his thinking
is likely to act on the impressions made upon him by others.
-- Dr. Claude R. Baker, "Coin In The Air"

looking for a few good stats

[Islandman]

I'm looking for a good stats package for presenting basic stats, normal
distributions, percentiles, and similar off of database queries.  Not
seeing much on CPAN.

Thanks in advance!
-Brian

push_handlers and PerlAuthenHandler troubles [second try]

[Bolt Thrower]

My apologies if you've seen this twice.

For a particular Location, I'd like to selectively (i.e., based on
arbitrary criteria) determine whether a visitor needs authentication.
So I set up a Location section in httpd.conf as follows:


  AuthType Apache::AuthTicket
  AuthName HomeIntranet
  PerlAuthenHandler Intranet::CheckSiteAuthen
  #PerlAuthenHandler Apache::AuthTicket->authenticate
  PerlAuthzHandler Apache::AuthTicket->authorize
  require valid-user


Intranet::CheckSiteAuthen looks like:

---[start]-
package Intranet::CheckSiteAuthen;

use strict;
use DBI;
use Apache::Constants qw(:common);
use Intranet::common;

sub handler {
  my $r = shift;
  $r->warn("starting CheckSiteAuthen");
  $r->push_handlers(PerlAuthenHandler =>
'Apache::AuthTicket->authenticate');

  return DECLINED;
}


1;
---[end]-

But when I try to access a location under that configuration,
I see in my error log:
[Mon Jun 25 18:33:55 2001] [crit] [client 192.168.10.15] configuration
error:  couldn't
check user.  No user file?: /u/IntranetLoginForm

(/u/IntranetLoginForm is the login CGI form that Apache::AuthTicket
uses).

All I'm trying to do at this point is set up a PerlAuthenHandler that
passes control to another one (Apache::AuthTicket->authenticate).

Of course, everything works with the configuration


  AuthType Apache::AuthTicket
  AuthName HomeIntranet
  #PerlAuthenHandler Intranet::CheckSiteAuthen
  PerlAuthenHandler Apache::AuthTicket->authenticate
  PerlAuthzHandler Apache::AuthTicket->authorize
  require valid-user


Any suggestions for me?

Thanks,

-- 
Steve Chadsey <[EMAIL PROTECTED]>
Now playing: Devil's Child
(Judas Priest - "Screaming For Vengeance")

ANNOUNCE: CGI::Application 2.0

[Jesse Erlbaum]

Version 2.0 of CGI::Application is now available via CPAN!


Download site for CGI::Application:

  http://www.cpan.org/authors/id/J/JE/JERLBAUM/


CHANGES SINCE VERSION 1.31:
- Added ability to set mode_param() to use a call-back instance method
  (specified by subref) instead of a CGI parameter.
- HTML::Template is now only loaded if load_tmpl() is called.
  (Thanks to Stephen Howard for the two preceding ideas!) 
- Run-modes may now return scalar-refs in addition to scalars.
- Added new run-mode of last resort: "AUTOLOAD".  See POD for usage.
- Updated MAJOR REVISION number to 2 -- new functionality deserves it.


Read the recent "Using CGI::Application" article on Perl.com for an 
overview of the module and its usage:

  http://www.perl.com/pub/2001/06/05/cgi.html


CGI::Application is intended to make it easier to create sophisticated,
reusable web-based applications. This module implements a methodology which,
if followed, will make your web software easier to design, easier to
document, easier to write, and easier to evolve.

CGI::Application builds on standard, non-proprietary technologies and 
techniques, such as the Common Gateway Interface and Lincoln D. Stein's 
excellent CGI.pm module.  CGI::Application judiciously avoids employing 
technologies and techniques which would bind a developer to any one set 
of tools, operating system or web server.

The guiding philosophy behind CGI::Application is that a web-based
application can be organized into a specific set of "Run-Modes." Each
Run-Mode is roughly analogous to a single screen (a form, some output, etc).
All the Run-Modes are managed by a single "Application Module" which is a
Perl module. In your web server's document space there is an "Instance
Script" which is called by the web server as a CGI (or an Apache::Registry
script if you're using Apache + mod_perl).

CGI::Application is an Object-Oriented Perl module which implements an
Abstract Class. It is not intended that this package be instantiated
directly. Instead, it is intended that your Application Module will be
implemented as a Sub-Class of CGI::Application.

If you have any questions, comments, bug reports or feature suggestions, 
post them to the support mailing list!  To join the mailing list, simply
send a blank message to "[EMAIL PROTECTED]".


--

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Jesse Erlbaum ... CTO
  [EMAIL PROTECTED] . Vanguard Media
  v: 212.242.5317 x115 .. New York City
+-+-+-+-+-+- http://www.vm.com/ +-+-+-+-+-+-+

swapping of mod_perl parent process / mlockall()

[Adi Fairbank]

Is it correct that when the Apache/mod_perl parent process swaps to disk, a
large part of it (swapped pages) becomes unshared?  Even after the kernel
restores the pages from swap, do they remain unshared?  So once the parent
process becomes unshared, new apache children that are spawned only share
the parent's pages that have never been swapped?

This is what I've grok'ed from my experiments with top/GTop.

If this is the case, it would be helpful to prevent the parent process from
*ever* swapping to disk.

The Linux kernel has a system call mlockall() which disables all memory
paging for the current process.  This sounds like exactly the recipe for
preventing parent process swapping.  It won't affect spawned child
processes, so shouldn't pose a threat of consuming all physical memory and
crashing the system.

I want to play around with this, but I'm not sure where in the mod_perl
source to call mlockall().  It would need to be before the parent spawns any
children..  Has anyone tried using Linux's mlockall()/mlock() with mod_perl?

-Adi

Re: mod_Perl 1.25, CGI.pm and POST

[Anthony Brock]

At 12:48 AM 06/26/2001 -0700, [EMAIL PROTECTED] wrote:
>At 15:50 25.06.2001 -0700, you wrote:
>
>[...]
>
>There has been a change in 1.25 concerning reading of STDIN (this is what
>POST does). Dough MacEachern mentioned this some days ago.
>
>IIRC $r->read() now returns nothing instaed of hanging if STDIN has
>already
>been read. I would conjecture that somehow your CGI.pm reads STDIN twice,
>overwriting the first read with said nothing.

Okay, after testing, I have narrowed the problem to existing ONLY when I 
add our PHP 4.0.5 module into the server configuration.

Basically, I created a simply CGI script to echo to the browser EVERYTHING 
the script received on STDIN from a POST. Once created, I deployed this on 
our new Apache server and an older Apache server which is still working. 
The new server never passes the POST to the script, while the old server 
does! However, once I removed the PHP module everything started working 
perfectly.

Does anyone know what mailing list I need to move this question to? Sorry 
for posting to the wrong group ...

>[...]
>
> >># This file is intended to be INCLUDED from an SHTML file,
> >>#   NOT directly executed!
>
>Did this ever work with POST? You can not POST to an SSI.
>
>Joachim

The comment was from the original script written about 3 years ago. I had 
forgotten to remove it and that original script has been used several times 
to 'seed' other scripts. It should have been deleted before I posted.

Actually, this has worked with POST for over a year. It's a CGI script used 
extensively by our librarians.

Tony

**
* Anthony Brock [EMAIL PROTECTED] *
* Director of Network Services George Fox University *
**

Cookies and redirection

[Glen Small]

All,
 
I'm having some problem setting a cookie in a logon 
script i have.  The code work fine as a CGI, and also under mod)perl, 
however, I want to set a cookie during the login script, and then redirect the 
browser to another page.  When I enter the code below into the mod_perl 
script, the browser tries to download login.pl, rather than running it.  If 
I print the HTTP header to the screen, it looks fine, but it wont 
run.
 
This code below works fine under normal CGI.  
Any thoughts ?
 
use CGI;
use CGI::Cookie;
 
my $q = new CGI;
 
...
my $cookie = new CGI::Cookie(-name => 
'testlogger', -value=> $UserID, -path => '/');
 
print $q->redirect(-uri=>'/perl/home.pl', 
-nph=>'1', -cookie => $cookie); 
 
...

Re: strange uninitialized value error.

[Vivek Khera]

> "RB" == Rodney Broom <[EMAIL PROTECTED]> writes:

>> Use of uninitialized value at /website/perllib/MLM/MLMhandler.pm line 56.

RB> $uri = $r->uri;
RB>  warn "\$uri is undef" unless defined $uri;  debugging?!?!?

worth a shot... let's see.  thanks.

Re: Persitant data accross processes

[Aaron E. Ross]

>Hi all,
>
>create a new dbh for every process. I've looked at IPC::Shareable, but =

 why is a new dbh for each process a problem? how else would it work?

>it has to copy data. Meaning that I can only have a certain amount of =
>complexity to my data structures.

 I'm not sure why IPC::Shareable doesn't work, but maybe if you explain the problem 
 we can help.

 I've had the best success with BerkeleyDB for most tasks, I like the balance of 
simplicity, 
 speed, locking, and concurrency.  Just be sure to use BerkeleyDB and not DB_File, ok?

 You might also take a look at Cache::Cache for some sessions.

 There are also a number of modules that provide persistance frameworks: Alzabo, 
 Persistent::*, Tangram, Storable. See Data Type Marshalling and Persistent Storage
 in the Modules list on CPAN: http://www.cpan.org/modules/00modlist.long.htm

 Let me know how it works out.

 Aaron

Re: Persistant data accross processes

[darren chamberlain]

Rodney Broom <[EMAIL PROTECTED]> said something to this effect on 06/25/2001:
> Hi all,
> 
> I'd like a way to store complex data structures across Apache
> processes. I've looked at Apache::DBI for an example: my tests
> say that he has to create a new dbh for every process. I've
> looked at IPC::Shareable, but it has to copy data. Meaning that
> I can only have a certain amount of complexity to my data
> structures.
> 
> Thoughts?

Apache::Session, currently at 1.53. Here's an except from the
perldoc:

 Sharing data between Apache processes

 When you share data between Apache processes, you need to decide
 on a session ID number ahead of time and make sure that an object
 with that ID number is in your object store before starting you
 Apache.  How you accomplish that is your own business.  I use the
 session ID "1".  Here is a short program in which we use
 Apache::Session to store out database access information.

   use Apache;
   use Apache::Session::File;
   use DBI;

   use strict;

   my %global_data;

   eval {
   tie %global_data, 'Apache::Session::File', 1,
  {Directory => '/tmp/sessiondata'};
   };
   if ($@) {
  die "Global data is not accessible: $@";
   }

   my $dbh = DBI->connect($global_data{datasource},
  $global_data{username}, $global_data{password})
  || die $DBI::errstr;

   undef %global_data;

   #program continues...

 As shown in this example, you should undef or untie your session
 hash as soon as you are done with it.  This will free up any
 locks associated with your process.

Is this what you are looking for?

(darren)

-- 
Make no laws whatever concerning speech, and speech will be free; so soon
as you make a declaration on paper that speech shall be free, you will have
a hundred lawyers proving that "freedom does not mean abuse, nor liberty
license"; and they will define and define freedom out of existence.  
-- Voltarine de Cleyre

Re: mod_perl 1.25, CGI.pm and POST

[Joachim Zobel]

At 15:50 25.06.2001 -0700, you wrote:

[...]

>However, if I change the submission type from POST to GET, the script 
>starts functioning perfectly.
>
>Does anyone know what would cause this type of behavior? I am at a loss as 
>to how to proceed ... I am including below an example script which 
>exhibits this behavior consistently on my server.

There has been a change in 1.25 concerning reading of STDIN (this is what 
POST does). Dough MacEachern mentioned this some days ago.

IIRC $r->read() now returns nothing instaed of hanging if STDIN has already 
been read. I would conjecture that somehow your CGI.pm reads STDIN twice, 
overwriting the first read with said nothing.

[...]

># This file is intended to be INCLUDED from an SHTML file,
>#   NOT directly executed!

Did this ever work with POST? You can not POST to an SSI.

Joachim

--
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden
koennen."- Bertolt Brecht - Leben des Galilei

Re: Persistant data accross processes

[Joachim Zobel]

At 14:54 25.06.2001 -0700, you wrote:
>Hi all,
>
>I'd like a way to store complex data structures across Apache processes. 
>I've looked at Apache::DBI for an example: my tests say that he has to 
>create a new dbh for every process. I've looked at IPC::Shareable, but it 
>has to copy data. Meaning that I can only have a certain amount of 
>complexity to my data structures.

We are using Data::Dumper to put the data structures as TEXT into a MySQL 
table, where they can retrieved via an id.

This is pretty fast for low to medium traffic and has the advantage that 
the data is persistent (restarting apache won't zap the carts) and human 
readable (debugging is easy).

Hth,
Joachim

--
"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden
koennen."- Bertolt Brecht - Leben des Galilei