Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
@
if (my $custom_config_path = custom_config_path()) {
debug loading custom config data from: '$custom_config_path';
$custom_config_loaded++;
+($candidate) = $candidate=~/^(.*)/; # launder for -T
require $custom_config_path;
huh?
something is definitely wrong here - there is no $candidate in the scope of
the current function, so this actually fails with errors.
$ perl Makefile.PL -apxs /apache/2.0/prefork/perl-5.8.5/bin/apxs
Global symbol $candidate requires explicit package name at
lib/Apache/TestConfig.pm line 2080.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote: geoff 2004/10/28 07:33:56 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: revert last change to keep things compiling sorry stas if you would have gotten to this quickly, but I thought it was a good idea to keep things in cvs compiling and gozer said you would be offline for a few days due to a crazy landlord or something :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Geoffrey Young wrote: [EMAIL PROTECTED] wrote: geoff 2004/10/28 07:33:56 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: revert last change to keep things compiling sorry stas if you would have gotten to this quickly, but I thought it was a good idea to keep things in cvs compiling and gozer said you would be offline for a few days due to a crazy landlord or something :) That's exactly right. you did the right thing. I'm still relying on a anonymous friendly neighbour somewhere on the same block to get my oxygen. One day we will be able to get online in a matter of seconds... -- __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote: gozer 2004/09/16 14:36:13 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: Added an apxs query cache for improved test performance It doesn't seem to make any difference for me. I'm not sure why it made such a significant difference on your machine. Perhaps your apxs util is for some reason is too slow. % time perl -le 'qx[~/httpd/prefork/bin/apxs -q CFLAGS] for 1..30' 3.411u 1.786s 0:05.35 97.0% 0+0k 0+0io 0pf+0w -- __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm
[EMAIL PROTECTED] wrote: stas2004/08/06 11:20:42 Modified:perl-framework/Apache-Test Changes Makefile.PL perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm Log: move the custom config code into Apache::TestConfig, split the config object creation in 2 parts - first not requiring the knowledge of httpd location, the second requiring one, refactor the custom config interactive prompting into the second phase, if failed to find httpd. Reshuffle the code to run first bits not requiring the knowledge of httpd location. I had to do some re-shuffling to change the timing of the httpd detection, as a few things were broken. I hope I didn't break anything. Please do extensive testing. Thanks. (I wish there was a test suite for Apache-Test itself, not the internal tests, but the configuration tests) -- __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm
And may be this is a good idea for the A-T skeleton as well :) indeed :) actually, the bug reporting skeleton used t/My/Handler.pm, and I'll certainly change that to t/lib not. the A-T module skeleton actually starts with no supporting modules, since you would want to install the module you're testing. but maybe I'll come up with something anyway :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm
On Jul 14, 2004, at 5:01 PM, [EMAIL PROTECTED] wrote: +If a directory t/lib exists from where the tests are run, adjust [EMAIL PROTECTED] so that this directory is added when running the tests, +both within t/TEST and within t/conf/modperl_inc.pl. +This allows inclusion of modules specific to the tests that +aren't intended to be installed. [Stas, Randy] Oh, nice! Now maybe I'll be able to get rid of this in my t/conf/extra.conf.in: Perl use File::Spec::Functions qw(catdir); use lib catdir '@ServerRoot@', 'lib'; use lib catdir '@ServerRoot@', '..', 'blib'; use lib catdir '@ServerRoot@', '..', 'lib'; /Perl Yes? Regards, David
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm
Geoffrey Young wrote: And may be this is a good idea for the A-T skeleton as well :) indeed :) actually, the bug reporting skeleton used t/My/Handler.pm, and I'll certainly change that to t/lib not. ECANTPARSETHAT the A-T module skeleton actually starts with no supporting modules, since you would want to install the module you're testing. but maybe I'll come up with something anyway :) :) -- __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
Geoffrey Young wrote: [EMAIL PROTECTED] wrote: coar2004/04/01 15:57:17 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm Log: add an '-httpd_conf_extra filename' option to allow an *additional* server config file to be inherited as well as the server's main one (or one specified with -httpd_conf). ok, I guess you guys figured out how to do it :) Looks like Ken's hair started to grow again, after he had it all lost over this case :) anyway, if I can interject a few comments on the idea... we already have a few files that get magical treatment: extra.conf.in, extra.last.conf.in, modperl_startup.pl, etc. I think the way I would do it (from afar :) is to create yet another special case, maybe httpd.extra.conf.in or somesuch. advantages would be that it would follow the approach we've been using, it wouldn't require an extra runtime argument, and it could benefit from variable subsitution like all the other conf files. That probably won't suite Ken's particular need. What Ken was after is to be able to throw random .so modules into some directory and tell Apache::Test to detect them, load them and have have_module() see them. and Ken really wants to have lots of these directories and point every time to a different one. So all he does now is generating a simple extra.conf which only lists LoadModule directives with the correct path to those modules, A-T picks them up and doesn't require c-modules any longer (Ken wants to pre-build c-modules for many architectures and many apache versions). I like this Ken's new option because it'll suite cases where a user can't modify the global httpd.conf, but will be able to add its own global httpd.conf extra's via this option. We have also discussed to make it accept more than one file, but at the moment it's not possible and will require quite a few changes (currently config is a hash and it's set in more than one place). doable, but we probably shouldn't touch it until someone will really need it. While we discussed possible solutions, I suggested an idea to figure out whether we have a compiler at all, and if not skip even trying to build c-modules. So if you build things on machine A with a compiler and then tar things up and move it to machine B w/o a compiler (same architecture), the modules will be already precompiled and ready to use and t/TEST -clean won't nuke them. Ken said that this idea didn't suite him, but I think it could be useful to others. The kludge is how to figure out whether things will be able to compile or not (whether there is a compiler at all). __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
right, I think I got that. but that requires knowing the hard-coded path. That's what Ken wanted ok, but just because you get substitution doesn't mean you have to use it :) perhaps I wasn't clear enough, but the proposed httpd.extra.conf.in would be appended to the generated httpd.conf rather than pulled in via Include. would that not suit the needs that the current patch resolves? Please see below would there really be a need to pull in more than one config into the main httpd.conf that couldn't be met via Include? No, have_module() won't see those modules. It must be parsed via inheriting scheme or come up with a new way. the new option seems to be the simplest solution. I don't see your point here. once you splice together the current httpd.conf with the new file (however it's generated) have_module would have access to the information it needs. Ken doesn't want it to be inside t/conf/, since he will have it elsewhere. He doesn't want to touch the A-T project's file. That's what I understood. ok, that's a valid reason. anyway I was just making a suggestion - it seems limiting to me not to have substitution in extra configuration files, or to be able to specify one kind of config file from the command line but not others. but it's not like I have the tuits to do anything about it now anyway, so I guess it stays as is :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
By splicing you mean 'Include ken_extra.conf' from t/conf/httpd.conf?
Yes, but have_module() doesn't look it up in any of the conf files, it
looks it up from the config object $cfg-{modules} which get populate
with available modules when the config is generated, and it only scans
the inherited file, it doesn't scan any of the files in t/conf.
no, what I meant was that ken_extra.conf (httpd.extra.conf.in -
httpd.extra.conf) would get appended to the currently generated httpd.conf,
then _that_ result is what is scanned. but maybe it's not as simple to
change the internal logic to accomodate that.
anyway I was just making a suggestion - it seems limiting to me not to
have
substitution in extra configuration files,
But that's exactly what Ken doesn't want. He wants to give his own file
which he has cooked already. This new option and your suggestion don't
contradict each other. and each has a merit for existence.
I still don't see how the idea I'm proposing isn't sufficient, save that it
would need to live within t/conf. that we could make it support variable
substitution doesn't mean that it can't be 100% hard-coded.
or to be able to specify one kind
of config file from the command line but not others. but it's not like I
have the tuits to do anything about it now anyway, so I guess it stays
as is :)
:)
:)
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Something is not right here, Geoff. It require()s *only* if IS_MOD_PERL_2 is true. Which must have Apache::Build present. I suggest that you try to revert it and find the real cause of the problem, rather than hide it. Thanks. ah, I see what's going on. I removed all Apache stuff but mod_perl.pm lingers. blarg. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote:
geoff 2004/04/01 06:32:03
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
Log:
trap require Apache::Build errors - not everyone has mod_perl 2.0 installed
Revision ChangesPath
1.215 +1 -1 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm
Index: TestConfig.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.214
retrieving revision 1.215
diff -u -r1.214 -r1.215
--- TestConfig.pm 31 Mar 2004 22:44:32 - 1.214
+++ TestConfig.pm 1 Apr 2004 14:32:03 - 1.215
@@ -29,7 +29,7 @@
eval { require mod_perl $mod_perl::VERSION = 1.99 } || 0;
use constant IS_MOD_PERL_2_BUILD = IS_MOD_PERL_2
-require Apache::Build Apache::Build::IS_MOD_PERL_BUILD();
+eval { require Apache::Build Apache::Build::IS_MOD_PERL_BUILD() } || 0;
Something is not right here, Geoff. It require()s *only* if IS_MOD_PERL_2 is
true. Which must have Apache::Build present. I suggest that you try to revert
it and find the real cause of the problem, rather than hide it. Thanks.
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
+(my $generated = $File::Find::name) =~ s/\.in$//;
+push @need_update, $generated
+unless -e $generated -M $generated -M $File::Find::name;
-if (my $extra_conf = $self-generate_extra_conf) {
-for my $file (@$extra_conf) {
-push @reasons, $file.in is newer than $file
-if -e $file -M $file.in -M $file;
-}
you flipped the logic here. it needs to be
unless -e $generated -M $generated -M $File::Find::name
which is equivalent to
if (! -e extra.conf || ! (extra.conf extra.conf.in))
right now it reconfigures all the time:
[warning] forcing re-configuration:
[warning] - t/conf/extra.conf.in is newer than t/conf/extra.conf.
-rw-rw-r--1 geoffgeoff1283 Feb 19 09:42 extra.conf
-rw-rw-r--1 geoffgeoff 353 Feb 19 09:36 extra.conf.in
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Geoffrey Young wrote:
+(my $generated = $File::Find::name) =~ s/\.in$//;
+push @need_update, $generated
+unless -e $generated -M $generated -M $File::Find::name;
-if (my $extra_conf = $self-generate_extra_conf) {
-for my $file (@$extra_conf) {
-push @reasons, $file.in is newer than $file
-if -e $file -M $file.in -M $file;
-}
you flipped the logic here. it needs to be
unless -e $generated -M $generated -M $File::Find::name
I don't think so. The two snippets you quoted above aren't the same. I've
changed the functionality and changed the order of the arguments. The code:
push @need_update, $generated
unless -e $generated -M $generated -M $File::Find::name;
says: a generated file needs to be updated, unless it already exists and it's
younger than its source file.
In other words, update the file if it doesn't exist or if it's older then the
source file:
push @need_update, $generated
if (!-e $generated || -M $generated -M $File::Find::name);
Am I wrong?
which is equivalent to
if (! -e extra.conf || ! (extra.conf extra.conf.in))
right now it reconfigures all the time:
[warning] forcing re-configuration:
[warning] - t/conf/extra.conf.in is newer than t/conf/extra.conf.
-rw-rw-r--1 geoffgeoff1283 Feb 19 09:42 extra.conf
-rw-rw-r--1 geoffgeoff 353 Feb 19 09:36 extra.conf.in
I bet you see that problem when you do a full reconfigure, no? So, yes, there
is a buglet in the comments, not the actual config process. Will fix that shortly.
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
you flipped the logic here. it needs to be unless -e $generated -M $generated -M $File::Find::name I don't think so. The two snippets you quoted above aren't the same. I've changed the functionality and changed the order of the arguments. ok, I see now. when I ran my own logic tests I flipped the files myself. confusing stuff :) right now it reconfigures all the time: [warning] forcing re-configuration: [warning] - t/conf/extra.conf.in is newer than t/conf/extra.conf. -rw-rw-r--1 geoffgeoff1283 Feb 19 09:42 extra.conf -rw-rw-r--1 geoffgeoff 353 Feb 19 09:36 extra.conf.in I bet you see that problem when you do a full reconfigure, no? So, yes, there is a buglet in the comments, not the actual config process. Will fix that shortly. yes, you're right, it was the comments - extra.conf wasn't being regenerated every time, it was just the warning that was showing up. anyway, sorry for not paying more attention. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Geoffrey Young wrote: you flipped the logic here. it needs to be unless -e $generated -M $generated -M $File::Find::name I don't think so. The two snippets you quoted above aren't the same. I've changed the functionality and changed the order of the arguments. ok, I see now. when I ran my own logic tests I flipped the files myself. confusing stuff :) Yes, -M is always confusing, since it reports the time since the last change. right now it reconfigures all the time: [warning] forcing re-configuration: [warning] - t/conf/extra.conf.in is newer than t/conf/extra.conf. -rw-rw-r--1 geoffgeoff1283 Feb 19 09:42 extra.conf -rw-rw-r--1 geoffgeoff 353 Feb 19 09:36 extra.conf.in I bet you see that problem when you do a full reconfigure, no? So, yes, there is a buglet in the comments, not the actual config process. Will fix that shortly. yes, you're right, it was the comments - extra.conf wasn't being regenerated every time, it was just the warning that was showing up. anyway, sorry for not paying more attention. No, no, your observation was good, as I indeed introduced a misleading commentary. I think it's all fixed now. __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
my Apache is D:\Apache2\bin\Apache.exe, which would
get reported as d:\apache2\bin\apache.exe. If there isn't
an easy way to preserve the case yet still remove such
duplicates, I'll do that - it's not a big deal.
Randy, you are the expert on win32 ;) I have no idea what
method to use to get a consistent case on case-insenstive
file systems. Really I think it's time to extend
File::Spec to handle that and not solve this problem every
time we need to read a filename.
This is an annoyance, for sure ... However, in a sense we
(Apache-Test) have some control over this problem. In
another section we're looking for 'Apache', and then in
TestRun.pm we also look for 'apache'. So both get reported
as being present. However, on Win32, looking for 'apache' is
somewhat misleading, as the default installation (either
binary or source) results in 'Apache'. What about the
following:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.138
diff -u -r1.138 TestRun.pm
--- lib/Apache/TestRun.pm 11 Jan 2004 15:25:12 - 1.138
+++ lib/Apache/TestRun.pm 13 Jan 2004 14:36:41 -
@@ -1343,11 +1343,13 @@
{
my %choices = ();
+my @tries = Apache::TestConfig::WIN32 ?
+qw(Apache httpd Apache2 httpd2) :
+qw(apache httpd apache2 httpd2);
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, $ENV{APACHE2}, map {which($_)} @tries) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
--
best regards,
randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
Randy Kobes wrote:
On Sun, 11 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
my Apache is D:\Apache2\bin\Apache.exe, which would
get reported as d:\apache2\bin\apache.exe. If there isn't
an easy way to preserve the case yet still remove such
duplicates, I'll do that - it's not a big deal.
Randy, you are the expert on win32 ;) I have no idea what
method to use to get a consistent case on case-insenstive
file systems. Really I think it's time to extend
File::Spec to handle that and not solve this problem every
time we need to read a filename.
This is an annoyance, for sure ... However, in a sense we
(Apache-Test) have some control over this problem. In
another section we're looking for 'Apache', and then in
TestRun.pm we also look for 'apache'. So both get reported
as being present. However, on Win32, looking for 'apache' is
somewhat misleading, as the default installation (either
binary or source) results in 'Apache'. What about the
following:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.138
diff -u -r1.138 TestRun.pm
--- lib/Apache/TestRun.pm 11 Jan 2004 15:25:12 - 1.138
+++ lib/Apache/TestRun.pm 13 Jan 2004 14:36:41 -
@@ -1343,11 +1343,13 @@
{
my %choices = ();
+my @tries = Apache::TestConfig::WIN32 ?
+qw(Apache httpd Apache2 httpd2) :
+qw(apache httpd apache2 httpd2);
better less dups, and comments are helpful too ;)
my @tries = qw(httpd httpd2);
# win32 has Apache and Apache2 and not apache and apache2
push @tries, WIN32 ? qw(Apache Apache2) : qw(apache apache2);
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, $ENV{APACHE2}, map {which($_)} @tries) {
$choices{$_}++ if -e $_ -x _;
otherwise +1
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
[EMAIL PROTECTED] wrote:
randyk 2004/01/10 14:07:17
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestRun.pm
Log:
On Win32, multiple options for Apache.exe can be returned which differ
only by the case of the .exe extension or by the directory separator.
These changes bring things into line with what is returned from which().
[...]
1.136 +2 -2 httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- TestRun.pm 8 Jan 2004 04:54:06 - 1.135
+++ TestRun.pm 10 Jan 2004 22:07:17 - 1.136
@@ -1346,8 +1346,8 @@
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('Apache'), which('httpd'),
+ $ENV{APACHE2}, which('Apache2'), which('httpd2')) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
yes, but we need which('apache') too for unix. so please:
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('apache'), which('Apache'),
which('httpd'),
+ $ENV{APACHE2}, which('apache2'), which('Apache2'),
which('httpd2')) {
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sat, 10 Jan 2004, Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
randyk 2004/01/10 14:07:17
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestRun.pm
Log:
On Win32, multiple options for Apache.exe can be returned which differ
only by the case of the .exe extension or by the directory separator.
These changes bring things into line with what is returned from which().
[...]
1.136 +2 -2
httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- TestRun.pm8 Jan 2004 04:54:06 - 1.135
+++ TestRun.pm10 Jan 2004 22:07:17 - 1.136
@@ -1346,8 +1346,8 @@
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir
bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('Apache'), which('httpd'),
+ $ENV{APACHE2}, which('Apache2'), which('httpd2')) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
yes, but we need which('apache') too for unix. so please:
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('apache'), which('Apache'),
which('httpd'),
+ $ENV{APACHE2}, which('apache2'), which('Apache2'),
which('httpd2')) {
Sorry about that - I'll revert that change (I just tried,
but got an error message about insufficient space left on a
device). Actually, looking for both 'apache' and 'Apache'
leads back to the same problem on Win32 that, when the list
of Apache binaries is reported, both 'apache' and 'Apache'
are listed (with the same paths), so a different approach is
needed.
--
best regards,
randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
Randy Kobes wrote:
On Sat, 10 Jan 2004, Stas Bekman wrote:
[EMAIL PROTECTED] wrote:
randyk 2004/01/10 14:07:17
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestRun.pm
Log:
On Win32, multiple options for Apache.exe can be returned which differ
only by the case of the .exe extension or by the directory separator.
These changes bring things into line with what is returned from which().
[...]
1.136 +2 -2
httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.135
retrieving revision 1.136
diff -u -r1.135 -r1.136
--- TestRun.pm 8 Jan 2004 04:54:06 - 1.135
+++ TestRun.pm 10 Jan 2004 22:07:17 - 1.136
@@ -1346,8 +1346,8 @@
for (grep defined $_,
map({ catfile $vars-{$_}, $vars-{target} } qw(sbindir bindir)),
$test_config-default_httpd, which($vars-{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('Apache'), which('httpd'),
+ $ENV{APACHE2}, which('Apache2'), which('httpd2')) {
$choices{$_}++ if -e $_ -x _;
}
my $optional = 0;
yes, but we need which('apache') too for unix. so please:
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, which('apache'), which('Apache'),
which('httpd'),
+ $ENV{APACHE2}, which('apache2'), which('Apache2'),
which('httpd2')) {
Sorry about that - I'll revert that change (I just tried,
but got an error message about insufficient space left on a
device). Actually, looking for both 'apache' and 'Apache'
leads back to the same problem on Win32 that, when the list
of Apache binaries is reported, both 'apache' and 'Apache'
are listed (with the same paths), so a different approach is
needed.
So check that the path and lowercased filename match and exclude those on
win32?
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ .. ] Sorry about that - I'll revert that change (I just tried, but got an error message about insufficient space left on a device). Actually, looking for both 'apache' and 'Apache' leads back to the same problem on Win32 that, when the list of Apache binaries is reported, both 'apache' and 'Apache' are listed (with the same paths), so a different approach is needed. So check that the path and lowercased filename match and exclude those on win32? Yes, that would work, but it looks a bit funny - for example, my Apache is D:\Apache2\bin\Apache.exe, which would get reported as d:\apache2\bin\apache.exe. If there isn't an easy way to preserve the case yet still remove such duplicates, I'll do that - it's not a big deal. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
Randy Kobes wrote: On Sun, 11 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ .. ] Sorry about that - I'll revert that change (I just tried, but got an error message about insufficient space left on a device). Actually, looking for both 'apache' and 'Apache' leads back to the same problem on Win32 that, when the list of Apache binaries is reported, both 'apache' and 'Apache' are listed (with the same paths), so a different approach is needed. So check that the path and lowercased filename match and exclude those on win32? Yes, that would work, but it looks a bit funny - for example, my Apache is D:\Apache2\bin\Apache.exe, which would get reported as d:\apache2\bin\apache.exe. If there isn't an easy way to preserve the case yet still remove such duplicates, I'll do that - it's not a big deal. Randy, you are the expert on win32 ;) I have no idea what method to use to get a consistent case on case-insenstive file systems. Really I think it's time to extend File::Spec to handle that and not solve this problem every time we need to read a filename. __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On 12/01/2004, at 8:56 AM, Stas Bekman wrote: Randy Kobes wrote: On Sun, 11 Jan 2004, Stas Bekman wrote: Randy Kobes wrote: [ .. ] Sorry about that - I'll revert that change (I just tried, but got an error message about insufficient space left on a device). Actually, looking for both 'apache' and 'Apache' leads back to the same problem on Win32 that, when the list of Apache binaries is reported, both 'apache' and 'Apache' are listed (with the same paths), so a different approach is needed. So check that the path and lowercased filename match and exclude those on win32? Yes, that would work, but it looks a bit funny - for example, my Apache is D:\Apache2\bin\Apache.exe, which would get reported as d:\apache2\bin\apache.exe. If there isn't an easy way to preserve the case yet still remove such duplicates, I'll do that - it's not a big deal. Randy, you are the expert on win32 ;) I have no idea what method to use to get a consistent case on case-insenstive file systems. Really I think it's time to extend File::Spec to handle that and not solve this problem every time we need to read a filename. Likely to be a problem on (at least some versions of) Darwin as well, isn't it? Which probably means that you *really* don't want to be handling it all every time you come across it... Cheers, Nick
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote:
stas2003/10/21 15:09:11
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
Log:
complete the removal of hardcoding project/lib (besides the autogenerated
t/TEST and other scripts where mp2 build must have it in @INC)
[snip]
+# mp2 needs its modper-2.0/lib before blib was created
+if (IS_MOD_PERL_2_BUILD || $ENV{APACHE_TEST_LIVE_DEV}) {
+# the live 'lib/' dir of the distro
+# (e.g. modperl-2.0/ModPerl-Registry/lib)
+my $dir = canonpath catdir $FindBin::Bin, lib;
+push @dirs, $dir if -d $dir;
+
+# the live dir of the top dir if any (e.g. modperl-2.0/lib)
+if (-e catfile($FindBin::Bin, .., Makefile.PL)) {
+my $dir = canonpath catdir $FindBin::Bin, .., lib;
+push @dirs, $dir if -d $dir;
+}
I should have noticed this before, but all the mod_perl foo in TestConfig
really belongs in TestConfigPerl (including the stuff that was there before
this flurry of commits :)
it's too late for 1.05 at this point (which I hope to release on monday or
tuesday) but right afterward I'm going to clean up a bit and remove all
traces of mod_perl from TestConfig.
--Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
stas2003/10/21 15:09:11
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
Log:
complete the removal of hardcoding project/lib (besides the
autogenerated
t/TEST and other scripts where mp2 build must have it in @INC)
[snip]
+# mp2 needs its modper-2.0/lib before blib was created
+if (IS_MOD_PERL_2_BUILD || $ENV{APACHE_TEST_LIVE_DEV}) {
+# the live 'lib/' dir of the distro
+# (e.g. modperl-2.0/ModPerl-Registry/lib)
+my $dir = canonpath catdir $FindBin::Bin, lib;
+push @dirs, $dir if -d $dir;
+
+# the live dir of the top dir if any (e.g. modperl-2.0/lib)
+if (-e catfile($FindBin::Bin, .., Makefile.PL)) {
+my $dir = canonpath catdir $FindBin::Bin, .., lib;
+push @dirs, $dir if -d $dir;
+}
I should have noticed this before, but all the mod_perl foo in
TestConfig really belongs in TestConfigPerl (including the stuff that
was there before this flurry of commits :)
it's too late for 1.05 at this point (which I hope to release on monday
or tuesday) but right afterward I'm going to clean up a bit and remove
all traces of mod_perl from TestConfig.
Why? This code was there all the time and it has nothing to do with mod_perl
and needed for any other perl project. Your quite shows like it wasn't added,
but it wasn't, you have removed the - lines, which have shown where it existed
before.
__
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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
I should have noticed this before, but all the mod_perl foo in TestConfig really belongs in TestConfigPerl (including the stuff that was there before this flurry of commits :) it's too late for 1.05 at this point (which I hope to release on monday or tuesday) but right afterward I'm going to clean up a bit and remove all traces of mod_perl from TestConfig. Why? This code was there all the time and it has nothing to do with mod_perl and needed for any other perl project. Your quite shows like it wasn't added, but it wasn't, you have removed the - lines, which have shown where it existed before. I'm not arguing about whether it was there before and you were just following suit. this isn't necessarily about the changes you just made. what I'm saying is that we have the TestConfigPerl class for configuring mod_perl specific widgets and TestConfig should probably be as non-httpd-core-module neutral as we can make it. so, stuff like IS_MOD_PERL_2, IS_MOD_PERL_2_BUILD, and PerlRequire shouldn't be there conceptually. it just makes it harder to extend and maintain when there isn't a nice separation :) --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: On Mon, Jun 03, 2002 at 11:21:57AM -0700, Doug MacEachern wrote: On Mon, 3 Jun 2002, Aaron Bannert wrote: Cliff is always mentioning something like t/TEST -d gdb or something like that. Won't that run in -X mode automatically? The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). you can store the bps in the gdb startup script if you like. e.g. I've documented this idea here: http://perl.apache.org/release/docs/2.0/devel/debug_c/debug_c.html#Precooked_gdb_Startup_Scripts __ 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
this change is wrong. please revert and explain what you need so we can find the right solution. On 3 Jun 2002 [EMAIL PROTECTED] wrote: jerenkrantz2002/06/03 11:03:42 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: Only start one server instance until we need the other one for the proxy tests. Revision ChangesPath 1.137 +1 -1 httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm Index: TestConfig.pm === RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v retrieving revision 1.136 retrieving revision 1.137 diff -u -r1.136 -r1.137 --- TestConfig.pm 20 May 2002 22:25:34 - 1.136 +++ TestConfig.pm 3 Jun 2002 18:03:42 - 1.137 @@ -1553,7 +1553,7 @@ /IfModule IfModule prefork.c -StartServers @MaxClients@ +StartServers 1 MaxClients @MaxClients@ MaxRequestsPerChild 0 /IfModule
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Aaron Bannert wrote: Cliff is always mentioning something like t/TEST -d gdb or something like that. Won't that run in -X mode automatically? yes.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, Jun 03, 2002 at 11:21:57AM -0700, Doug MacEachern wrote: On Mon, 3 Jun 2002, Aaron Bannert wrote: Cliff is always mentioning something like t/TEST -d gdb or something like that. Won't that run in -X mode automatically? The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). I'm confused why this commit is an issue. None of the other MPMs start multiple processes - why should prefork? And, it's not like it won't start multiple processes when it needs to. -- justin
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). I'm confused why this commit is an issue. None of the other MPMs start multiple processes - why should prefork? And, it's not like it won't start multiple processes when it needs to. -- justin Not that I'm that experienced with the perl-framework over here, it would seem to me that it's important to run the tests under typical environments (ie multiple processes). Imagine a deadlocking bug that we never hit in -X mode. just my 2c, -aaron
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, Jun 03, 2002 at 11:34:39AM -0700, Aaron Bannert wrote: Not that I'm that experienced with the perl-framework over here, it would seem to me that it's important to run the tests under typical environments (ie multiple processes). Imagine a deadlocking bug that we never hit in -X mode. Um, as I pointed out, none of the other MPMs are configured like this. Only prefork would start multiple servers. The others always run under a single process. -- justin
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). you can use the -maxclients option or edit httpd.conf by hand before you start to debug. I'm confused why this commit is an issue. None of the other MPMs start multiple processes - why should prefork? it breaks any sort of proxy tests, various modperl test, etc. your change is just plain wrong, back it out. And, it's not like it won't start multiple processes when it needs to. -- justin umm, not with MaxClients 1 it won't
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: Um, as I pointed out, none of the other MPMs are configured like this. Only prefork would start multiple servers. The others always run under a single process. -- justin yeah, cos threaded mpms can handle concurrent requests with one process, prefork cannot.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, Jun 03, 2002 at 11:31:54AM -0700, Doug MacEachern wrote: On Mon, 3 Jun 2002, Justin Erenkrantz wrote: The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). you can use the -maxclients option or edit httpd.conf by hand before you start to debug. I'm confused why this commit is an issue. None of the other MPMs start multiple processes - why should prefork? it breaks any sort of proxy tests, various modperl test, etc. your change is just plain wrong, back it out. And, it's not like it won't start multiple processes when it needs to. -- justin umm, not with MaxClients 1 it won't Um, I think you misread my commit. All I changed was StartServers. IfModule prefork.c StartServers 1 MaxClients @MaxClients@ MaxRequestsPerChild 0 /IfModule MaxClients remained the same. In fact, I think it should be: IfModule prefork.c StartServers 1 MinSpareServers 1 MaxSpareServers 1 MaxClients @MaxClients@ MaxRequestsPerChild 0 /IfModule Now, Aaron mentioned that perhaps we should always run with multiple processes regardless of the MPMs. I could agree with that. But, what we had was inconsistent. -- justin
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Doug MacEachern wrote: umm, not with MaxClients 1 it won't oh wait, you changed StartServers not MaxClients, maybe that isn't a problem.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Mon, 3 Jun 2002, Justin Erenkrantz wrote: Um, I think you misread my commit. All I changed was StartServers. totally, i only read - @MaxClients@ + 1, never even saw StartServers. disregard my comments, they were meant for MaxClients, your change is fine with me.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On 6 Apr 2002 [EMAIL PROTECTED] wrote: dougm 02/04/05 18:39:31 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: try MP_AP_PREFIX in modperl build config for httpd location hint Doug. DOOD. You're working too hard. GO PARTY! ;) -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
On Fri, 5 Apr 2002, Cliff Woolley wrote: Doug. DOOD. You're working too hard. GO PARTY! ;) well, i am drinking a beer at least. wasn't expecting this GA push today, so i'm scrambling to get a modperl release together. then i will party like never before!
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Rodent of Unusual Size wrote:
Stas Bekman wrote:
How the other starting server is supposed to know whether port X is busy
because the first server is still running or it didn't quit cleanly?
{sigh} It doesn't. But the user tries to run the tests, gets
a 'port in use' error, and runs again with '-port select'. Now
there are two servers running -- and potentially *left* running.
He gets this a few times, and codes '-port select' into his
script. Now they're propagating like rabbits because of a bug
in the harness.
If you want to ensure that all the servers are always killed run,
% killall httpd
A wonderful alternative if the test suite is the ONLY server
running. Not. And the fact that you say that's how you kill them
might explain why they sometimes get left around -- it's a bug
you don't see.
OK, I got you. So we should make sure that the test suite will never
leave the server running when the testing is done.
Currently if for some reason this happens, harness will tell you that it
has failed to stop the server. What are the alternative, keeping on
trying to kill the server indefinitely? You realize that the server may
go into uninterruptable sleep state and no kill -9 will help.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Stas Bekman wrote: OK, I got you. So we should make sure that the test suite will never leave the server running when the testing is done. Bingo. Currently if for some reason this happens, harness will tell you that it has failed to stop the server. I am not sure that is actually the case, although your recent changes may have made it so. What are the alternative, keeping on trying to kill the server indefinitely? Just exit with an error status. Perhaps a spectrum of such exit values should be defined so a script can tell *what* aspect of the testing failed. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
Rick Myers wrote: On Jan 05, 2002 at 11:07:03 +0800, Stas Bekman wrote: But we shouldn't permit this to mask the existing problem of servers not being shut down at end of testing.. You mean this options introduces some new problems? It shouldn't change anything at all. All it does is doing the port selection for you. If the tests fail, pass, or shoot off fireworks, they should shut down the servers. No question. I've had problems with that in the old tests and it's just as relevant today. No matter what, those servers need to be shut down. Otherwise you're leaving an unexpected port open on a potentially live machine. That's obvious. I didn't question the need to shutdown servers. You don't answer my question though: has my recent patch introduced such a problem? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote: - implement '-port select' feature, so many t/TEST's can be run in parallel without forcing the user to assign non-colliding port numbers. Yay! Thanks! But we shouldn't permit this to mask the existing problem of servers not being shut down at end of testing.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRequest.pm TestRun.pm
Doug MacEachern wrote: i'll have a look on win32 later, in the meantime you can grab this: http://perl.apache.org/~dougm/httpd-test-sslca.tar.gz unpack it inside the httpd-test/perl-framework directory. and there will be no attempt to use openssl or generate the ca. Nope, I'm still getting the 'can't find openssl' error, unless I redo the 'perl Makefile.PL' step w/o the -ssl switch. Which, by the way, is particularly annoying when I'm not trying to run any SSL tests; it completely disables the suite. :-( IMHO, having to re-do the Makefile depending on whether you intend to test SSL or not isn't cool.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ All right everyone! Step away from the glowing hamburger!
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRequest.pm TestRun.pm
[EMAIL PROTECTED] wrote:
+if ($check) {
+my $openssl = Apache::TestSSLCA::openssl();
+if (which($openssl)) {
+return 1;
+}
+
+error cannot locate '$openssl' program required to generate SSL
CA;
+exit(1);
+}
Okey, now everything SSL is broken on my Win box, and I'm getting
this error. I don't have OpenSSL installed; if that is now a
requirement, -1 on this whole patch sequence..
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
All right everyone! Step away from the glowing hamburger!
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
From: [EMAIL PROTECTED] Sent: Tuesday, October 16, 2001 8:30 PM dougm 01/10/16 18:30:40 Modified:perl-framework/Apache-Test README perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm Log: backing out the set of --? enforcing patches due to breaking of: is not proxying requests: t/TEST -proxy args meant for Apache::TestRequest are dropped on the floor: t/TEST -post /foo content one=1 (-content was not working either) t/TEST -get /foo username x password y (nor -username or -password) runs all tests rather than just the specified one: t/TEST -httpd ~/foo/httpd t/foo/bar.t also was using @ARGV instead of @$argv that is passed into Apache::PerlRun-getopts (hmm, maybe this is what broke things, but i've already spent too much time fighting these problems, just need things to work right now) httpd is now 'undef'... not pretty... watching for the next commit. I believe the other patch you suggested for win32 paths solves our problem on that platform. As far as file 'comparisons' to the pod files, I believe we've probably opened those files in the wrong 'mode'... and we need to binmode them into binary (thus, all our mismatches :) Where would I find that comparison code? Bill
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: httpd is now 'undef'... not pretty... watching for the next commit. hmm, you might need to: t/TEST -clean (and double check that any *.conf in t/conf and t/conf/apache_test_config.pm are gone after that) and backing out that change means you'll need to use: perl Makefile.PL httpd .../Apache.exe rather than -httpd .../Apache.exe I believe the other patch you suggested for win32 paths solves our problem on that platform. ok great. As far as file 'comparisons' to the pod files, I believe we've probably opened those files in the wrong 'mode'... and we need to binmode them into binary (thus, all our mismatches :) Where would I find that comparison code? oh right, i'll need to dig to find it anyhow, i'll just go ahead and add the binmode() calls.
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: As far as file 'comparisons' to the pod files, I believe we've probably opened those files in the wrong 'mode'... and we need to binmode them into binary (thus, all our mismatches :) Where would I find that comparison code? hmm, server side the default-handler is sending the files, client side libwww-perl is reading the data over a socket, i don't think binmode() can be applied there, can it? and the comparision to the file on disk is done with -s $file; can you run that test with t/TEST -v t/apache/getfile so we can see what it reports for download and file bytes?
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
- Original Message - From: Doug MacEachern [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 16, 2001 10:27 PM Subject: Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm On Tue, 16 Oct 2001, William A. Rowe, Jr. wrote: As far as file 'comparisons' to the pod files, I believe we've probably opened those files in the wrong 'mode'... and we need to binmode them into binary (thus, all our mismatches :) Where would I find that comparison code? hmm, server side the default-handler is sending the files, client side libwww-perl is reading the data over a socket, i don't think binmode() can be applied there, can it? and the comparision to the file on disk is done with -s $file; can you run that test with t/TEST -v t/apache/getfile so we can see what it reports for download and file bytes? No, getfile got it right. Any chance that something is wrong with the socket handling itself?
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Wed, 5 Sep 2001, Doug MacEachern wrote: On 6 Sep 2001 [EMAIL PROTECTED] wrote: --- TestConfig.pm 2001/09/05 16:41:57 1.51 +++ TestConfig.pm 2001/09/06 02:36:44 1.52 @@ -940,6 +940,9 @@ HostnameLookups Off +# make sure that we test under Taint mode +PerlSwitches -T + wait a sec, i didn't notice the context before. this is the wrong place, since this generated httpd.conf is being used without modperl. should instead be in modperl-2.0/t/conf/extra.conf.in (that file will need to be added to cvs) fixed _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Thu, Sep 06, 2001 at 05:02:51AM -, [EMAIL PROTECTED] wrote: stas01/09/05 22:02:51 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm Log: This patch forces reconfiguration when: - httpd is newer than conf/httpd.conf - conf/*.in are newer than the autogenerated conf/* FWIW, I'm slowly figuring out this ezmlm moderation thing. I think your commits should make it without my intervention anymore. If not, keep committing and I'll get it right. =-) -- justin
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
On Wed, 5 Sep 2001, Justin Erenkrantz wrote: On Thu, Sep 06, 2001 at 05:02:51AM -, [EMAIL PROTECTED] wrote: stas01/09/05 22:02:51 Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm Log: This patch forces reconfiguration when: - httpd is newer than conf/httpd.conf - conf/*.in are newer than the autogenerated conf/* FWIW, I'm slowly figuring out this ezmlm moderation thing. I think your commits should make it without my intervention anymore. If not, keep committing and I'll get it right. =-) -- justin I've just screwed up with stray -m tag :( must go and eat something... I am reverting it now :( _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On 6 Sep 2001 [EMAIL PROTECTED] wrote:
stas01/09/05 19:36:44
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestConfigParse.pm
Log:
- enable taint mode in tests via PerlSwitches -T
- untaint $ENV{PATH} before using open -|
[snip]
diff -u -r1.7 -r1.8
--- TestConfigParse.pm 2001/08/20 15:20:50 1.7
+++ TestConfigParse.pm 2001/09/06 02:36:44 1.8
@@ -220,6 +220,8 @@
my $version;
my $cmd = $httpd -v;
+# untaint
+$ENV{PATH} = '/bin:/usr/bin';
open my $v, '-|', $cmd or die $cmd failed: $!;
local $_;
This breaks on mine even though $httpd is an absolute path at this point.
I'm not familiar enough with Perl to know why this should be, but is there
a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
Would that successfully untaint it?
I can't tell, since mine doesn't complain about it being tainted at this
point and I can't figure out a way to make it do so. Why do you need to
untaint here anyway? Is this something from mod_perl? I'm confused!
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, Sep 06, 2001 at 12:33:43PM +0100, Gary Benson wrote:
+$ENV{PATH} = '/bin:/usr/bin';
Hmmm, just noticed this in the reply. On Win32, the PATH sep is ';'
(assuming that you want this code to work there, don't know).
Don't know about the taint issues.
- Barrie
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Barrie Slaymaker wrote:
On Thu, Sep 06, 2001 at 12:33:43PM +0100, Gary Benson wrote:
+$ENV{PATH} = '/bin:/usr/bin';
Hmmm, just noticed this in the reply. On Win32, the PATH sep is ';'
(assuming that you want this code to work there, don't know).
Oops, portability issue. How about:
$ENV{PATH} = ''; We use full paths anyway.
_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Gary Benson wrote:
On 6 Sep 2001 [EMAIL PROTECTED] wrote:
stas01/09/05 19:36:44
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestConfigParse.pm
Log:
- enable taint mode in tests via PerlSwitches -T
- untaint $ENV{PATH} before using open -|
[snip]
diff -u -r1.7 -r1.8
--- TestConfigParse.pm2001/08/20 15:20:50 1.7
+++ TestConfigParse.pm2001/09/06 02:36:44 1.8
@@ -220,6 +220,8 @@
my $version;
my $cmd = $httpd -v;
+# untaint
+$ENV{PATH} = '/bin:/usr/bin';
open my $v, '-|', $cmd or die $cmd failed: $!;
local $_;
This breaks on mine even though $httpd is an absolute path at this point.
You mean if you don't add the patch from above?
I'm not familiar enough with Perl to know why this should be, but is there
a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
Would that successfully untaint it?
It's not about being absolute path or not, it's about opening -|, which
is insecure if $ENV{PATH} is not untainted.
I can't tell, since mine doesn't complain about it being tainted at this
point and I can't figure out a way to make it do so. Why do you need to
untaint here anyway? Is this something from mod_perl? I'm confused!
What's your Perl version? perl -v ?
It has nothing to do with mod_perl, it's a pure Perl issue (a good one :)
For more information please read the perlsec manpage:
% perldoc perlsec
or as the mod_perl guide suggests:
http://perl.apache.org/guide/help.html#Get_help_with_Perl_CGI:
http://www.gunther.web66.com/FAQS/taintmode.html
_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Stas Bekman wrote:
On Thu, 6 Sep 2001, Gary Benson wrote:
On 6 Sep 2001 [EMAIL PROTECTED] wrote:
stas01/09/05 19:36:44
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
TestConfigParse.pm
Log:
- enable taint mode in tests via PerlSwitches -T
- untaint $ENV{PATH} before using open -|
[snip]
diff -u -r1.7 -r1.8
--- TestConfigParse.pm 2001/08/20 15:20:50 1.7
+++ TestConfigParse.pm 2001/09/06 02:36:44 1.8
@@ -220,6 +220,8 @@
my $version;
my $cmd = $httpd -v;
+# untaint
+$ENV{PATH} = '/bin:/usr/bin';
open my $v, '-|', $cmd or die $cmd failed: $!;
local $_;
This breaks on mine even though $httpd is an absolute path at this point.
You mean if you don't add the patch from above?
From a clean, current CVS checkout:
% cd httpd-test/perl-framework
% export PATH=/path/to/httpd-and-apxs:$PATH
% perl Makefile.PL
% make
% t/TEST -start-httpd
setting ulimit to allow core files
ulimit -c unlimited
exec t/TEST -start-httpd
cannot build c-modules without apxs
no test server configured, please specify an httpd or apxs or put either in
your PATH
I'm not familiar enough with Perl to know why this should be, but is there
a better way (like $ENV{PATH} = '/bin:/usr/bin' unless $httpd =~ m:^/:;).
Would that successfully untaint it?
It's not about being absolute path or not, it's about opening -|, which
is insecure if $ENV{PATH} is not untainted.
I don't really think I understand this line:
|open my $v, '-|', $cmd or die $cmd failed: $!;
As far as I see it, '-|' means perform an explicit fork, with return
value of open being child pid in the parent and 0 in the child. From what
I see, it looks like you should be doing either of these two:
|open my $v, $httpd| or die $cmd failed: $!;
|open my $v, '-|' or exec $httpd or die $cmd failed: $!;
I'm not saying that your code is _wrong_: I'm saying I don't understand
it. I can see what your line does, but now how it does it or why '-|' is
insecure.
I can't tell, since mine doesn't complain about it being tainted at this
point and I can't figure out a way to make it do so. Why do you need to
untaint here anyway? Is this something from mod_perl? I'm confused!
What's your Perl version? perl -v ?
v5.6.1
I'm just running it as my UID, so would taint checking happen anyway?
Gary
[ Gary Benson, Red Hat Europe ][ [EMAIL PROTECTED] ][ GnuPG 60E8793A ]
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Gary Benson wrote:
+# untaint
+$ENV{PATH} = '/bin:/usr/bin';
this should be 'local $ENV{PATH} = ...;', does that help at all?
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigParse.pm
On Thu, 6 Sep 2001, Doug MacEachern wrote:
On Thu, 6 Sep 2001, Gary Benson wrote:
+# untaint
+$ENV{PATH} = '/bin:/usr/bin';
this should be 'local $ENV{PATH} = ...;', does that help at all?
oops, I've missed the point that you were explicitly set PATH:
% export PATH=/path/to/httpd-and-apxs:$PATH
so I was ruining it. So would the empty path will be OK?
local $ENV{PATH} = '';
_
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://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
