Linux Hello World Benchmarks...

2000-12-11 Thread Joshua Chamas

Hey,

I have automated a portable Hello World test suite, but its not
CPAN ready, so if any would like to contribute, run, and comment
on the sources, give me a holler  I'll send them to you.  What
it does is fire up a lean apache on a high port with only the 
config necessary to run the benchmark.

RESULTS:

[hello]# ./bench.pl -time=60
...
Test Name Test FileHits/sec Total Hits   Total Time   Total 
Bytes  
      
 
Apache::ASP   hello.asp 416.9   25016 hits   60.00 sec4478401 
byte 
Apache::Registry CGI Raw  hello_raw.re  736.9   44214 hits   60.00 sec2299284 
byte 
Apache::Registry CGI.pm   hello.reg 501.3   30080 hits   60.00 sec4632628 
byte 
HTML Static   hello.html   1211.6   5 hits   41.27 sec12450249 
byt 
HTML::Embperl hello.epl 510.7   30647 hits   60.01 sec4843016 
byte 
HTML::Mason   hello.mas 382.2   22934 hits   60.00 sec3086640 
byte 
ModPerl Handler   hello.bench   888.9   5 hits   56.25 sec6700268 
byte 
Template Toolkit  hello.tt  181.6   10895 hits   60.01 sec1481992 
byte 

**AxKit -- need someone to run benchmark suite with this working

Apache::ASP v2.07
HTML::Embperl 1.3.0
HTML::Mason 0.89
Template Toolkit 2.0
mod_perl 1.24
apache 1.3.14
linux 2.2.14
PIII 450x2
localhost interface

Note, this is the first benchmark that I've run of Apache::ASP on 
Linux, which is nice to see because Linux is one of the faster OS's,
and it now looks bit more of a player, compared to what's listed at
http://www.chamas.com/bench/ when I benched it on Solaris x86.

Also, Mason seems to have improved significantly since I last
benched it.  Good job Jonathan.  

Lastly, I was unable to get AxKit to run without segfaulting ...
I had wanted to get at least a XPathScript benchmark, and maybe
Sablotron driven XSLT.  The simple XSLT hello world is at
http://www.chamas.com/bench/#xml.  The XPathScript HelloWorld
that I came up with was: % print "Hello "; %World  ... but
maybe it should have been more like the XSLT hello world?

-- Josh
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: mod_perl advocacy project resurrection

2000-12-11 Thread Matt Sergeant

On Sun, 10 Dec 2000, Jim Woodgate wrote:


 [EMAIL PROTECTED] writes:
   You can do the twostage server if you are short on memory, speed is
   important and usage of active content is relatively low. Setup a mod_proxy
   and stripped down apache for port 80 and mod_perl for port 8080 for
   example. Proxy certain urls to the 8080 and you are good. Set low number
   for the mod_perl items, to avoid thrashing. I'd see where Java is weak,
   integration wise like 2 MB per process and not even integrated string
   processing.

 I'm sorry I wasn't more clear in my first response.  My main point was
 not that the common threads I've seen on this mailing list didn't have
 good solutions.  It was that these things come up alot, and although
 there are good solutions, they typically involve something beyond
 mod_perl...

 I've used dbm files and shared memory before, and I find it easier to
 use the built in thread support in java (like I said IMHO of course :)

Except that won't scale beyond 1 server...

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




Re: mod_perl advocacy project resurrection

2000-12-11 Thread Gunther Birznieks

At 10:07 AM 12/11/2000 +, Matt Sergeant wrote:
On Sun, 10 Dec 2000, Jim Woodgate wrote:

 
  [EMAIL PROTECTED] writes:
You can do the twostage server if you are short on memory, speed is
important and usage of active content is relatively low. Setup a 
 mod_proxy
and stripped down apache for port 80 and mod_perl for port 8080 for
example. Proxy certain urls to the 8080 and you are good. Set low number
for the mod_perl items, to avoid thrashing. I'd see where Java is weak,
integration wise like 2 MB per process and not even integrated string
processing.
 
  I'm sorry I wasn't more clear in my first response.  My main point was
  not that the common threads I've seen on this mailing list didn't have
  good solutions.  It was that these things come up alot, and although
  there are good solutions, they typically involve something beyond
  mod_perl...
 
  I've used dbm files and shared memory before, and I find it easier to
  use the built in thread support in java (like I said IMHO of course :)

Except that won't scale beyond 1 server...

But that's the same thing with IPC shared mem modules yet people still use 
them on mod_perl for various tricks. It's still easier in Java to do that 
sort of sharing -- at least it is for me. As always, other people's mileage 
may vary.





Re: Linux Hello World Benchmarks...

2000-12-11 Thread Gunther Birznieks

Is CGI Raw decoding the get/post yourself? Or using the Apache::args, 
Apache::Request::param mechanism?


At 02:13 AM 12/11/2000 -0800, Joshua Chamas wrote:
Hey,

I have automated a portable Hello World test suite, but its not
CPAN ready, so if any would like to contribute, run, and comment
on the sources, give me a holler  I'll send them to you.  What
it does is fire up a lean apache on a high port with only the
config necessary to run the benchmark.




Re: mod_perl advocacy project resurrection

2000-12-11 Thread Matt Sergeant

On Mon, 11 Dec 2000, Gunther Birznieks wrote:

 Except that won't scale beyond 1 server...

 But that's the same thing with IPC shared mem modules yet people still use
 them on mod_perl for various tricks. It's still easier in Java to do that
 sort of sharing -- at least it is for me. As always, other people's mileage
 may vary.

I don't disagree with you. I wish it were easier in Perl too.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




Re: Linux Hello World Benchmarks...

2000-12-11 Thread Joshua Chamas

Gunther Birznieks wrote:
 
 Is CGI Raw decoding the get/post yourself? Or using the Apache::args,
 Apache::Request::param mechanism?
 

In the hello world scripts, there is no get/post processing as
part of the benchmark.  Here's the code that's run:

  http://www.chamas.com/bench/#perlrawcgi

The general language scripts are at http://www.chamas.com/bench/
and are also in the hello.tar.gz bundle that I could send.
The bundle also has the app configs in bench.pl.  Its a whole 8K 
gzipped though, and I'm afraid Ask would hurt me if I posted it ;)

-- Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: Linux Hello World Benchmarks...

2000-12-11 Thread Matt Sergeant

On Mon, 11 Dec 2000, Joshua Chamas wrote:

 Lastly, I was unable to get AxKit to run without segfaulting ...

http://axkit.org/faq.xml

Either you're running PHP on that server, or you have an Apache with expat
included. Do "nm /path/to/apache/bin/httpd | grep -i XML" to find out if
the latter is true.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




Re: Linux Hello World Benchmarks...

2000-12-11 Thread Gunther Birznieks

Then it seems odd that there is such a huge discrepency between CGI.pm and 
no CGI.pm. If you preload CGI.pm in startup.pl does the difference go away?

At 02:56 AM 12/11/2000 -0800, Joshua Chamas wrote:
Gunther Birznieks wrote:
 
  Is CGI Raw decoding the get/post yourself? Or using the Apache::args,
  Apache::Request::param mechanism?
 

In the hello world scripts, there is no get/post processing as
part of the benchmark.  Here's the code that's run:

   http://www.chamas.com/bench/#perlrawcgi

The general language scripts are at http://www.chamas.com/bench/
and are also in the hello.tar.gz bundle that I could send.
The bundle also has the app configs in bench.pl.  Its a whole 8K
gzipped though, and I'm afraid Ask would hurt me if I posted it ;)

-- Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA
http://www.nodeworks.com1-714-625-4051

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/




Re: Linux Hello World Benchmarks...

2000-12-11 Thread Joshua Chamas

Gunther Birznieks wrote:
 
 Then it seems odd that there is such a huge discrepency between CGI.pm and
 no CGI.pm. If you preload CGI.pm in startup.pl does the difference go away?
 

I did preload CGI.pm.  I'll send you the hello world
suite separately since you seem curious.  Note that at 500
requests / second, the difference of 50 requests / sec is
really 1/500 - 1/550 = .00018 CPU seconds.  The point is
that as these systems get more efficient, minor differences
in performance seem to make more of a difference.  

The same .0018 CPU sec at 100 hits/sec would only make 102 
hits / sec.

--Josh



Re: Script Debugging Modules?

2000-12-11 Thread Daniel Chetlin

On Sun, Dec 10, 2000 at 07:26:38PM -0800, Bill Moseley wrote:
 Just how smart is the compiler?
[snip]
 use constant DEBUG_TEMPLATE  = 1;
 use constant DEBUG_SESSION   = 2;
 use constant DEBUG_REQUEST   = 4;
 use constant DEBUG_QUERY = 8;
 use constant DEBUG_QUERY_PARSED  = 16;
 
 my $debug = DEBUG_REQUEST|DEBUG_QUERY;
 
 warn "query = '$query'\n" if $debug  DEBUG_QUERY;

Not quite that smart. It has no idea if `$debug' will have changed by
the time you're asking about it. However, if you make `$debug' into a
constant, it will work (where "work" is defined as "optimize out the
conditional").

  use constant FOO = 1;
  use constant BAR = 2;
  use constant FOOBAR = FOO|BAR;
  warn "baz" if FOOBAR  FOO;

 use constant DEBUG_TEMPLATE  = 0;  # OFF
 use constant DEBUG_SESSION   = 1;  # ON
 use constant DEBUG_REQUEST   = 0;
 use constant DEBUG_QUERY = 1;  # ON
 use constant DEBUG_QUERY_PARSED  = 0;
 
 warn $query if DEBUG_QUERY || DEBUG_QUERY_PARSED;

This will also work, but I like the first approach better. It allows you
to factor out the component you want to debug.

-dlc



Re: Linux Hello World Benchmarks...

2000-12-11 Thread Joshua Chamas

"Alexander Farber (EED)" wrote:
 
 Hi Joshua,
 
 you sort the table at http://www.chamas.com/bench/ by Hits/s,
 but the ModPerl Handler was tested on PIII-500 x 2 and the Java
 thingies below - only PII-266.
 
 Is it an intended joke or do I misunderstand something?
 

The first page is marked "for fun" because there are no relevant
sortings that you can do between systems  benchmarkers, as there
are too many variables.  Its sorted by speed to encourage people
to submit new results with their shiny new GHz CPUs.

You can try to derive some real meaning from tests done on
the same system by the same person using the same methodology ... 
for these go to 

  http://www.chamas.com/bench/hello_bysystem.html

--Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Upgraded to perl 5.6.0, ImageMagick now gives boot_libapreq error

2000-12-11 Thread Chris


I have just done a complete install of RedHat v7.0 which includes
Perl 5.6.0. Image Magick was running fine on my old system, but now 
when I attempt to install it, it gives the following error message
when attempting to do the PerlMagick install:

./perlmain.o: In function: 'xs_init' :
./perlmain.o(.text+0xc1): undefined reference to  'boot_libapreq'
collect2: ld returned 1 exit status


I have:

Apache 1.3.14
ModPerl 1.24
ImageMagick 5.2.6


If I remove the lines from perlmain.c that talk about boot_libapreq,
then PerlMagic compiles and installs fine, and works from standard
perl scripts, but does not work called from a mod perl handler - hence
the post to this list.

I'd be most grateful if anybody could help!

Chris Allen
[EMAIL PROTECTED]






Re: File name conversion

2000-12-11 Thread darren chamberlain

Hi Aaron,

Check out the section titled "Using a Translation Handler to Change the
URI" in Chapter 7 of the Eagle book, at
http://www.modperl.com/book/chapters/ch7.html#Using_a_Translation_Handler_to_C.

Aaron Johnson ([EMAIL PROTECTED]) said something to this effect:
 Is there a module that allows you to translate the file name into
 something else, but keeps the requested filename in an enviroment
 variable or other location?

(darren)

-- 
So far as a man thinks, he is free.



Re: Naming the mod_perl process $0

2000-12-11 Thread Joshua Chamas

 [EMAIL PROTECTED] wrote:
 
 Hello, I have a question that may have a simple answer.
 
 In order to satisfy some broader system dependencies I need to define my mod_perl 
process name.  By default $0 seems to get set to "/dev/null".
 When I try to modify $0 in the Apache startup script or elsewhere apache dumps core. 
 I'm running Apache 1.3.9 with mod_perl 1.22 linked in on DEC
 alpha.
 

local *0 = 'whatever'; # is how I do it

-- Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



the list's digest is working now

2000-12-11 Thread Stas Bekman


Thanks to Brian Behlendorf and Jim Winstead the [EMAIL PROTECTED]
is back to normal operation.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: Naming the mod_perl process $0

2000-12-11 Thread Stas Bekman

On Mon, 11 Dec 2000, Joshua Chamas wrote:

  [EMAIL PROTECTED] wrote:
  
  Hello, I have a question that may have a simple answer.
  
  In order to satisfy some broader system dependencies I need to define my mod_perl 
process name.  By default $0 seems to get set to "/dev/null".
  When I try to modify $0 in the Apache startup script or elsewhere apache dumps 
core.  I'm running Apache 1.3.9 with mod_perl 1.22 linked in on DEC
  alpha.
  
 
 local *0 = 'whatever'; # is how I do it

and the real name of the script if you are running under Registry and
friends can be derived from __PACKAGE__ or $r-filename

 
 -- Josh
 
 _
 Joshua Chamas Chamas Enterprises Inc.
 NodeWorks  free web link monitoring Huntington Beach, CA  USA 
 http://www.nodeworks.com1-714-625-4051
 



_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: Linux Hello World Benchmarks...

2000-12-11 Thread Joe Schaefer

Joshua Chamas [EMAIL PROTECTED] writes:

 RESULTS:
 
 [hello]# ./bench.pl -time=60
 ...
 Test Name Test FileHits/sec Total Hits   Total Time   Total 
Bytes  
       
 
 HTML Static   hello.html   1211.6   5 hits   41.27 sec
12450249 byt 
 ModPerl Handler   hello.bench   888.9   5 hits   56.25 sec
6700268 byte 
[...]

IME, simple mod_perl handlers typically run around 50% as fast as 
HTML static pages.  Your hello world benchmark seems to be slightly 
misleading in this respect, since the content-length is small 
relative to the header size.

For your HTML Static, I would guess that the headers delivered are
significantly larger than the ones returned by your modperl handler.
Hence for 5 hits, there is a significant discrepancy in the 
total bytes delivered.  This skews the hits/sec numbers in the
favor of content handlers that deliver shorter headers.

To use HTML Static as a baseline comparison for dynamic content 
handlers, I think you should ensure that the headers delivered
are comparable to those that are dynamically generated.

Best.
-- 
Joe Schaefer



Upgraded to perl 5.6.0, ImageMagick now gives boot_libapreq error

2000-12-11 Thread Chris Allen

I have just done a complete install of RedHat v7.0 which includes
Perl 5.6.0. Image Magick was running fine on my old system, but now 
when I attempt to install it, it gives the following error message
when attempting to do the PerlMagick install:

./perlmain.o: In function: 'xs_init' :
./perlmain.o(.text+0xc1): undefined reference to  'boot_libapreq'
collect2: ld returned 1 exit status


I have:

Apache 1.3.14
ModPerl 1.24
ImageMagick 5.2.6


If I remove the lines from perlmain.c that talk about boot_libapreq,
then PerlMagic compiles and installs fine, and works from standard
perl scripts, but does not work called from a mod perl handler - hence
the post to this list.

I'd be most grateful if anybody could help!

Chris Allen
[EMAIL PROTECTED]






Still bugs in Apache::Dispatch with .htaccess

2000-12-11 Thread Matt Sergeant

Sorry Geoff,

OK, the bug now is that the _translate_uri sub expects you to be working
with Location rather than .htaccess. It does this to do
s/location/prefix/, which is why it doesn't work with .htaccess.

Now first of all, there's a bit of a security risk in there - you're doing
s/$location/$prefix/. Always *always* use \Q\E around those if you don't
want someone to be malicous.

Second, we want to get this working inside of .htaccess. My thought as to
how to do this is to set something defining where the directive is set
when your config methods are called. So I'm assuming you can get this from
$parms-path(). Store this in the $cfg hash, and then in _translate_uri
do:

my $location = $r-location || $cfg-{'Path'};

Or something like that.

Anyway, for now, back to normal handlers... :-)

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




RE: Still bugs in Apache::Dispatch with .htaccess

2000-12-11 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Monday, December 11, 2000 8:27 AM
 To: [EMAIL PROTECTED]
 Subject: Still bugs in Apache::Dispatch with .htaccess
 
 
 Sorry Geoff,
 
 OK, the bug now is that the _translate_uri sub expects you to 
 be working
 with Location rather than .htaccess. 

argh - I knew there was a reason I enforced DispatchPrefix from within a
Location tag - I have all the memory of a bowling ball...

 It does this to do
 s/location/prefix/, which is why it doesn't work with .htaccess.
 
 Now first of all, there's a bit of a security risk in there - 
 you're doing
 s/$location/$prefix/. Always *always* use \Q\E around those 
 if you don't
 want someone to be malicous.

right - I suppose I should be using \Q - I do, however, check for
metacharacters in the url as the (nearly) very first step:
  # if the uri contains any characters we don't like, bounce...
  # is this necessary?
  if ($uri =~ m![^\w/-]!) {
$log-info("\t$uri has bogus characters...")
   if $Apache::Dispatch::DEBUG;
$log-info("Exiting Apache::Dispatch");
return DECLINED;
  }

sufficient?

BTW, I return DECLINED often for scenarios like this within Dispatch, but
have contemplated recently returning NOT_FOUND...  opinions?  I don't want
to break existing behaviors for people...

 
 Second, we want to get this working inside of .htaccess. My 
 thought as to
 how to do this is to set something defining where the directive is set
 when your config methods are called. So I'm assuming you can 
 get this from
 $parms-path(). Store this in the $cfg hash, and then in 
 _translate_uri
 do:
 
 my $location = $r-location || $cfg-{'Path'};
 
 Or something like that.

yeah, something like that might be the only alternative...  I'll have to
play with it... 

can you send me your .htaccess file - I may actually have some time in the
next day or so to try and figure this out...

 
 Anyway, for now, back to normal handlers... :-)

bah :)

--Geoff
 
 -- 
 Matt/
 
 /||** Director and CTO **
//||**  AxKit.com Ltd   **  ** XML Application Serving **
   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
  // \\| // ** Personal Web Site: http://sergeant.org/ **
  \\//
  //\\
 //  \\
 



[DIGEST] mod_perl digest 12/3/2000

2000-12-11 Thread Geoffrey Young

--

  mod_perl digest
 
   December 3, 2000 - December 9, 2000

--

Recent happenings in the mod_perl world...


Features

  o mod_perl status
  o module announcements
  o mailing list highlights
  o news
  o FAQ of the week
  o links


mod_perl status

  o mod_perl
- stable: 1.24_01 (released October 10, 2000) [1]
- development: 1.24_02-dev [2]
  o Apache
- stable: 1.3.14 (released October 13, 2000) [3]
- development: 1.3.15-dev [4]
  o Perl
- stable: 5.6 (released March 23, 2000) [5]
- development: 5.7 [6]


module announcements

  o Apache::SSI 2.16 - implementation of Server Side Includes that 
provides a subclassable interface allowing you to define your
own SSI tags [7]

  o HTML-Embperl 1.3.0 - a module for embedding Perl code in HTML
pages that includes building pages/sites out of small reusable
objects/components and session handling [8]

  o Apache-Dispatch 0.08 - call PerlHandlers with the ease of
Registry scripts [9]

  o Apache::ASP 2.07 - provides an Active Server Pages port to for
Perl scripting only, and enables the development of dynamic web 
applications with session management and embedded perl code [10]


mailing list highlights

  o While not specifically for mod_perl, the first release of lingerd
- a daemon (service) designed to take over the job of TCP/IP 
lingering_closes - made its debut this week [11]

  o take23.org - one stop shopping for mod_perl news and info - also
made its debut this week [12]

  o Some debugging techniques and tools for people writing mod_perl
handlers were discussed [13]

  o For the security minded, running Apache using chroot can offer
another level of protection.  This thread contains some thoughts
as well as links to additional information [14]


news

  o Netcraft mod_perl statistics are out for September [15]
  1,524,620 Domains, 197,931 IP Addresses


FAQ of the week

  o What can be done to better advocate mod_perl?

Apparently, everyone has an opinion :)  There were several
threads this week that focused on mod_perl advocacy.  It all 
started (this time) with Stas sending out an RFC [16].  This
spawned 21 related threads (by my count).  The largest of these
is now 104 messages long [17].  Some of the more focused
departures are about
   easier installation [18]
   certification [19]
   object orientation [20]
Sorting through all these is an exercise left to the reader...


links

  o The Apache/Perl Integration Project [21]
  o mod_perl documentation [22]
  o mod_perl modules on CPAN [23]
  o mod_perl homepage [24]
  o mod_perl list archives [25]


happy mod_perling...

--Geoff
[EMAIL PROTECTED]

--
[1] http://perl.apache.org/dist/
[2] http://perl.apache.org/from-cvs/modperl/
[3] http://www.apache.org/dist/
[4] http://dev.apache.org/from-cvs/apache-1.3/
[5] http://www.perl.com/pub/language/info/software.html#stable
[6] http://www.perl.com/pub/language/info/software.html#devel
[7] http://forum.swarthmore.edu/epigone/modperl/skiltehsmex
[8] http://forum.swarthmore.edu/epigone/modperl/joskumsteld
[9] http://forum.swarthmore.edu/epigone/modperl/mandquygri
[10] http://forum.swarthmore.edu/epigone/modperl/phinbliwhox
[11] http://forum.swarthmore.edu/epigone/modperl/queelahsteh
[12] http://forum.swarthmore.edu/epigone/modperl/glungrablar
[13] http://forum.swarthmore.edu/epigone/modperl/skingthendblex
[14] http://forum.swarthmore.edu/epigone/modperl/stimlorthen
[15] http://marc.theaimsgroup.com/?l=apache-modperl-cvsm=97594404107042w=2
[16] http://forum.swarthmore.edu/epigone/modperl/twimralnan
[17] http://forum.swarthmore.edu/epigone/modperl/sneflarskimp
[18] http://forum.swarthmore.edu/epigone/modperl/swarbrahox
[19] http://forum.swarthmore.edu/epigone/modperl/dumgexdwah
[20] http://forum.swarthmore.edu/epigone/modperl/prerdrerchul
[21] http://perl.apache.org
[22] http://perl.apache.org/#docs
[23] http://www.perl.com/CPAN-local/modules/by-module/Apache/
[24] http://www.modperl.com
[25] http://forum.swarthmore.edu/epigone/modperl/



Re: sharing tied dbm fd

2000-12-11 Thread Robin Berjon

At 22:11 10/12/2000 +0100, Stas Bekman wrote:
Am I correct to say that it's wrong to tie the dbm file in startup.pl and
than share it across the children? 
 [snip]
I think that unexpected things may happen since %My::Tied::btree has only
one file descriptor, and different processes accessing the dbm file at the
same time will mess it up, since the dbm iterator (or think of it as
seek() ) will jump wildly to satisfy requests from different processes and
wrecking havoc with methods like keys(), each() and similar...

Am I correct here? If so there is a bad suggestion in the guide which
should be corrected :(

I don't know whether or not you're correct as I haven't tested this (which
I guess is the only way to really know :). I don't much about fd's either,
but one thing that I think could cause trouble is indeed each() and keys(),
and this applies to any kind of tied hash, not just dbm tied hashes. Behind
the scenes, each() is implemented in tied interface through FIRSTKEY() and
NEXTKEY(). Typically, those two methods will do some housekeeping in order
to emulate a rational behaviour for each().

Say for instance you have a tied hash that's internally represented as an
array (for whatever reason). The first time you call each() on your tied
hash, it will call FIRSTKEY(). FIRSTKEY will return the first element of
the array, and in order for NEXTKEY() to know what it must return, it will
set an attribute of the tied object to 0, ie the position in the array of
the element that was last returned. The next time each() is called,
NEXTKEY() will return the next element and increment that attribute, and so
on until there are no elements left and NEXTKEY returns undef. If another
process jumps in and FIRSTKEY is called again while the first one is
accessing the keys, the attribute will get reset, and then it will call
NEXTKEY too and you will get strange increments.

This does not affect cases where you'd never call each() or keys(), but you
see the kind of mess one could get into. However, in order to avoid a tie()
on all requests it might be possible to put the tie()ing code inside a
ChildInitHandler (untested).

-- robin b.
I think...  I think it's in my basement... Let me go upstairs and check. --
Escher




Re: mod_perl in chroot environment

2000-12-11 Thread Vivek Khera

 "SB" == Stas Bekman [EMAIL PROTECTED] writes:

SB Do you think I should include the scenario of making Apache run in
SB chroot enviroment in the guide?

That require quite a bit of stuff be crammed into the chroot jail.
You'll need an entire perl install there, wouldn't you?  It might make
sense for a front-end of a two-tier setup, but the mod_perl instance
seems to me a bit big.  But I guess some people will want the extra
safety of it.  Personally I think it is a bit much to cram into a
chroot environment.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/



Re: mod_perl in chroot environment

2000-12-11 Thread Stas Bekman

  "SB" == Stas Bekman [EMAIL PROTECTED] writes:
 
 SB Do you think I should include the scenario of making Apache run in
 SB chroot enviroment in the guide?
 
 That require quite a bit of stuff be crammed into the chroot jail.
 You'll need an entire perl install there, wouldn't you?  It might make
 sense for a front-end of a two-tier setup, but the mod_perl instance
 seems to me a bit big.  But I guess some people will want the extra
 safety of it.  Personally I think it is a bit much to cram into a
 chroot environment.

Well, chroot wants everything to be inside, so you pretty much have no
choice if you go for it. I suppose that I'll just give some incentives
hints and point to these resources that hopefully will no go dead soon.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: sharing tied dbm fd

2000-12-11 Thread Stas Bekman

 At 22:11 10/12/2000 +0100, Stas Bekman wrote:
 Am I correct to say that it's wrong to tie the dbm file in startup.pl and
 than share it across the children? 
  [snip]
 I think that unexpected things may happen since %My::Tied::btree has only
 one file descriptor, and different processes accessing the dbm file at the
 same time will mess it up, since the dbm iterator (or think of it as
 seek() ) will jump wildly to satisfy requests from different processes and
 wrecking havoc with methods like keys(), each() and similar...
 
 Am I correct here? If so there is a bad suggestion in the guide which
 should be corrected :(
 
 I don't know whether or not you're correct as I haven't tested this (which
 I guess is the only way to really know :). I don't much about fd's either,
 but one thing that I think could cause trouble is indeed each() and keys(),
 and this applies to any kind of tied hash, not just dbm tied hashes. Behind
 the scenes, each() is implemented in tied interface through FIRSTKEY() and
 NEXTKEY(). Typically, those two methods will do some housekeeping in order
 to emulate a rational behaviour for each().
 
 Say for instance you have a tied hash that's internally represented as an
 array (for whatever reason). The first time you call each() on your tied
 hash, it will call FIRSTKEY(). FIRSTKEY will return the first element of
 the array, and in order for NEXTKEY() to know what it must return, it will
 set an attribute of the tied object to 0, ie the position in the array of
 the element that was last returned. The next time each() is called,
 NEXTKEY() will return the next element and increment that attribute, and so
 on until there are no elements left and NEXTKEY returns undef. If another
 process jumps in and FIRSTKEY is called again while the first one is
 accessing the keys, the attribute will get reset, and then it will call
 NEXTKEY too and you will get strange increments.

Yup, that's exactly what I was talking about without going into details
:) thanks for expanding on this!

 This does not affect cases where you'd never call each() or keys(), but you
 see the kind of mess one could get into. However, in order to avoid a tie()
 on all requests it might be possible to put the tie()ing code inside a
 ChildInitHandler (untested).

I suppose that this is pretty much what should be advised. It doesn't give
you much benefit anyway to have only one shared fd, since the data is in
the dbm files and it's not shared per se. The situation is of course
different if you copy the whole dbm into a memory. Then it makes sense to
do it once for all processes to share (read-only case).


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: sharing tied dbm fd

2000-12-11 Thread barries

On Mon, Dec 11, 2000 at 05:08:29PM +0100, Stas Bekman wrote:
  At 22:11 10/12/2000 +0100, Stas Bekman wrote:
  
  I don't know whether or not you're correct as I haven't tested this (which
  I guess is the only way to really know :). I don't much about fd's either,

I tested sharing fds beteen parent  child, but not dbms, and it breaks
as expected.  sysseek() in one process alters the internals of the fd,
tripping up the other process if it happens between seek and read.

You'd have to be very careful to use locks and re-seek before each I/O.
If dbm does re-seek, and you are using locks, it should be Ok, I'd
guess.  Make sure to get a locker that flushes the fd and the 4k header
before unlocking, though.

  but one thing that I think could cause trouble is indeed each() and keys(),
  and this applies to any kind of tied hash, not just dbm tied hashes.

good explanation snipped

 Yup, that's exactly what I was talking about without going into details
 :) thanks for expanding on this!

I'm confused: how can one process' internal variables (the attribute set
to 0 in the example snipped above) affect another process'?

If this were the case, then any use of each() in forked children would
be badly broken.  What am I missing?

- Barrie



Re: mod_perl advocacy project resurrection

2000-12-11 Thread Jim Woodgate


Matt Sergeant writes:
  
  Except that won't scale beyond 1 server...

If I needed to go beyond one server in java, I would probably look at
something like Objectspace Voyager, which is the easiest to use orb
I've ever seen.  Is there anything similar in perl? I'd love to try it
out!

-- 
[EMAIL PROTECTED]



ORBs

2000-12-11 Thread Matt Sergeant

On Mon, 11 Dec 2000, Jim Woodgate wrote:


 Matt Sergeant writes:
  
   Except that won't scale beyond 1 server...

 If I needed to go beyond one server in java, I would probably look at
 something like Objectspace Voyager, which is the easiest to use orb
 I've ever seen.  Is there anything similar in perl? I'd love to try it
 out!

CORBA::ORBit is very simple to use. I'd be very interested in hearing from
anyone who has used this in a mod_perl project.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




RE: Still bugs in Apache::Dispatch with .htaccess

2000-12-11 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Monday, December 11, 2000 11:57 AM
 To: Geoffrey Young
 Subject: RE: Still bugs in Apache::Dispatch with .htaccess
 
 
 On Mon, 11 Dec 2000, Geoffrey Young wrote:
 
 
 
  I've started poking around...
 
  in order to allow .htaccess configurations we have to be 
 able to accomodate:
  /Foo/Bar/Baz/foo  where .htaccess lives in Foo:  Prefix +
  Bar::Baz-foo()
  /Foo/Bar/Baz/foo  where .htaccess lives in Bar:  Prefix 
 + Baz-foo()
 
  yuk.  with Location you don't have to worry about the 
 left hand side...
 
 OK, so how about a new directive: DispatchBase. If that is set, remove
 that from $r-filename, and use that as the base path. 
 Otherwise use the
 $r-location method.

yeah, I thought about that too - it would involve less overhead than
scanning for the location of the .htaccess file, but wouldn't be as friendly
as DispatchAccess On.

I also don't want to confuse people, though.  The issue here is Directory
v. Location and not specifically .htaccess files (any more, at least :) -
applying this to a Location could start to get obscure (as if it isn't
already :)

DispatchTrim "/usr/local/apache/htdocs/"  ?
DispatchBase (which is probably what I should have called DispatchISA) ?
DispatchDirectory ?

or do both that and have a .htaccess scan as well?

--Geoff


 
 -- 
 Matt/
 
 /||** Director and CTO **
//||**  AxKit.com Ltd   **  ** XML Application Serving **
   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
  // \\| // ** Personal Web Site: http://sergeant.org/ **
  \\//
  //\\
 //  \\
 



RE: Still bugs in Apache::Dispatch with .htaccess

2000-12-11 Thread Matt Sergeant

On Mon, 11 Dec 2000, Geoffrey Young wrote:

 
  OK, so how about a new directive: DispatchBase. If that is set, remove
  that from $r-filename, and use that as the base path.
  Otherwise use the
  $r-location method.

 yeah, I thought about that too - it would involve less overhead than
 scanning for the location of the .htaccess file, but wouldn't be as friendly
 as DispatchAccess On.

 I also don't want to confuse people, though.  The issue here is Directory
 v. Location and not specifically .htaccess files (any more, at least :) -
 applying this to a Location could start to get obscure (as if it isn't
 already :)

 DispatchTrim "/usr/local/apache/htdocs/"  ?
 DispatchBase (which is probably what I should have called DispatchISA) ?
 DispatchDirectory ?

 or do both that and have a .htaccess scan as well?

I'd make it as simple as possible. Make it DispatchRoot (akin to
DocumentRoot). Don't try and do anything fancy.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




Apache / ModPerl and IPv6

2000-12-11 Thread Jimi Thompson

I know this is off topic, but does anyone know if the config files in
Apache support IPv6 addresses?

--
Jimi Thompson
Web Master
L3 communications

"It's the same thing we do every night, Pinky."



begin:vcard 
n:Thompson;Jimi
tel;pager:877-309-2784
tel;cell:817-980-7863
tel;work:817-619-3612
x-mozilla-html:FALSE
url:hww
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:Jimi Thompson
end:vcard



Re: mod_perl in chroot environment

2000-12-11 Thread Matthew Byng-Maddick

On Sun, 10 Dec 2000, Gunther Birznieks wrote:
 At 03:33 PM 12/10/00 +0100, Stas Bekman wrote:
 Do you think I should include the scenario of making Apache run in chroot
 enviroment in the guide?
 I think chroot Apache is important especially for dynamic services.

Definitely.

 For example, perhaps the mod_perl server and the HTML/images server should 
 be separately chrooted from each other? That way, someone who breaks the 
 dynamic script won't be able to mess with the frontpage of the website to 
 deface it assuming the hacker could get around permissions issues within 
 the chroot jail.

Why do you need the proxy server to be chrooted at all? what does that
gain you. After all if apache is insecure, you can break out of the
chroot()ed jail anyway.

 BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow 
 necessary once the chroot jail is in effect? The author creates a shadow 

Well, you've lost if you break root inside a traditional chroot() (as
opposed to FreeBSD4's jail() - 
1) attacker can mknod() (and can therefore attack kmem.
2) attacker can call chroot()
   - int j; mkdir("./bin"); chroot("./bin");
 for(j=0;jPATH_MAX;j++) chdir(".."); chroot(".");

In which case the shadow file can be there. What isn't there is a way to
get root (any suid programs or similar). You hope. :)

 file but it seemed odd to me. He also advocates copying it over and then 
 creating a new one from scratch which seems redundant and potentially 
 dangerous if the second step is forgotten.

Very much so, agreed.

MBM

-- 
Matthew Byng-Maddick   Home: [EMAIL PROTECTED]  +44 20  8981 8633  (Home)
http://colondot.net/   Work: [EMAIL PROTECTED] +44 7956 613942  (Mobile)
philosophy, n.:   Unintelligible answers to insoluble problems.




open/opendir/readdir fail under latest perl/mod_perl/apache

2000-12-11 Thread Richard Dice

Everyone:

Here's something that myself and my sysadmin guy have been working on
for a bit:  opendir appears to be broken for us on a new Apache/mod_perl
installation.

We've tried checking out the mailing list archives but nothing jumpped
out at us along these lines.

Any ideas from anyone? (much more info follows...)

Thanks,

   - Richard

(BTW, "use CGI::Carp 'fatalsToBrowser';" causes our installation to 
segfault when included in my startup.perl program, which is invoked
from within httpd.conf with 'PerlRequire startup.perl'... just to muddy
the waters some more. :-) )

(BTW 2, do Apache::Registry scripts now allow variable _not_ to have
explicit package declaration and/or explicit lexical declarations?
Damian is showing me a program that he wrote that has neither, and yet
runs under Apache::Registry, and this freaks me out.)

 Original Message 
Subject: open/opendir/readdir fail under latest perl/mod_perl/apache.
Date: Mon, 11 Dec 2000 13:17:59 -0500
From: Damian M Gryski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]

   I've been trying to use opendir/readdir under mod_perl 1.24 with
   apache 1.2.14 under Debian GNU/Linux.  The system is an up-to-date
   Debian `woody' system, and so is using the .deb of perl 5.6.0

   The problem is that while neither opendir nor readdir actually return
   errors, they also don't return the results I'm expecting: namely,
   the directory contents.  Instead, the results consist of a list
   containing the correct # of items, but each item is a zero-length
   scalar (and _not_ the undefined value!) rather than a filename.

   This problem does not occur on a system running mod_perl 1.24
   with apache 1.3.12 and perl 5.005_03.  I can't find anything in the
   changelog for either mod_perl or apache suggesting a change in how
   opendir is used.

   Here's some example code that fails:

---8 CUT HERE 8---
#!/usr/bin/perl

use strict;

my $some_dir = "/home/dmg";

opendir(DIR, $some_dir) || die "can't opendir $some_dir: $!";
my @files = readdir(DIR);
closedir(DIR);

print "Content-type: text/plain\n\n";
print join("\n", @files), "\n";
exit 0;
---8 CUT HERE 8---

   On the working system, it correctly produces the list of files
   in my home directory.  On the `broken' system, it produces a list
   of zero-length strings. (On both systems, it works when run from the
   command line.)

   TIA,

   Damian

-- 
Damian Gryski
ShadNet Admin
[EMAIL PROTECTED]



RE: Still bugs in Apache::Dispatch with .htaccess

2000-12-11 Thread Geoffrey Young



 -Original Message-
 From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
 Sent: Monday, December 11, 2000 1:27 PM
 To: Geoffrey Young
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: Still bugs in Apache::Dispatch with .htaccess
 
 
 
 I'd make it as simple as possible. Make it DispatchRoot (akin to
 DocumentRoot). 

  I like that name (and concept) better...


 Don't try and do anything fancy.

  but that's so much more fun ;)

--Geoff

 
 -- 
 Matt/
 
 /||** Director and CTO **
//||**  AxKit.com Ltd   **  ** XML Application Serving **
   // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
  // \\| // ** Personal Web Site: http://sergeant.org/ **
  \\//
  //\\
 //  \\
 



Re: open/opendir/readdir fail under latest perl/mod_perl/apache

2000-12-11 Thread Stas Bekman

On Mon, 11 Dec 2000, Richard Dice wrote:

 Everyone:
 
 Here's something that myself and my sysadmin guy have been working on
 for a bit:  opendir appears to be broken for us on a new Apache/mod_perl
 installation.

Rich, please send in the relevant parts of the strace output, or may be
you will learn what's the problem while looking at it. I doubt it has
anything to do with mod_perl. Does this code work from the command line?

FYI, your code works for me...

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  






Apache::asp

2000-12-11 Thread Eran Keshet

hi,
im trying 2 call the "handler" function in Apache::asp from a perl module
(in apache with mode_perl),
i need 2 pass parameters 2 that function like the filename, and i tried 2
modify the handler function accordingly,
but i keep getting errors like " [client 10.10.10.19] need AuthName: /Test"
,
and i also need 2 change the file type from html 2 other types (like .wml)
does anyone have experience in this stuff ?

10x

eran




Re: open/opendir/readdir fail under latest perl/mod_perl/apache

2000-12-11 Thread Richard Dice

 Have you looked at the permissions and verified that the uid of the user
 running apache has permissions to list the contents of the directory?

It's a good suggestion, but we've been all up and down this one over
here.  (For instance, if it didn't have perms, then the opendir/readdir
commands would fail -- they're not failing, they're just giving garbage
output.)

Damian and I are now going through strace, per Stas' suggestion.
That didn't seem to yield any useful info, but we'll bring it to the 
list eventually.

We're now giving ltrace a go... sure, it yields a few gigabytes of
log information, but you gotta do what you gotta do...

Cheers,
  - Richard

-- 

 Richard Dice * Personal 519 635 9568 * Fax 519 635 9569
 ShadNet Creator * http://shadnet.shad.ca/
 Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/
 "squeeze the world 'til it's small enough to join us heel to toe"
 - jesus jones



'why mod_perl' rebate anybody?

2000-12-11 Thread Stas Bekman

As it was said before, successfull projects are self-fueled once they get
to the press. Look at this article dated Nov 7, 2000.
http://www.WebDevelopersJournal.com/articles/why_php.html

The article starts with what seems to be a hard evidence:

"According to NetCraft surveys, PHP is now the most popular module for the
Apache server and in total running on something like two million Web
sites. Here are some of the reasons why PHP is such a popular server side
scripting language"

But nobody knows how many mod_perl servers out there, since many run
behind the proxy so NetCraft stats aren't really correct. So it's possible
that there are more mod_perl servers than mod_php servers... well, we
don't know...

Anyone is willing to write a rebate
article? Please contact [EMAIL PROTECTED] .

BTW, I'm not saying that article is not fair -- it's very fair. It's just
that it doesn't mention mod_perl (only Perl...). So may be it's not a
rebate call but "me too" article request :)

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: open/opendir/readdir fail under latest perl/mod_perl/apache

2000-12-11 Thread Stas Bekman

On Mon, 11 Dec 2000, Richard Dice wrote:

  Have you looked at the permissions and verified that the uid of the user
  running apache has permissions to list the contents of the directory?
 
 It's a good suggestion, but we've been all up and down this one over
 here.  (For instance, if it didn't have perms, then the opendir/readdir
 commands would fail -- they're not failing, they're just giving garbage
 output.)

yup :)

 Damian and I are now going through strace, per Stas' suggestion.
 That didn't seem to yield any useful info, but we'll bring it to the 
 list eventually.
 
 We're now giving ltrace a go... sure, it yields a few gigabytes of
 log information, but you gotta do what you gotta do...

It shouldn't be gigabytes -- you want to strace only special events like
open and read, and you want to attach to the process only before running
the script (run under -X) -- so you should have just a few lines!!!

 % strace -p PID -e trace=open,read



_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: File name conversion

2000-12-11 Thread Aaron Johnson

That is just what I was looking for.

I just modified the $r-filename and left $r-uri untouched.

10 lines of code and I have it doing exactly what I needed and Apache::ASP reads
the correct file.
I still have the $ENV{REQUEST_URI} to check for the orginal name requested, there
by allow me to set options based on it.

I see now it is in the Guide as well at:
http://thingy.kcilink.com/modperlguide/snippets/PerlTransHandler_example.html

Not knowing what I needed to do was called (or what phase it was best handled) was
the root of my problem.

Thanks!

Aaron Johnson

darren chamberlain wrote:

 Hi Aaron,

 Check out the section titled "Using a Translation Handler to Change the
 URI" in Chapter 7 of the Eagle book, at
 http://www.modperl.com/book/chapters/ch7.html#Using_a_Translation_Handler_to_C.

 Aaron Johnson ([EMAIL PROTECTED]) said something to this effect:
  Is there a module that allows you to translate the file name into
  something else, but keeps the requested filename in an enviroment
  variable or other location?

 (darren)

 --
 So far as a man thinks, he is free.




Re: Linux Hello World Benchmarks...

2000-12-11 Thread Joe Schaefer

Joshua Chamas [EMAIL PROTECTED] writes:

 Joe Schaefer wrote:
  
  IME, simple mod_perl handlers typically run around 50% as fast as
  HTML static pages.  Your hello world benchmark seems to be slightly
  misleading in this respect, since the content-length is small
  relative to the header size.
  
 
 I'll send you my benchmark suite separately so you can
 submit your results for http://www.chamas.com/bench.  I have
 never seen modperl handler faster than static HTML.

Me neither - what I said was that modperl handlers are about twice
as slow as static pages.  That's what I meant, but I guess didn't
make it clear.

Best.
-- 
Joe Schaefer



Re: Apache::asp

2000-12-11 Thread Joshua Chamas

Eran Keshet wrote:
 
 hi,
 im trying 2 call the "handler" function in Apache::asp from a perl module
 (in apache with mode_perl),
 i need 2 pass parameters 2 that function like the filename, and i tried 2
 modify the handler function accordingly,
 but i keep getting errors like " [client 10.10.10.19] need AuthName: /Test"
 ,

Just set AuthName in your httpd.conf.  I'll make this error go away
next release.  Also, set $r-filename($value) before you call the handler
and your file will work fine.  

 and i also need 2 change the file type from html 2 other types (like .wml)
 does anyone have experience in this stuff ?
 

$Response-{ContentType} ... you can do this for all your scripts
in your global.asa Script_OnStart based on matching the file's
extension.

-- Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: open/opendir/readdir fail under latest perl/mod_perl/apache

2000-12-11 Thread Richard Dice

 It shouldn't be gigabytes -- you want to strace only special events like
 open and read, and you want to attach to the process only before running
 the script (run under -X) -- so you should have just a few lines!!!
 
  % strace -p PID -e trace=open,read

I was talking about ltrace, not strace, when I said it would take gigs.
And even then, I was wrong -- it was only about 50mb.  (And that didn't
take into account specifiying which events to trace on.)

Anyhow... here are the results...

Test program: /web/ShadNet/sys/cvs/webdocs/foo.mp  (no, it's
not the same as the one before... I tried an IO::Dir object
this time, but it makes an underlying call to Perl's 'opendir',
so it's equivalent to what I had before)
---
#!/usr/bin/perl -w

use strict;

use IO::Dir;

my $dir = new IO::Dir "/web/ShadNet/sys/cvs/webdocs";

print "Content-type: text/plain\n\n";

if ( defined($dir)) {
while (defined($_ = $dir-read)) {
print "[$_]\n";
}
}

undef $dir;

exit 0;
---

This works from the command line but not from Apache::Registry.

strace of seemingly-relevant bits via command line:
(this works)
---
munmap(0x40017000, 4096)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
open("/dev/null", O_RDONLY|O_NONBLOCK|0x1) = -1 ENOTDIR (Not a directory)
open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 4
fstat(4, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
brk(0x81ca000)  = 0x81ca000
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40017000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "Content-type: text/plain\n", 25) = 25
write(1, "\n", 1)   = 1
getdents(4, /* 43 entries */, 3391) = 936
write(1, "[.]\n", 4)= 4
write(1, "[..]\n", 5)   = 5
write(1, "[CVS]\n", 6)  = 6
write(1, "[accountclaim]\n", 15)= 15
write(1, "[AppletTag.pm]\n", 15)= 15
write(1, "[admin-login.mp]\n", 17)  = 17
write(1, "[bugs.mp]\n", 10) = 10
write(1, "[bugs.mp.save]\n", 15)= 15
write(1, "[finger.mp]\n", 12)   = 12
write(1, "[index.mp]\n", 11)= 11
write(1, "[login.mp]\n", 11)= 11
write(1, "[logout.html]\n", 14) = 14
write(1, "[logout.mp]\n", 12)   = 12
write(1, "[menu.mp]\n", 10) = 10
write(1, "[motd.mp]\n", 10) = 10
write(1, "[msie.mp]\n", 10) = 10
write(1, "[newshad.mp]\n", 13)  = 13
write(1, "[nph-changegroup.mp]\n", 21)  = 21
write(1, "[nph-changelanguage.mp]\n", 24) = 24
write(1, "[nph-validate.mp]\n", 18) = 18
write(1, "[other.mp]\n", 11)= 11
write(1, "[page.mp]\n", 10) = 10
write(1, "[parsechangelog.mp]\n", 20)   = 20
write(1, "[poll.mp]\n", 10) = 10
write(1, "[shadfont.css]\n", 15)= 15
write(1, "[shadnet.css]\n", 14) = 14
write(1, "[shownews.mp]\n", 14) = 14
write(1, "[admin]\n", 8)= 8
write(1, "[alumni]\n", 9)   = 9
write(1, "[common]\n", 9)   = 9
write(1, "[developers]\n", 13)  = 13
write(1, "[development]\n", 14) = 14
write(1, "[online]\n", 9)   = 9
write(1, "[partner]\n", 10) = 10
write(1, "[password]\n", 11)= 11
write(1, "[polls]\n", 8)= 8
write(1, "[static]\n", 9)   = 9
write(1, "[util]\n", 7) = 7
write(1, "[classes]\n", 10) = 10
write(1, "[test-opendir.mp]\n", 18) = 18
write(1, "[test-opendir.mp~]\n", 19)= 19
write(1, "[foo.mp]\n", 9)   = 9
write(1, "[foo.mp~]\n", 10) = 10
getdents(4, /* 0 entries */, 3391)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
close(4)= 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
munmap(0x40017000, 4096)= 0
_exit(0)= ?
---

strace of seemingly-relevant bits via Apache::Registry
(this doesn't work)
---
munmap(0x40018000, 4096)= 0
open("/dev/null", O_RDONLY|O_NONBLOCK|0x1) = -1 ENOTDIR (Not a directory)
open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 5
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl(5, F_SETFD, FD_CLOEXEC)   = 0
brk(0x858d000)  = 

Re: mod_perl training (was Re: Certification)

2000-12-11 Thread J. J. Horner

On Sun, Dec 10, 2000 at 06:13:13PM +0800, Gunther Birznieks wrote:
 It sounds to me like you have hit the nail on the head. Perhaps what is 
 needed in terms of recouping costs for a mod_perl hands-on development 
 course and/or online course is the open source/collaborative approach.
 
This seems to be a good solution to this problem.  Instead of 
one person sucking up the costs of developing these courses, we could
get a group together to do this.  Sounds good to me.

 I would be willing to donate my time to write and initially test the 
 exercises to the slides that are taught for the days. If a couple people 
 were to donate their time to writing the slides based on an outline 
 produced by Stas and Randal.
 

So would I.  I'm more than willing to proof read, test, and be a guinea pig.


 We could host it on sourceforge as the modperltraining project. Sourceforge 
 could also host the mailing list.
 
 Then regardless of if Randal would then be willing to take the course 
 material and beta test it as a class he offers (eg maybe giving the course 
 itself would not be profitable for him), we ourselves could be giving this 
 course all over the world in beta-test Perl Monger groups.
 

Yet another good idea.  We all love open-source, and collaborative efforts, so 
let's create a good set of training materials, and then let people teach this
material in their own neighborhoods.  


 I know there are still issues such as getting people of the same level of 
 expertise in the same room and mod_perl not being a "core" technology, but 
 I think mod_perl can be taught assuming similar requirements as the PROM 
 class you offer as an initial thought? mod_perl doesn't require all of 
 PROM, but probably about a day of it would be integrated to bring people up 
 to speed on the basics?

You lost me here.  I'm not sure what "core" technology means.  I always thought
it would be relatively easy for an experienced teacher to develop a coherent, 
reliable course for mod_perl, as long as some requirements are met (able to program
perl and able to configure and administer an apache server).  Once those guidelines
are met, discussing the Apache API, going into detail on each of the response phases,
and going through examples and exercises, would flow somewhat unfettered.

1.  the Apache server life cycle
2.  the request loop
3.  Discussion of the API for each phase of the loop with examples
4.  Exercises

This would take about 3 (maybe 4) days with someone who meets the pre-reqs.  1 for the 
intro and terminology
1 long day to discuss the APIs for each phase (maybe two), and 1 day to go over
exercises and have some "lab" work.

This is just a rough estimate, and if someone thinks I've lost my coconuts let me know.
Getting someone up to speed on mod_perl (not Apache::* modules, but the perl API to 
Apache),
shouldn't take too long.  I'd say about 1-1.5 hours for each stop in the request loop. 
 4-5 
hours to teach someone the guts of Apache, including terminology and the real base 
knowledge
stuff, and 8-10 hours to go over exercises, and develop skeleton handlers.

We are looking at about 30 hours of hard, hard work.  They don't call some training 
sessions
"boot camps" for nothing.

Again, feedback is good.  Just make it constructive.  Calling me a "moronic putz" 
isn't helpful, 
but saying "Hey, Moronic Putz, you underestimate " is good.


 helping with this project, please email me privately. If I get enough 
 people willing to contribute (at least 5), I'll set up the sourceforge 
 project to start the ball rolling Oh yeah, did I say I didn't mind donating 
 my admin time as well to this experiment. :)

Count me in.  I'll be willing to guinea pig stuff and give feedback, as well
as do research and help out more experienced teachers.


 
 Later,
 Gunther
 
 

JJ
-- 
J. J. Horner 
[EMAIL PROTECTED]
Apache, Perl, mod_perl, Web security, Linux




Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread tom

Er. I think you mean 'rebuttal'.
I don't know what kind of rebate anyone's expecting from mod_perl, since it's free.
In fact, more people might be expecting to pay for it ;-)

Tom 



[OT] Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread Aaron Johnson

Actually in some context rebate will do.

One meaning of rebate is:
Middle English rabet, from Old French rabat:
recess in a wall, act of beating down,
from rabattre,
to beat down again;

Is rebate in the sense of the word that the amount is reduced an American thing?

Aaron Johnson

[EMAIL PROTECTED] wrote:

 Er. I think you mean 'rebuttal'.
 I don't know what kind of rebate anyone's expecting from mod_perl, since it's free.
 In fact, more people might be expecting to pay for it ;-)

 Tom




Re: sharing tied dbm fd

2000-12-11 Thread Robin Berjon

At 11:55 11/12/2000 -0500, barries wrote:
I tested sharing fds beteen parent  child, but not dbms, and it breaks
as expected.  sysseek() in one process alters the internals of the fd,
tripping up the other process if it happens between seek and read.

I guess that's pretty much to be expected.

I'm confused: how can one process' internal variables (the attribute set
to 0 in the example snipped above) affect another process'?

If this were the case, then any use of each() in forked children would
be badly broken.  What am I missing?

I don't think that you're missing anything. I on the other hand was
probably missing much, much caffeine and some anti-cold medicine. If the
hash is truly shared then such problems will crop up, but as soon as it
goes to individual processes, unless the tied implementation somehow keeps
it's state elsewhere, no problem should occur. Maybe the problem would
occur in a threaded environment, but I haven't played with threads in Perl
and that's another question altogether. We'll see to that when mod_perl 2
comes out :)

Well, at least I hope that if there were people on the list that didn't
know how tied hashes worked and were curious about that they've learnt
something :)

-- robin b.
I'm not a complete idiot - some parts are missing! 




Re: [OT] Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread Robin Berjon

At 15:58 11/12/2000 -0500, Aaron Johnson wrote:
Actually in some context rebate will do.

One meaning of rebate is:
Middle English rabet, from Old French rabat:
recess in a wall, act of beating down,
from rabattre,
to beat down again;

Is rebate in the sense of the word that the amount is reduced an American 
thing?

I don't think so. Both usages come from the French rabat/rabattre/rabaisser
(rabattre and rabaisser have somewhat branched in French but they were the
same back then). Rabaisser has the amount reduced meaning (amongst others)
while rabattre is what you do when you bring something to a specific place
using various techniques. You would rabattre (rebate) a prey to where it
might be caught (eg by having lots of advertising people beating drums in
the forest so that you run away to the place where the marketing people are
ambushed to sell something to you).

-- robin b.
After all, what is your hosts' purpose in having a party?  Surely not for
you to enjoy yourself; if that were their sole purpose, they'd have simply
sent champagne and women over to your place by taxi.




Re: [OT] Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread tom

 Is rebate in the sense of the word that the amount is reduced an American thing?

Hmmm. I hadn't thought about it, but come to think of it, I think it is used more 
extensively in America. The sense it has here is more of a partial refund, as in "Buy 
this mouse and send in the manufacturer's coupon - you get a $10 rebate"
Or as in tax rebate.

I'm actually English, but I can't really think of it being used much in England. Or 
maybe I've just been here too long :)

Tom



Re: open/opendir/readdir fail under latest perl/mod_perl/apache

2000-12-11 Thread Stas Bekman

On Mon, 11 Dec 2000, Richard Dice wrote:

  It shouldn't be gigabytes -- you want to strace only special events like
  open and read, and you want to attach to the process only before running
  the script (run under -X) -- so you should have just a few lines!!!
  
   % strace -p PID -e trace=open,read
 
 I was talking about ltrace, not strace, when I said it would take gigs.
 And even then, I was wrong -- it was only about 50mb.  (And that didn't
 take into account specifiying which events to trace on.)

Hmm, its manpage says : Its use is very similar to strace(1) but it's
irrelevant to the problem..
 
The only relevant bits are those where syscalls interact with the dir fd
more or less, so that's what's left:

 open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 4
 fstat(4, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
 fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
 brk(0x81ca000)  = 0x81ca000
[snip interaction with STDOUT(fd=1)]
 getdents(4, /* 43 entries */, 3391) = 936

fd==4, and we have 43 files and it's fine.

now the registry script which is broken:

 open("/web/ShadNet/sys/cvs/webdocs", O_RDONLY|O_NONBLOCK|0x1) = 5
 fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
 fcntl(5, F_SETFD, FD_CLOEXEC)   = 0
 brk(0x858d000)  = 0x858d000
 alarm(300)  = 0
 alarm(0)= 300
 getdents(5, /* 43 entries */, 2980) = 936

all fine till now the same 43 entries are read, and the alarm(0)  calls,
which appear on my system as well.

 alarm(300)  = 0
 alarm(0)= 300

apparently 43 times...

What happens if you run the same code on the server with no preloaded
modules and configurations? Only the registry alias?

Obviously using IO::Dir won't help you to debug this problem but will make
it even more complicated.

Another thing to try: 'su - httpd' or whatever user you are running the
server under and now run the script from the command line. Since you
probably don't have the passwd for httpd do 'su' to become root first.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread Stas Bekman

 Er. I think you mean 'rebuttal'.
 I don't know what kind of rebate anyone's expecting from mod_perl, since it's free.
 In fact, more people might be expecting to pay for it ;-)

So you've know my secret now... my English sucks... please don't tell
anybody... Now you start wondering how he [me] is capable of writing a
book... in English... well it's easy, I write it in Russian using English
words and a few folks are translating it to the proper English... cvs
helps a lot :)

Anyway at least the subject has pulled attention to the post (at least
among our American readers :)

So anybody wants to write a rebuttal? Don't you care about making mod_perl
more known at least in the web developers forum? I suppose this kind of
magazines are read by IT people.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/  





Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread Jimi Thompson

Count me in!  I'll help!

Stas Bekman wrote:

  Er. I think you mean 'rebuttal'.
  I don't know what kind of rebate anyone's expecting from mod_perl, since it's free.
  In fact, more people might be expecting to pay for it ;-)

 So you've know my secret now... my English sucks... please don't tell
 anybody... Now you start wondering how he [me] is capable of writing a
 book... in English... well it's easy, I write it in Russian using English
 words and a few folks are translating it to the proper English... cvs
 helps a lot :)

 Anyway at least the subject has pulled attention to the post (at least
 among our American readers :)

 So anybody wants to write a rebuttal? Don't you care about making mod_perl
 more known at least in the web developers forum? I suppose this kind of
 magazines are read by IT people.

 _
 Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
 http://stason.org/   mod_perl Guide  http://perl.apache.org/guide
 mailto:[EMAIL PROTECTED]   http://apachetoday.com http://logilune.com/
 http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

--
Jimi Thompson
Web Master
L3 communications

"It's the same thing we do every night, Pinky."



begin:vcard 
n:Thompson;Jimi
tel;pager:877-309-2784
tel;cell:817-980-7863
tel;work:817-619-3612
x-mozilla-html:FALSE
url:hww
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:Jimi Thompson
end:vcard



PerlChildInitHandler not being called

2000-12-11 Thread Paul J. Lucas

I looked int he archives for this problem and, while mentioned,
not definitive solution was apparantly found.  I did notice the
handler get called once, but only once: total server shutowns
and restarts don't make it get called.

I'm using Apache 1.3.12, mod_perl 1.24_01, Perl 5.6 under Linux.

- Paul




Re: mod_perl class

2000-12-11 Thread Richard Routh

OK,
 J. J. Horner writes:
 I would be willing to donate my time to write and initially test
 the exercises to the slides that are taught for the days. If a
 couple people were to donate their time to writing the slides
 based on an outline produced by Stas and Randal.


I will write the slides if they are still needed!

If I can clarify this for anyone please respond and I will gladly review
this.

Mit Freundlichen GrĂ¼ssen/Kind Regards/Met Vreundlijke Groet,

To invent, you need a good imagination and a pile of junk.  -- Thomas Alva
Edison (1847-1931)

Richard Routh
ABS -  GO Strategic IP Network Services
Vox: 863-965-7773
Fax: 209-882-9276
Email:  [EMAIL PROTECTED]

Good management consists of showing average people how to do the work of
superior people.  John D. Rockefeller



Nathan Torkington [EMAIL PROTECTED] on 12/11/2000 03:44:02 PM

To:   [EMAIL PROTECTED]
cc:
Subject:  mod_perl class



J. J. Horner writes:
 I would be willing to donate my time to write and initially test
 the exercises to the slides that are taught for the days. If a
 couple people were to donate their time to writing the slides
 based on an outline produced by Stas and Randal.

 So would I.  I'm more than willing to proof read, test, and be a
 guinea pig.

http://prometheus.frii.com/~gnat/mod_perl/ holds the PowerPoint slide
source and the PDF produced from it, of the course I taught at
O'Reilly's University of Perl earlier this year.  I'm happy to have
this become the basis for an open source mod_perl class.  The "course
book" for this is the Eagle book, "Writing Apache Modules in Perl and
C" published by O'Reilly.

There are bugs in some of the code in the class, I know.  I have
revised versions of some of the programs but haven't had time to add
them.  A volunteer who already knows mod_perl and has ability to edit
PowerPoint files would be useful here to do this work.

A full class will need not just slides but:

 * text for the teacher on what should be said for this slide
   (doesn't have to be a transcription, just an idea of how deep to
   go into each bullet point)

 * labs with sample answers

And finally, please note that I'm not Randal.

Nat





Re: mod_perl in chroot environment

2000-12-11 Thread Gunther Birznieks

At 10:51 AM 12/11/00 -0500, Vivek Khera wrote:
  "SB" == Stas Bekman [EMAIL PROTECTED] writes:

SB Do you think I should include the scenario of making Apache run in
SB chroot enviroment in the guide?

That require quite a bit of stuff be crammed into the chroot jail.
You'll need an entire perl install there, wouldn't you?  It might make
sense for a front-end of a two-tier setup, but the mod_perl instance
seems to me a bit big.  But I guess some people will want the extra
safety of it.  Personally I think it is a bit much to cram into a
chroot environment.
I believe it is especially the dynamic application portion of a web server 
that should be chrooted from the rest of the OS. How many CGI scripts have 
you seen that allow /etc/passwd to be read? Or arbitrary commands to be run 
on the system versus buffer overflows in Apache?

Even mod_perl and taintmode may not prevent this stuff (well maybe the 
arbitrary commands).

Furthermore, I trust Apache to be more secure from buffer overflows than 
the Perl interpreter stuck inside Apache (same with mod_php though)... 
Language interpreters are large and complex beasts. It's probable that if 
they still have memory leaks that some of the bugs in the interpreters 
could result in buffer overflow too.

I guess I trust the Apache group to be more diligent on security than Perl 
programmers developing custom apps in a highly pressured environment (eg 
startups, or whatnot) and that it is the Perl developers (or web app 
developers of any genre) which are more likely to have security bugs.

I know very few web developers who have read anything on security beyond a 
few security advisories if they made main news... They are so busy learning 
Java or the latest Perl trick.  I am not saying this is bad, but just 
realistic. Of course, I'd rather all developers get educated in security. 
But frankly, speaking as a developer, I find myself overwhelmed by the 
complexity of the custom apps that are being demanded these days in real 
environments, and I can only imagine that there are security bugs in those 
apps even with the knowledge I now have.

Why? Because I'm a bad developer? Well, maybe, but it's closer to what 
Lincoln Stein says in the W3C Security FAQ. Paraphrased: because all 
programs have bugs, large and complex programs have more bugs, and there is 
always a probability that some of those bugs are security bugs. The more 
complex the program, the more likely there are security bugs.

Of course, as Stas pointed out earlier, he is saying he would still have 
just one copy of the Perl interpreter but the hard-copy of it would be in 
the chroot jail, so it wouldn't take up a lot of extra space.

So hopefully even space won't be an issue.

Later,
   Gunther




Re: mod_perl in chroot environment

2000-12-11 Thread Gunther Birznieks

I've snipped some stuff out of both sides.

At 09:58 AM 12/11/00 +, Matthew Byng-Maddick wrote:
On Sun, 10 Dec 2000, Gunther Birznieks wrote:
  At 03:33 PM 12/10/00 +0100, Stas Bekman wrote:

  For example, perhaps the mod_perl server and the HTML/images server should
  be separately chrooted from each other? That way, someone who breaks the
  dynamic script won't be able to mess with the frontpage of the website to
  deface it assuming the hacker could get around permissions issues within
  the chroot jail.

Why do you need the proxy server to be chrooted at all? what does that
gain you. After all if apache is insecure, you can break out of the
chroot()ed jail anyway.

If Apache is insecure it's not necessarily possible to break out of the 
chrooted jail. It depends on if the part of Apache that grabs the socket is 
insecure which is a tiny part of Apache.

Apache itself is large and complex and if you are talking about a front-end 
server, you are talking about having at minimum mod_proxy, mod_rewrite and 
maybe even mod_backhand. These modules are not trivial code but breaking 
them wouldn't allow someone to break out of the chroot jail with root 
privileges.

  BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
  necessary once the chroot jail is in effect? The author creates a shadow

Well, you've lost if you break root inside a traditional chroot() (as
opposed to FreeBSD4's jail() -
1) attacker can mknod() (and can therefore attack kmem.
2) attacker can call chroot()
- int j; mkdir("./bin"); chroot("./bin");
  for(j=0;jPATH_MAX;j++) chdir(".."); chroot(".");

Doesn't this require the root ID in order to issue .. chroots? I may be 
misunderstanding this portion of your statement.

In which case the shadow file can be there. What isn't there is a way to
get root (any suid programs or similar). You hope. :)

I agree that it's an important point to make is that any binary copied to 
the chroot jail should not be suid root as that would allow a point of attack.





Re: [OT] Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread Gunther Birznieks

At 01:23 PM 12/11/00 -0800, [EMAIL PROTECTED] wrote:
  Is rebate in the sense of the word that the amount is reduced an 
 American thing?

Hmmm. I hadn't thought about it, but come to think of it, I think it is 
used more extensively in America. The sense it has here is more of a 
partial refund, as in "Buy this mouse and send in the manufacturer's 
coupon - you get a $10 rebate"
Or as in tax rebate.

I'm actually English, but I can't really think of it being used much in 
England. Or maybe I've just been here too long :)
Apple uses the term rebate here in Singapore (eg right now they offer that 
if you buy a G4 + a crappy Apple monitor and get enough money back as a 
rebate to make buying the crappy monitor almost worth it).

Later,
Gunther

PS Don't tell anyone I am buying a G4...




[OT] Re: 'why mod_perl' rebate anybody?

2000-12-11 Thread Paul


A linguistics discussion on the mod_perl list.
Larry would be proud. =o)

Je pense, donc je sui! lol!

--- [EMAIL PROTECTED] wrote:
  Is rebate in the sense of the word that the amount is reduced an
 American thing?
 
 Hmmm. I hadn't thought about it, but come to think of it, I think it
 is used more extensively in America. The sense it has here is more of
 a partial refund, as in "Buy this mouse and send in the
 manufacturer's coupon - you get a $10 rebate"
 Or as in tax rebate.
 
 I'm actually English, but I can't really think of it being used much
 in England. Or maybe I've just been here too long :)
 
 Tom


=
"Seize the wildness of the moment, Feel the movement of the moon -- Swans fly with 
wings wide open to the sky." -- B-52's 
-
Real friends are those whom, when you inconvenience them, it bothers you more than 
them. -- me. =o) 
-
"There are trivial truths and there are great Truths. The opposite of a trival truth 
is obviously false. The opposite of a great Truth is also true."  -- Neils Bohr 
-
TEMPVS PECVDEM COLLARE EST - It's time to thin the herd.
-
[http://www.catfishforbreakfast.com/letgod.html]
-


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/



Linux Hello World: TT Optimized...

2000-12-11 Thread Joshua Chamas

Hey,

Updated results from the other day with the Template Toolkit 
benchmark properly optimized, thanks Perrin!  

The reference for these numbers is at: http://www.chamas.com/bench
If you would like the hello test suite, please email me separately.

]# ./bench.pl -time=60

Test Name Test FileHits/sec Total Hits   Total Time   sec/Hits 

      
 
Apache::ASP   hello.asp 414.1   24846 hits   60.00 sec0.002415 

Apache::Registry CGI Raw  hello_raw.re  741.7   44502 hits   60.00 sec0.001348 

Apache::Registry CGI.pm   hello.reg 500.0   30001 hits   60.00 sec0.002000 

HTML Static   hello.html   1215.7   5 hits   41.13 sec0.000823 

HTML::Embperl hello.epl 509.6   30579 hits   60.00 sec0.001962 

HTML::Mason   hello.mas 385.9   23153 hits   60.00 sec0.002592 

ModPerl Handler   hello.bench   885.8   5 hits   56.45 sec0.001129 

Template Toolkit  hello.tt  560.3   33622 hits   60.01 sec0.001785 


-- Josh

_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks  free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051



Re: Linux Hello World: TT Optimized...

2000-12-11 Thread newsreader

Could you please explain the differences between
CGI Raw and CGI.pm?  I'm using oo method of
CGI.

Thanks
   
On Mon, Dec 11, 2000 at 07:56:03PM -0800, Joshua Chamas wrote:
 Hey,
 
 Updated results from the other day with the Template Toolkit 
 benchmark properly optimized, thanks Perrin!  
 
 The reference for these numbers is at: http://www.chamas.com/bench
 If you would like the hello test suite, please email me separately.
 
 ]# ./bench.pl -time=60
 
 Test Name Test FileHits/sec Total Hits   Total Time   
sec/Hits 
       
 
 Apache::ASP   hello.asp 414.1   24846 hits   60.00 sec
0.002415 
 Apache::Registry CGI Raw  hello_raw.re  741.7   44502 hits   60.00 sec
0.001348 
 Apache::Registry CGI.pm   hello.reg 500.0   30001 hits   60.00 sec
0.002000 
 HTML Static   hello.html   1215.7   5 hits   41.13 sec
0.000823 
 HTML::Embperl hello.epl 509.6   30579 hits   60.00 sec
0.001962 
 HTML::Mason   hello.mas 385.9   23153 hits   60.00 sec
0.002592 
 ModPerl Handler   hello.bench   885.8   5 hits   56.45 sec
0.001129 
 Template Toolkit  hello.tt  560.3   33622 hits   60.01 sec
0.001785 
 
 -- Josh
 
 _
 Joshua Chamas Chamas Enterprises Inc.
 NodeWorks  free web link monitoring Huntington Beach, CA  USA 
 http://www.nodeworks.com1-714-625-4051



Re: Linux Hello World: TT Optimized...

2000-12-11 Thread Joshua Chamas

[EMAIL PROTECTED] wrote:
 
 Could you please explain the differences between
 CGI Raw and CGI.pm?  I'm using oo method of
 CGI.
 
 Thanks
 
 On Mon, Dec 11, 2000 at 07:56:03PM -0800, Joshua Chamas wrote:
  Hey,
 
  Updated results from the other day with the Template Toolkit
  benchmark properly optimized, thanks Perrin!
 
  The reference for these numbers is at: http://www.chamas.com/bench
  If you would like the hello test suite, please email me separately.
 

See http://www.chamas.com/bench/#perlcgi

The Raw CGI test makes no use of CGI.pm, just issues raw print 
statements that sets up the right CGI headers.  Please note that the 
number that I reported showed a difference of .00065 seconds of system 
time per request between CGI.pm  Raw CGI HelloWorld, so I wouldn't much 
worry about the environment overhead.

If you are using CGI.pm object methods, I would worry about calling 
all those methods to build your HTML and if you are performance 
minded, I would use them frugally.

--Josh



Re: Linux Hello World: TT Optimized...

2000-12-11 Thread Jeremy Howard

Joshua Chamas wrote:
 If you are using CGI.pm object methods, I would worry about calling
 all those methods to build your HTML and if you are performance
 minded, I would use them frugally.

IIRC, CGI.pm is actually slower to run the functional syntax than the object
syntax. This is because accessing CGI's functions end up getting dispatched
through a complex autoload(ish) mechanism.

I haven't benchmarked this though, so it's only theory!





RE: ORBs

2000-12-11 Thread Henrik Tougaard

 Matt Sergeant writes:
 
 CORBA::ORBit is very simple to use. I'd be very interested in 
 hearing from
 anyone who has used this in a mod_perl project.

We are currently using CORBA and mod_perl for scaleable access to databases.
The setup is:
  Web-server:  Apache::ASP and client-side COPE.
  App-server:  COPE and DBI.

We use COPE instead of CORBA::ORBit, as COPE runs just nicely on Digital
Unix (which we use) and ORBit is a hassle to port.

There are some not-to-nice mismatches here and there, especially in the
errorhandling - COPE, DBI and Apache::ASP use 3 different strategies and it
cvan be quite cumbersome to get things running smoothly -not impossible
though.

We hope to gain:
 - better scaleability: we can add more servers whenever a bottelneck
appears,
 - better security: the acces to the database is guarded by the app-servers
(who validate user access etc),
 - better modularity: the ASP-coders are mainly concered with appearance and
user-dialog, the app-servers handle the buisness logic.

Until now it seems to hold true.

--
Henrik Tougaard, [EMAIL PROTECTED]
Forbundet af Offentligt Ansatte, Copenhagen, Denmark.



Apache::Session benchmarks

2000-12-11 Thread Ed Park

FYI-- here are some Apache::Session benchmark results. As with all
benchmarks, this may not be applicable to you.

Basically, though, the results show that you really ought to use a database
to back your session stores if you run a high-volume site.

Benchmark: This benchmark measures the time taken to do a create/read for
1000 sessions. It does not destroy sessions, i.e. it assumes a user base
that browses around arbitrarily and then just leaves (i.e. does not log out,
and so session cleanup can't easily be done).

RESULTS: I tested the following configurations:

Apache::Session::MySQL - Dual-PIII-600/512MB/Linux 2.2.14SMP: Running both
the httpd and mysqld servers on this server. Average benchtime: 2.21 seconds
(consistent)

Apache::Session::Oracle - Ran the httpd on the dual-PIII-600/512MB/Linux
2.2.14SMP, running Oracle on a separate dual PIII-500/1G (RH Linux 6.2).
Average benchtime: 3.1 seconds (consistent). (ping time between the servers:
~3ms)

Apache::Session::File - Dual-PIII-600/512MB/Linux 2.2.14SMP: Ran 4 times.
First time: ~2.2s. Second time: ~5.0s. Third time: ~8.4s. Fourth time:
~12.2s.

Apache::Session::DB_File - Dual-PIII-600/512MB/Linux 2.2.14SMP: Ran 4 times.
First time: ~20.0s. Second time: ~20.8s. Third time: ~21.9s. Fourth time:
~23.2s.

The actual benchmarking code can be found at
http://www.lifespree.com/modperl/ (warning - the site is in a terrible state
right now, mostly a scratchpad for various techniques  benchmarks)

Question: does anyone know how to pre-specify the _session_id for the
session, rather than allowing Apache::Session to set it and read it? I saw
some posts about it a while back, but no code...

cheers,
Ed