Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev

2003-06-19 Thread Ged Haywood
Hi Stas,

On Wed, 18 Jun 2003, Stas Bekman wrote:

 Please try it out:
 http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz

Neat!

73,
Ged.

Script started on Wed Jun 18 13:29:03 2003
hurricane:~/src/Apache-Test-1.03-dev$  t/TEST -times=10 -order=random
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -times=10 -order=random
/usr/local/apache/bin/httpd -X -d 
/home/ged_demountable/src/Apache-Test-1.03-dev/t -f 
/home/ged_demountable/src/Apache-Test-1.03-dev/t/conf/httpd.conf -DAPACHE1 
using Apache/1.3.27 

waiting for server to start: .
waiting for server to start: ok (waited 0 secs)
server localhost:8529 started
*** Using random number seed: 894127215 (autogenerated)

[snip]

All tests successful.
Files=20, Tests=120, 10 wallclock secs ( 7.25 cusr +  1.44 csys =  8.69 CPU)
*** server localhost:8529 shutdown
hurricane:~/src/Apache-Test-1.03-dev$  
Script done on Wed Jun 18 13:29:26 2003



Re: Perl Testing

2003-06-19 Thread Stas Bekman
David Wheeler wrote:
On Tuesday, June 17, 2003, at 08:02  PM, Stas Bekman wrote:
Geoffrey Young wrote:
1. The documentation is pretty lacking.

As Geoff pointed out, this statement is incorrect. The document:
http://perl.apache.org/docs/general/testing/testing.html
should answer most of your questions.

It's incorrect in the sense that most of the modules aren't documented. 
That's absolutely true. I thought you were referring to the tutorial.
I was using that article and the one on perl.com, or I would have got 
nowhere. I'll likely submit some docs for TestRequest shortly.
Fantastic. May I suggest that modules should include only API docs, but all 
real usages go to the tutorial? modperl-docs/src/general/testing/testing.pod

 2. The tests are being run from t/, rather then from the root of the
 module distribution directory. IIRC, Perl itself runs all of its tests
 from t/, but all modules by default run them from the module
 distribution root. Can this be fixed/changed?
They aren't running from t/, unless you run them from there. t/TEST 
can run from t/ and from base.

No, I run `make test`. In my test scripts, which live in t/, when I want 
to parse the log, I have to open 'logs/error_log', not 
't/logs/error_log'. It runs out of t/.
What you try to say is that the ServerRoot is t/, not that t/TEST is invoked 
from t/. You can override that of course.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: resolving Apache::Test vs. Apache::test collision

2003-06-19 Thread Stas Bekman
David Wheeler wrote:
On Wednesday, June 18, 2003, at 07:30  AM, Stas Bekman wrote:
Now just awaiting a confirmation from David and I'll put Apache::Test 
1.03 on CPAN.

David, if you see this before tomorrow, simpy try the latest cvs, I 
have already committed the needed change. Hopefully it does do the 
right thing for you.

It does. Well done.
Thanks David, posting Apache::Test to CPAN.
Hopefully this post concludes this *very* long thread ;)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


[ANNOUNCE] Apache::Test 1.03

2003-06-19 Thread Stas Bekman
The uploaded file
Apache-Test-1.03.tar.gz
has entered CPAN as
  file: $CPAN/authors/id/S/ST/STAS/Apache-Test-1.03.tar.gz
  size: 80048 bytes
   md5: 8ed7fd0bb829bf7c16850aafd282ffbf
Changes since 1.01:
=item 1.03 - June 19, 2003
Instrumented Makefile.PL to unconditionally remove any old
pre-installed occurrences of Apache/test.pm, which has been renamed to
Apache/testold.pm in mod_perl 1.28 to avoid collisions with
Apache/Test.pm on case-insensitive systems. [Stas]
Apache::TestClient now handles correctly responses with no body and
its response header() method is no longer case-sensitive [Stas]
add skip helper shortcuts: have_min_perl_version,
have_min_module_version [Stas]
pass to 'use lib' only 'lib/' dirs that actually exist in
autogenerated t/TEST t/SMOKE and others. [Stas]
add the ASF LICENSE file to the distro [Stas]
get rid of Apache::TestTrace's dependency on Apache::TestConfig as it
creates too many circular use() problems. [Stas]
wrap blib loading in eval block (added to autogenerated files), to
prevent 'make clean' failures. [Stas]
add two more variants of each of the tracing functions. If the '_mark'
suffix is appended (e.g., 'error_mark') the trace will start with the
filename and the line number the function was called from. If the
'_sub' suffix is appended (e.g., 'error_info') the trace will start
with the name of the subroutine the function was called from. [Stas]
add support for a new env var APACHE_TEST_TRACE_LEVEL, used to
override the tracing level. It propogates the overriden (either by env
var APACHE_TEST_TRACE_LEVEL or -trace option) value to the
server-side, so we can use Apache::TestTrace in mod_perl handlers, and
be able enable/disable tracing from the commmand line. This way we
don't have to comment out debug prints. [Stas]
=item 1.02
not released
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev

2003-06-19 Thread Stas Bekman
Stas Bekman wrote:
I've uploaded 1.03's release candidate. If nobody finds any faults, I'll 
upload it tomorrow on CPAN. (libapreq needs to rely on 1.03 fixes to 
release its 1.2's version).

Please try it out:
http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz
Thank you all very much for testing this release candidate. Apache::Test 1.03 
is propogating to CPAN mirrors at this very moment.

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


[STATUS] (flood) Wed Jun 18 23:46:07 EDT 2003

2003-06-19 Thread Rodent of Unusual Size
flood STATUS:   -*-text-*-
Last modified at [$Date: 2002/09/06 10:24:42 $]

Release:

1.0:   Released July 23, 2002
milestone-03:  Tagged January 16, 2002
ASF-transfer:  Released July 17, 2001
milestone-02:  Tagged August 13, 2001
milestone-01:  Tagged July 11, 2001 (tag lost during transfer)

RELEASE SHOWSTOPPERS:

* Everything needs to work perfectly

Other bugs that need fixing:

* I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml
  config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001.
  
* iPlanet sends Content-length - there is a hack in there now
  to recognize it.  However, all HTTP headers need to be normalized
  before checking their values.  This isn't easy to do.  Grr.

* OpenSSL 0.9.6
  Segfaults under high load.  Upgrade to OpenSSL 0.9.6b.
   Aaron says: I just found a big bug that might have been causing
   this all along (we weren't closing ssl sockets).
   How can I reproduce the problem you were seeing
   to verify if this was the fix?

* SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable
  and at least bomb with a good error message. (See Doug's patch.)
   Status: This is fixed, no?

* If APR has disabled threads, flood should as well. We might want
  to have an enable/disable parameter that does this also, providing
  an error if threads are desired but not available.

* flood needs to clear pools more often. With a long running test
  it can chew up memory very quickly. We should just bite the bullet
  and create/destroy/clear pools for each level of our model:
  farm, farmer, profile, url/request-cycle, etc.

* APR needs to have a unified interface for ephemeral port
  exhaustion, but aparently Solaris and Linux return different
  errors at the moment. Fix this in APR then take advantage of
  it in flood.

* The examples/analyze-relative scripts fail when there are less
  than 5 unique URLs.

Other features that need writing:

* More analysis and graphing scripts are needed

* Write robust tool (using tethereal perhaps) to take network dumps 
  and convert them to flood's XML format.
Status: Justin volunteers.  Aaron had a script somewhere that is
a start.

* Get chunked encoding support working.
Status: Justin volunteers.  He got sidetracked by the httpd
implementation of input filtering and never finished 
this.  This is a stopgap until apr-serf is completed.

* Maybe we should make randfile and capath runtime directives that
  come out of the XML, instead of autoconf parameters.

* We are using apr_os_thread_current() and getpid() in some places
  when what we really want is a GUID. The GUID will be used to
  correlate raw output data with each farmer. We may wish to print
  a unique ID for each of farm, farmer, profile, and url to help in
  postprocessing.

* We are using strtol() in some places and strtoll() in others.
  Pick one (Aaron says strtol(), but he's not sure).

* Validation of responses (known C-L, specific strings in response)
   Status: Justin volunteers

* HTTP error codes (ie. teach it about 302s)
   Justin says: Yeah, this won't be with round_robin as implemented.  
Need a linked list-based profile where we can insert 
new URLs into the sequence.

* Farmer (Single-thread, multiple profiles)
   Status: Aaron says: If you have threads, then any Farmer can be
   run as part of any Farm. If you don't have threads, you can
   currently only run one Farmer named Joe right now (this will
   be changed so that if you don't have threads, flood will attempt
   to run all Farmers in serial under one process).

* Collective (Single-host, multiple farms)
  This is a number of Farms that have been fork()ed into child processes.

* Megaconglomerate (Multiple hosts each running a collective)
  This is a number of Collectives running on a number of hosts, invoked
  via RSH/SSH or maybe even some proprietary mechanism.

* Other types of urllists
a) Random / Random-weighted
b) Sequenced (useful with cookie propogation)
c) Round-robin
d) Chaining of the above strategies
  Status: Round-robin is complete.

* Other types of reports
  Status: Aaron says: simple reports are functional. Justin added
  a new type that simply prints the approx. timestamp when
  the test was run, and the result as OK/FAIL; it is called
  easy reports (see flood_easy_reports.h).
  Furthermore, simple_reports and easy_reports both print
  out the current requesting URI line.

Documentation that needs writing:

* Documentation?  

[STATUS] (perl-framework) Wed Jun 18 23:46:10 EDT 2003

2003-06-19 Thread Rodent of Unusual Size
httpd-test/perl-framework STATUS:   -*-text-*-
Last modified at [$Date: 2002/03/09 05:22:48 $]

Stuff to do:
* finish the t/TEST exit code issue (ORed with 0x2C if
  framework failed)

* change existing tests that frob the DocumentRoot (e.g.,
  t/modules/access.t) to *not* do that; instead, have
  Makefile.PL prepare appropriate subdirectory configs
  for them.  Why?  So t/TEST can be used to test a
  remote server.

* problems with -d perl mode, doesn't work as documented
  Message-ID: [EMAIL PROTECTED]
  Date: Sat, 20 Oct 2001 12:58:33 +0800
  Subject: Re: perldb

Tests to be written:

* t/apache
  - simulations of network failures (incomplete POST bodies,
chunked and unchunked; missing POST bodies; slooow
client connexions, such as taking 1 minute to send
1KiB; ...)

* t/modules/autoindex
  - something seems possibly broken with inheritance on 2.0

* t/ssl
  - SSLPassPhraseDialog exec:
  - SSLRandomSeed exec:


Re: Perl Testing

2003-06-19 Thread Geoffrey Young

No, I run `make test`. In my test scripts, which live in t/, when I 
want to parse the log, I have to open 'logs/error_log', not 
't/logs/error_log'. It runs out of t/.

What you try to say is that the ServerRoot is t/, not that t/TEST is 
invoked from t/. You can override that of course.

How?
I think he means by adding your own ServerRoot directive to 
extra.last.conf.in.  however, I see what you are saying and that won't 
likely resolve your issue.

is there some reason that you want to backtrack to t/ in your test scripts? 
 for the most part, I put things I need under t/, including libraries and 
other cruft, so that everything is relative to the default ServerRoot setting.

HTH
--Geoff


Apach::TestRequest Doc Patch

2003-06-19 Thread David Wheeler
Hi all,
Please find enclosed a documentation patch for Apache::TestRequest. It 
does a couple of other things, too, so here's a complete list:

* Attempts to document all of the important functions of 
Apache::TestRequest. Comments and corrections would be much 
appreciated. I especially need help with the keep_alive parameter to 
user_agent() and a description of what OPTIONS() does.

* Exports UPLOAD from Apache::TestRequest. Was this an oversight?
* Changes the way the redirect_ok parameter works so that it affects 
only that _that call_ to the function. Afterward it should revert to 
the old value of $RedirectOK. I use local() to do this.

* Changes user_agent() so that the LWP::UserAgent 
requests_redirectable parameter actually does something useful 
vis-à-vis $RedirectOK.

* Added SEE ALSO section to Apache::Test. Note that this section, and 
the same section of Apache::TestRequest, points to Apache::TestMM, 
which currently has no documentation.

Thanks,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED]  ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]


Apache-Test-Pod.patch
Description: Binary data


Apache/2.1.0-dev, mod_ssl and insufficient entry

2003-06-19 Thread J. W. Ballantine
I tried this question with users and was directed here.  If that is wrong,
please let me know.
Thanks




I'm trying to start Apache/2.1.0-dev with mod_ssl enabled and all
I keep getting is the dreaded:

[Wed Jun 18 15:31:59 2003] [warn] Init: PRNG still contains insufficient 
entropy!
[Wed Jun 18 15:31:59 2003] [error] Init: Failed to generate temporary 512 bit 
RSA private key
Configuration Failed

I understand that this is controlled by SSLRandomSeed in the httpd.conf file,
and I've tried the following pairs to generate enough entropy:

SSLRandomSeed startup exec:`/usr/local/add-on/egd/bin/egc.pl 
/etc/local/openssh/egd-pool`
SSLRandomSeed connect exec:`/usr/local/add-on/egd/bin/egc.pl 
/etc/local/openssh/egd-pool`

SSLRandomSeed startup egd:/etc/local/openssh/egd-pool
SSLRandomSeed connect egd:/etc/local/openssh/egd-pool

SSLRandomSeed startup file:/etc/local/openssh/httpd_ssl.seed
SSLRandomSeed connect file:/etc/local/openssh/httpd_ssl.seed


SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

where /etc/local/openssh/httpd_ssl.seed was created by:
 /usr/local/add-on/egd/bin/egc.pl /etc/local/openssh/egd-pool read 255
and /etc/local/openssh/egd-pool is the socket from egd.pl ( which works
fine with pnrgd for opensshd ).

Any thoughts/pointers will be greatly appreciated.

The cvs date is 20030612 and other info on httpd are:

Server version: Apache/2.1.0-dev
Server built:   Jun 12 2003 12:14:31
Server version: Apache/2.1.0-dev
Server built:   Jun 12 2003 12:14:31
Server's Module Magic Number: 20030213:1
Architecture:   32-bit
Server compiled with
 -D APACHE_MPM_DIR=server/mpm/prefork
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_PROC_PTHREAD_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT=/local/APACHE/Apache2
 -D SUEXEC_BIN=/local/APACHE/Apache2/bin/suexec
 -D DEFAULT_PIDLOG=logs/httpd.pid
 -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
 -D DEFAULT_LOCKFILE=logs/accept.lock
 -D DEFAULT_ERRORLOG=logs/error_log
 -D AP_TYPES_CONFIG_FILE=conf/mime.types
 -D SERVER_CONFIG_FILE=conf/httpd.conf
Compiled in modules:
  core.c
  mod_authn_file.c
  mod_authn_default.c
  mod_authz_host.c
  mod_authz_groupfile.c
  mod_authz_user.c
  mod_authz_default.c
  mod_auth_basic.c
  mod_include.c
  mod_log_config.c
  mod_env.c
  mod_setenvif.c
  mod_ssl.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_autoindex.c
  mod_asis.c
  mod_cgi.c
  mod_negotiation.c
  mod_dir.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_so.c



1.3.28

2003-06-19 Thread Jim Jagielski
OK, let's get 1.3.28 out the door. I'd like to hear some feedback
on whether there is stuff people want to see in this release.
I'd also like some feedback on some testing on the latest HEAD.
It is likely that 1.3.28 will be out there for quite awhile,
so let's get it out soon, but also get it out right.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson


RE: Apache/2.1.0-dev, mod_ssl and insufficient entry

2003-06-19 Thread Bennett, Tony - CNF
JW,

Do you really mean /usr/local/add-on/egd/bin/egd.pl 
^
-tony



-Original Message-
From: J. W. Ballantine [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 19, 2003 6:37 AM
To: [EMAIL PROTECTED]
Subject: Apache/2.1.0-dev, mod_ssl and insufficient entry 


I tried this question with users and was directed here.  If that is wrong,
please let me know. Thanks




I'm trying to start Apache/2.1.0-dev with mod_ssl enabled and all I keep
getting is the dreaded:

[Wed Jun 18 15:31:59 2003] [warn] Init: PRNG still contains insufficient 
entropy!
[Wed Jun 18 15:31:59 2003] [error] Init: Failed to generate temporary 512
bit 
RSA private key
Configuration Failed

I understand that this is controlled by SSLRandomSeed in the httpd.conf
file, and I've tried the following pairs to generate enough entropy:

SSLRandomSeed startup exec:`/usr/local/add-on/egd/bin/egc.pl 
/etc/local/openssh/egd-pool`
SSLRandomSeed connect exec:`/usr/local/add-on/egd/bin/egc.pl 
/etc/local/openssh/egd-pool`

SSLRandomSeed startup egd:/etc/local/openssh/egd-pool SSLRandomSeed connect
egd:/etc/local/openssh/egd-pool

SSLRandomSeed startup file:/etc/local/openssh/httpd_ssl.seed
SSLRandomSeed connect file:/etc/local/openssh/httpd_ssl.seed


SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

where /etc/local/openssh/httpd_ssl.seed was created by:
/usr/local/add-on/egd/bin/egc.pl /etc/local/openssh/egd-pool read 255 and
/etc/local/openssh/egd-pool is the socket from egd.pl ( which works fine
with pnrgd for opensshd ).

Any thoughts/pointers will be greatly appreciated.

The cvs date is 20030612 and other info on httpd are:

Server version: Apache/2.1.0-dev
Server built:   Jun 12 2003 12:14:31
Server version: Apache/2.1.0-dev
Server built:   Jun 12 2003 12:14:31
Server's Module Magic Number: 20030213:1
Architecture:   32-bit
Server compiled with
 -D APACHE_MPM_DIR=server/mpm/prefork
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_PROC_PTHREAD_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT=/local/APACHE/Apache2
 -D SUEXEC_BIN=/local/APACHE/Apache2/bin/suexec
 -D DEFAULT_PIDLOG=logs/httpd.pid
 -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
 -D DEFAULT_LOCKFILE=logs/accept.lock
 -D DEFAULT_ERRORLOG=logs/error_log
 -D AP_TYPES_CONFIG_FILE=conf/mime.types
 -D SERVER_CONFIG_FILE=conf/httpd.conf
Compiled in modules:
  core.c
  mod_authn_file.c
  mod_authn_default.c
  mod_authz_host.c
  mod_authz_groupfile.c
  mod_authz_user.c
  mod_authz_default.c
  mod_auth_basic.c
  mod_include.c
  mod_log_config.c
  mod_env.c
  mod_setenvif.c
  mod_ssl.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_autoindex.c
  mod_asis.c
  mod_cgi.c
  mod_negotiation.c
  mod_dir.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_so.c



Re: 1.3.28

2003-06-19 Thread Bill Stoddard
Jim Jagielski wrote:

OK, let's get 1.3.28 out the door. I'd like to hear some feedback
on whether there is stuff people want to see in this release.
I'd also like some feedback on some testing on the latest HEAD.
It is likely that 1.3.28 will be out there for quite awhile,
so let's get it out soon, but also get it out right.
 

Quick sniff test in Windows looks good.

Bill



Re: Apache/2.1.0-dev, mod_ssl and insufficient entry

2003-06-19 Thread J. W. Ballantine

Yes, that is the name of the perl script that reads from the pool for
seed generation.

--  In Response to your message -

  Date:  Thu, 19 Jun 2003 07:47:05 -0700
  To:  '[EMAIL PROTECTED]' [EMAIL PROTECTED]
  From:  Bennett, Tony - CNF [EMAIL PROTECTED]
  Subject:  RE: Apache/2.1.0-dev, mod_ssl and insufficient entry 

  JW,
  
  Do you really mean /usr/local/add-on/egd/bin/egd.pl 
  ^
  -tony
  
  
  
  -Original Message-
  From: J. W. Ballantine [mailto:[EMAIL PROTECTED] 
  Sent: Thursday, June 19, 2003 6:37 AM
  To: [EMAIL PROTECTED]
  Subject: Apache/2.1.0-dev, mod_ssl and insufficient entry 
  
  
  I tried this question with users and was directed here.  If that is wrong,
  please let me know. Thanks
  
  
  
  
  I'm trying to start Apache/2.1.0-dev with mod_ssl enabled and all I keep
  getting is the dreaded:
  
  [Wed Jun 18 15:31:59 2003] [warn] Init: PRNG still contains insufficient 
  entropy!
  [Wed Jun 18 15:31:59 2003] [error] Init: Failed to generate temporary 512
  bit 
  RSA private key
  Configuration Failed
  
  I understand that this is controlled by SSLRandomSeed in the httpd.conf
  file, and I've tried the following pairs to generate enough entropy:
  
  SSLRandomSeed startup exec:`/usr/local/add-on/egd/bin/egc.pl 
  /etc/local/openssh/egd-pool`
  SSLRandomSeed connect exec:`/usr/local/add-on/egd/bin/egc.pl 
  /etc/local/openssh/egd-pool`
  
  SSLRandomSeed startup egd:/etc/local/openssh/egd-pool SSLRandomSeed connect
  egd:/etc/local/openssh/egd-pool
  
  SSLRandomSeed startup file:/etc/local/openssh/httpd_ssl.seed
  SSLRandomSeed connect file:/etc/local/openssh/httpd_ssl.seed
  
  
  SSLRandomSeed startup builtin
  SSLRandomSeed connect builtin
  
  where /etc/local/openssh/httpd_ssl.seed was created by:
  /usr/local/add-on/egd/bin/egc.pl /etc/local/openssh/egd-pool read 255 and
  /etc/local/openssh/egd-pool is the socket from egd.pl ( which works fine
  with pnrgd for opensshd ).
  
  Any thoughts/pointers will be greatly appreciated.
  
  The cvs date is 20030612 and other info on httpd are:
  
  Server version: Apache/2.1.0-dev
  Server built:   Jun 12 2003 12:14:31
  Server version: Apache/2.1.0-dev
  Server built:   Jun 12 2003 12:14:31
  Server's Module Magic Number: 20030213:1
  Architecture:   32-bit
  Server compiled with
   -D APACHE_MPM_DIR=server/mpm/prefork
   -D APR_HAS_MMAP
   -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
   -D APR_USE_PROC_PTHREAD_SERIALIZE
   -D APR_USE_PTHREAD_SERIALIZE
   -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
   -D APR_HAS_OTHER_CHILD
   -D AP_HAVE_RELIABLE_PIPED_LOGS
   -D HTTPD_ROOT=/local/APACHE/Apache2
   -D SUEXEC_BIN=/local/APACHE/Apache2/bin/suexec
   -D DEFAULT_PIDLOG=logs/httpd.pid
   -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
   -D DEFAULT_LOCKFILE=logs/accept.lock
   -D DEFAULT_ERRORLOG=logs/error_log
   -D AP_TYPES_CONFIG_FILE=conf/mime.types
   -D SERVER_CONFIG_FILE=conf/httpd.conf
  Compiled in modules:
core.c
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
mod_include.c
mod_log_config.c
mod_env.c
mod_setenvif.c
mod_ssl.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_so.c
  




Re: 1.3.28

2003-06-19 Thread Jeff Trawick
Jim Jagielski wrote:
OK, let's get 1.3.28 out the door. I'd like to hear some feedback
on whether there is stuff people want to see in this release.
I'd also like some feedback on some testing on the latest HEAD.
It is likely that 1.3.28 will be out there for quite awhile,
so let's get it out soon, but also get it out right.
I did quite a bit of banging on HEAD of core code on AIX and Solaris 
when I tested some recent changes to http_main.c, but I'll bang some 
more today.



RE: Apache/2.1.0-dev, mod_ssl and insufficient entry

2003-06-19 Thread Bennett, Tony - CNF
So did changing it from egc.pl to egd.pl
solve your insufficient entropy error ???

-tony

-Original Message-
From: J. W. Ballantine [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 19, 2003 8:06 AM
To: [EMAIL PROTECTED]
Subject: Re: Apache/2.1.0-dev, mod_ssl and insufficient entry 



Yes, that is the name of the perl script that reads from the pool for seed
generation.

--  In Response to your message -

  Date:  Thu, 19 Jun 2003 07:47:05 -0700
  To:  '[EMAIL PROTECTED]' [EMAIL PROTECTED]
  From:  Bennett, Tony - CNF [EMAIL PROTECTED]
  Subject:  RE: Apache/2.1.0-dev, mod_ssl and insufficient entry

  JW,
  
  Do you really mean /usr/local/add-on/egd/bin/egd.pl   
 ^
  -tony
  
  
  
  -Original Message-
  From: J. W. Ballantine [mailto:[EMAIL PROTECTED]
  Sent: Thursday, June 19, 2003 6:37 AM
  To: [EMAIL PROTECTED]
  Subject: Apache/2.1.0-dev, mod_ssl and insufficient entry 
  
  
  I tried this question with users and was directed here.  If that is 
 wrong,  please let me know. Thanks
  
  
  
  
  I'm trying to start Apache/2.1.0-dev with mod_ssl enabled and all I 
 keep  getting is the dreaded:
  
  [Wed Jun 18 15:31:59 2003] [warn] Init: PRNG still contains 
 insufficient
  entropy!
  [Wed Jun 18 15:31:59 2003] [error] Init: Failed to generate temporary 512
  bit 
  RSA private key
  Configuration Failed
  
  I understand that this is controlled by SSLRandomSeed in the 
 httpd.conf  file, and I've tried the following pairs to generate 
 enough entropy:
  
  SSLRandomSeed startup exec:`/usr/local/add-on/egd/bin/egc.pl
  /etc/local/openssh/egd-pool`
  SSLRandomSeed connect exec:`/usr/local/add-on/egd/bin/egc.pl 
  /etc/local/openssh/egd-pool`
  
  SSLRandomSeed startup egd:/etc/local/openssh/egd-pool SSLRandomSeed 
 connect  egd:/etc/local/openssh/egd-pool
  
  SSLRandomSeed startup file:/etc/local/openssh/httpd_ssl.seed
  SSLRandomSeed connect file:/etc/local/openssh/httpd_ssl.seed
  
  
  SSLRandomSeed startup builtin
  SSLRandomSeed connect builtin
  
  where /etc/local/openssh/httpd_ssl.seed was created by:  
 /usr/local/add-on/egd/bin/egc.pl /etc/local/openssh/egd-pool read 255 
 and  /etc/local/openssh/egd-pool is the socket from egd.pl ( which 
 works fine  with pnrgd for opensshd ).
  
  Any thoughts/pointers will be greatly appreciated.
  
  The cvs date is 20030612 and other info on httpd are:
  
  Server version: Apache/2.1.0-dev
  Server built:   Jun 12 2003 12:14:31
  Server version: Apache/2.1.0-dev
  Server built:   Jun 12 2003 12:14:31
  Server's Module Magic Number: 20030213:1
  Architecture:   32-bit
  Server compiled with
   -D APACHE_MPM_DIR=server/mpm/prefork
   -D APR_HAS_MMAP
   -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
   -D APR_USE_PROC_PTHREAD_SERIALIZE
   -D APR_USE_PTHREAD_SERIALIZE
   -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
   -D APR_HAS_OTHER_CHILD
   -D AP_HAVE_RELIABLE_PIPED_LOGS
   -D HTTPD_ROOT=/local/APACHE/Apache2
   -D SUEXEC_BIN=/local/APACHE/Apache2/bin/suexec
   -D DEFAULT_PIDLOG=logs/httpd.pid
   -D DEFAULT_SCOREBOARD=logs/apache_runtime_status
   -D DEFAULT_LOCKFILE=logs/accept.lock
   -D DEFAULT_ERRORLOG=logs/error_log
   -D AP_TYPES_CONFIG_FILE=conf/mime.types
   -D SERVER_CONFIG_FILE=conf/httpd.conf
  Compiled in modules:
core.c
mod_authn_file.c
mod_authn_default.c
mod_authz_host.c
mod_authz_groupfile.c
mod_authz_user.c
mod_authz_default.c
mod_auth_basic.c
mod_include.c
mod_log_config.c
mod_env.c
mod_setenvif.c
mod_ssl.c
prefork.c
http_core.c
mod_mime.c
mod_status.c
mod_autoindex.c
mod_asis.c
mod_cgi.c
mod_negotiation.c
mod_dir.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_so.c
  



Re: 1.3.28

2003-06-19 Thread David McCreedy




It tests out OK on IBM's TPF system.

-David



   

  Brad Nicholes  

  [EMAIL PROTECTED]To:   [EMAIL PROTECTED], [EMAIL 
PROTECTED]   
  .comcc: 

   Subject:  Re: 1.3.28

  06/19/2003 09:24 

  AM   

  Please respond to

  dev  

   

   





A quick build and run on NetWare looks good.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

 [EMAIL PROTECTED] Thursday, June 19, 2003 9:14:54 AM 
Jim Jagielski wrote:
 OK, let's get 1.3.28 out the door. I'd like to hear some feedback
 on whether there is stuff people want to see in this release.
 I'd also like some feedback on some testing on the latest HEAD.
 It is likely that 1.3.28 will be out there for quite awhile,
 so let's get it out soon, but also get it out right.

I did quite a bit of banging on HEAD of core code on AIX and Solaris
when I tested some recent changes to http_main.c, but I'll bang some
more today.






Re: 1.3.28

2003-06-19 Thread André Malo
* Jim Jagielski wrote:

 OK, let's get 1.3.28 out the door. I'd like to hear some feedback
 on whether there is stuff people want to see in this release.
 I'd also like some feedback on some testing on the latest HEAD.
 It is likely that 1.3.28 will be out there for quite awhile,
 so let's get it out soon, but also get it out right.

/me points silently to the 2.0 STATUS file where the LimitInternalRecursion
thing resides :-)

nd
-- 
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join   #
 [ $japh =~ /{(.)}/] - [0] = map $_ - ()  #André Malo #
= @japh;# http://www.perlig.de/ #


Re: 1.3.28

2003-06-19 Thread Glenn
* Jim Jagielski wrote:
 OK, let's get 1.3.28 out the door. I'd like to hear some feedback
 on whether there is stuff people want to see in this release.

meekly
I have been waiting patiently for some comments on my patches to
server-side includes (first posted over a month ago and reposted
earlier this week)
/meekly

Would you accept some patches for changing httpd.conf-dist?
(the default config for _new_ installations)
Things such as:

  CGICommandArgs off

  Directory /
Options FollowSymLinks
AllowOverride None
## (protect filesystem unless explicitly allowed elsewhere)
order allow,deny
deny from all
  /Directory

Thanks.
Glenn


Re: [PATCH] mod_dav streamy error handling

2003-06-19 Thread Ben Collins-Sussman

gstein (and others), here is another micro-patch for the original
mod_dav.c 1.94 change we made a couple of weeks ago.  David Waite
noticed a segfault and made this patch.  Please apply ASAP!

The old code never hit this problem, because it would always send NULL
as the last argument to dav_send_multistatus(), *unless* a 404 href
response came back from the provider, in which case it sent
doc-namespaces.  But in that situation, that means doc *had* to be
non-NULL; a 404 href can only happen when PROPFIND has a body asking
for specific things.


--- mod_dav.c   3 Jun 2003 22:09:24 -   1.94
+++ mod_dav.c   19 Jun 2003 20:07:41 -
@@ -2051,3 +2051,3 @@
 badprops. */
-dav_begin_multistatus(ctx.bb, r, HTTP_MULTI_STATUS, doc-namespaces);
+dav_begin_multistatus(ctx.bb, r, HTTP_MULTI_STATUS, doc ? doc-namespaces : NULL);




2.0.46 shuts down after 5 min

2003-06-19 Thread Aviv Eliezer
Title: Message



Sorry for posting 
this here, posted it in the user list, and got no response..

I've got a clean 
vanilla install of apache 2.0.46, that for some unknown reason shuts down after 
~5 minutes.
It's a simple 
installation (only ./configure --prefix=/usr/local/apache2 
--enable-so).
The only 
non-standard thing is that this apache instance runs on port 81 (its a test 
server)-
since there's 
another instance of apache (production) running on 80 (the apache on port 80 is 
2.0.44).

I've tried to run 
the test apache on other ports (not only 81), still, I keep 
getting
"[notice] caught 
SIGTERM, shutting down" in the error log after ~5 minutes.

Is that a known 
problem or so?

Thanks.


Re: [PATCH] mod_dav streamy error handling

2003-06-19 Thread Greg Stein
Applied. Thanks!

On Thu, Jun 19, 2003 at 03:17:17PM -0500, Ben Collins-Sussman wrote:
 
 gstein (and others), here is another micro-patch for the original
 mod_dav.c 1.94 change we made a couple of weeks ago.  David Waite
 noticed a segfault and made this patch.  Please apply ASAP!
 
 The old code never hit this problem, because it would always send NULL
 as the last argument to dav_send_multistatus(), *unless* a 404 href
 response came back from the provider, in which case it sent
 doc-namespaces.  But in that situation, that means doc *had* to be
 non-NULL; a 404 href can only happen when PROPFIND has a body asking
 for specific things.
 
 
 --- mod_dav.c   3 Jun 2003 22:09:24 -   1.94
 +++ mod_dav.c   19 Jun 2003 20:07:41 -
 @@ -2051,3 +2051,3 @@
  badprops. */
 -dav_begin_multistatus(ctx.bb, r, HTTP_MULTI_STATUS, doc-namespaces);
 +dav_begin_multistatus(ctx.bb, r, HTTP_MULTI_STATUS, doc ? doc-namespaces : 
 NULL);

-- 
Greg Stein, http://www.lyra.org/


Re: [PATCH] mod_dav streamy error handling

2003-06-19 Thread Greg Stein
Applied. Thanks!

On Wed, Jun 18, 2003 at 02:52:48PM -0500, Ben Collins-Sussman wrote:
 
 [Reposting patch, with gstein's added check for r-sent_bodyct.]
 
 Have mod_dav deal with errors that happen during a streamy provider response.
 
 * mod_dav.c (dav_method_propfind, dav_method_report): if the dav
   provider throws an error in the middle of streaming a response, have
   mod_dav log an error and abort the connection.
...

-- 
Greg Stein, http://www.lyra.org/


Re: [PATCH] mod_dav streamy error handling

2003-06-19 Thread Ben Collins-Sussman

OK, so now all the mod_dav 'streamy propfind' patches are in.  My two
original concerns are addressed:  no more segfault, no more unlogged
errors.  I think jerenkrantz should be happy.  gstein and striker as
well.

That said, it'd be swell if we can get revisions 1.94, 1.95, 1.96 of
mod_dav.c backported to httpd-2.0.  I hear a rumor that sander is
itchin' to release 2.0.47 sometime soon, and Subversion really needs
this mod_dav feature.

Backport anyone?


Cleaning up the bucket allocator in the MPM...

2003-06-19 Thread Brad Nicholes
   After taking a look at how the different MPMs are implemented, it
appears that almost all of the MPMs create a bucket allocator and a
transaction pool for each worker thread or process.  The transaction
pool is cleared after each request but the bucket allocator is not
cleared or cleaned up until the worker thread or process goes away.  Is
there a reason why the bucket allocator is never cleaned up?

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 


RE: [PATCH] mod_dav streamy error handling

2003-06-19 Thread Sander Striker
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Thursday, June 19, 2003 11:37 PM

 OK, so now all the mod_dav 'streamy propfind' patches are in.  My two
 original concerns are addressed:  no more segfault, no more unlogged
 errors.  I think jerenkrantz should be happy.  gstein and striker as
 well.

I am happy.  Very.

 That said, it'd be swell if we can get revisions 1.94, 1.95, 1.96 of
 mod_dav.c backported to httpd-2.0.  I hear a rumor that sander is
 itchin' to release 2.0.47 sometime soon,

Well, itchin' is a bit of a stretch.  I would want to see if we can get
the periods between releases a bit shorter than last time.

 and Subversion really needs this mod_dav feature.

/me grins

That alone is not a good enough reason :)
 
 Backport anyone?

Yes.  I'll update STATUS.


Sander


Re: Release from the 2.1-dev branch?

2003-06-19 Thread Günter Knauf
Hi,
you suggested this already more than a month ago, but nothing happened then...
I would also like to see such an alpha-release...
Guenter.

 Is anyone interested in seeing a release from the dev branch? I suspect
 there are some users out there who would like to get their hands dirty,
 and would be happy to give us their feedback.

 -aaron




Re: Release from the 2.1-dev branch?

2003-06-19 Thread Justin Erenkrantz
--On Friday, June 20, 2003 2:11 AM +0200 Günter Knauf [EMAIL PROTECTED] wrote:

you suggested this already more than a month ago, but nothing happened
then... I would also like to see such an alpha-release...
Once mod_ssl works again, I'd support doing a 2.1 release.

I think that'll require me subscribing to openssl-dev and trying to sort out 
exactly what needs to happen with those callbacks and locks.  That's something 
that may take a little bit for me to do - unless someone is willing to speak 
up on openssl-dev and figuring out what we *should* be doing.  -- justin


Survey

2003-06-19 Thread Survey
[EMAIL PROTECTED]

Subject: Your perceptions of online gambling


Dear Sir / Madam,

I am a 23 year old Dutch international business student and currently writing my 
master thesis. This thesis involves a study into the determinants of the intention to 
gamble on the internet. Completion of the study requires feedback on current 
perceptions of online gambling among internet users. Therefore I would like to ask you 
to fill in the online survey at this address:

www.ringtechnologies.com

Answering the questions will take approximately four minutes of Your time. 

Your input would be very helpful.

With kind regards,


Jeroen van der Most 

Participating is completely anonymous and all information will be handled with strict 
confidentiality.

In case You have never gambled before in Your life, neither via the internet nor in 
traditional ways, Your input will not be useful and You are asked to ignore the 
request above.  



Re: Cleaning up the bucket allocator in the MPM...

2003-06-19 Thread Cliff Woolley
On Thu, 19 Jun 2003, Brad Nicholes wrote:

After taking a look at how the different MPMs are implemented, it
 appears that almost all of the MPMs create a bucket allocator and a
 transaction pool for each worker thread or process.  The transaction
 pool is cleared after each request but the bucket allocator is not
 cleared or cleaned up until the worker thread or process goes away.  Is
 there a reason why the bucket allocator is never cleaned up?

Yes.  Allocating memory for the bucket allocator takes time.  The goal
here is that we should reach after just a connection or two a steady-state
of memory usage, with additional allocations (via malloc() I mean) being
very infrequent.

That said, there is a problem: the bucket_max_free() stuff /still/ isn't
committed.  Why not?  Because I keep forgetting about it.  I'm sure
Jean-Jacques would cheer if I'd get around to it.  :)  It's on my schedule
for the weekend.

Once that's done, then the fact that the same bucket allocator is used
will continue to be the benefit that it is without causing the potential
problems of potential memory growth over time to which I believe you're
alluding.

Sound about right?

--Cliff