You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2003/07/29 00:24:22 UTC
Apache::Test oustanding issues
In the last few weeks the following two issues were raised:
1) store a default location of httpd/apxs in Apache::Test so one should
provide it only once.
I'm +1 on this feature. Is anybody interested to implement it?
2) We have a problem with Apache::Test running as root, since when Apache
"sudoes" into 'nobody' it can't access files under /root or some other root
owned dir. The current cvs version already tries to tell the user about the
problem before starting to run the test suite.
Currently the only solution that was suggested is to copy t/ into /tmp and run
the tests from there and then cleanup. That doesn't sound good to me, however
I don't have any better ideas. I hope that you do.
Try to download Apache-Test (the current cvs!) into /root and run make test
from there, to see what I'm talking about.
Once these two issues are resolved I think it's a time for the next release.
Let me know if you have some other issues that need to go in now.
Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> But I don't see anything in Apache-Test/Changes. Can you please fix
> that? Thanks.
done
--Geoff
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> Stas Bekman wrote:
>
>> Geoffrey Young wrote:
>>
>>> BTW, are we still +1 on the have_apache_mpm() patch I posted last? I
>>> know Bill had some thoughts on hitting up ap_mpm_query instead of
>>> httpd -V, but if we can agree on have_apache_mpm() as the API, then
>>> we can use the current implementation and I can play with
>>> ap_mpm_query in a bit.
>>
>>
>>
>> I have already replied +1 in the other thread ;)
>
>
> I know, but that was before Bill raised his hand :)
> anyway, it's committed as per our last discussion (but no email yet... hmm)
neither did I. the commit did make through. I suppose this is because the
moderator hasn't approved your post yet. I'm not sure who it is (since this is
your first post from non-subscribed address).
But I don't see anything in Apache-Test/Changes. Can you please fix that? Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> BTW, are we still +1 on the have_apache_mpm() patch I posted last? I
>> know Bill had some thoughts on hitting up ap_mpm_query instead of
>> httpd -V, but if we can agree on have_apache_mpm() as the API, then we
>> can use the current implementation and I can play with ap_mpm_query in
>> a bit.
>
>
> I have already replied +1 in the other thread ;)
I know, but that was before Bill raised his hand :)
anyway, it's committed as per our last discussion (but no email yet... hmm)
--Geoff
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> BTW, are we still +1 on the have_apache_mpm() patch I posted last? I
> know Bill had some thoughts on hitting up ap_mpm_query instead of httpd
> -V, but if we can agree on have_apache_mpm() as the API, then we can use
> the current implementation and I can play with ap_mpm_query in a bit.
I have already replied +1 in the other thread ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> well, it was a web services interface, and some of the services
>> required root permission to manipulate certain backend elements.
>
>
> You still have the root permissions. it's only the server that starts
> with non-root perms. why do you needed that override?
you need to be root in order to start Apache so its children run as root -
the forced change to the nobody user was wrecking things for me.
anyway, enough on that :)
> I don't think we need to chdir to /tmp
hmm, I would have thought that was necessary, but without trying it entirely
I guess I won't know :)
anyway, I'll be back into the swing of things late this week and can help out.
BTW, are we still +1 on the have_apache_mpm() patch I posted last? I know
Bill had some thoughts on hitting up ap_mpm_query instead of httpd -V, but
if we can agree on have_apache_mpm() as the API, then we can use the current
implementation and I can play with ap_mpm_query in a bit.
--geoff
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>> the way I handled this was to add the following to my TEST.PL
>>>
>>> # override root blocks
>>> local *Apache::TestConfig::default_user = sub { return 'root' };
>>> local *Apache::TestConfig::default_group = sub { return 'root' };
>>
>>
>>
>> why do you need to run tests as root?
>
>
> well, it was a web services interface, and some of the services required
> root permission to manipulate certain backend elements.
You still have the root permissions. it's only the server that starts with
non-root perms. why do you needed that override?
>>> # and that nasty chown stuff
>>> local *Apache::TestRun::adjust_t_perms = sub { 1 };
>>
>>
>>
>> root can still work with files owned by 'nobody', but of course...
>
>
> I forget why I did that. I think it was to enable files added by
> root-run tests to be removed by normal users, but I'm not sure - it was
> something like that :)
but that's exactly what adjust_t_perms does. Otherwise normal user can't
create/write/delete them.
>> let me repeat what the problem is:
>>
>> cd /root ; mkdir t ; chmod 0777 t ;
>> sudo -u 'nobody' perl -le 'print -r "t" && -w _ && -x _ ? "OK" : "NOK"'
>>
>> if you can make it return 'OK', than the problem is solved.
>
>
> yeah, ok, I get it now.
>
> well, perhaps the /tmp copy isn't so bad (I misread it :)
I shouldn't have mentioned this idea, so may be someone will have a better one ;)
> the issue that we will have, though, is for people whose tests need to
> get back to the base directory, ../. so, I'd also suggest some function
> or package global that can be used in place of ../, making
>
> my $lib = catfile($Apache::Test::basedir, 'lib');
>
> equivalent to (from t/)
>
> my $lib= catfile('../', 'lib');
>
> and
>
> my $lib = catfile('/src/Apache-Foo', 'lib');
I don't think we need to chdir to /tmp, I think all we need is to tell Apache
that DocRoot is /tmp/whatever/t. you still run from the normal dir. Or are you
saying that you want the DocRoot to be the original t/?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> the way I handled this was to add the following to my TEST.PL
>>
>> # override root blocks
>> local *Apache::TestConfig::default_user = sub { return 'root' };
>> local *Apache::TestConfig::default_group = sub { return 'root' };
>
>
> why do you need to run tests as root?
well, it was a web services interface, and some of the services required
root permission to manipulate certain backend elements.
>
>> # and that nasty chown stuff
>> local *Apache::TestRun::adjust_t_perms = sub { 1 };
>
>
> root can still work with files owned by 'nobody', but of course...
I forget why I did that. I think it was to enable files added by root-run
tests to be removed by normal users, but I'm not sure - it was something
like that :)
>
> let me repeat what the problem is:
>
> cd /root ; mkdir t ; chmod 0777 t ;
> sudo -u 'nobody' perl -le 'print -r "t" && -w _ && -x _ ? "OK" : "NOK"'
>
> if you can make it return 'OK', than the problem is solved.
yeah, ok, I get it now.
well, perhaps the /tmp copy isn't so bad (I misread it :)
the issue that we will have, though, is for people whose tests need to get
back to the base directory, ../. so, I'd also suggest some function or
package global that can be used in place of ../, making
my $lib = catfile($Apache::Test::basedir, 'lib');
equivalent to (from t/)
my $lib= catfile('../', 'lib');
and
my $lib = catfile('/src/Apache-Foo', 'lib');
--Geoff
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
Welcome back, Geoff!
>> 2) We have a problem with Apache::Test running as root, since when
>> Apache "sudoes" into 'nobody' it can't access files under /root or
>> some other root owned dir. The current cvs version already tries to
>> tell the user about the problem before starting to run the test suite.
>
>
> I've use A::T to test a SOAP server that runs as root, which means the
> tests need to be run as root as well.
>
> the way I handled this was to add the following to my TEST.PL
>
> # override root blocks
> local *Apache::TestConfig::default_user = sub { return 'root' };
> local *Apache::TestConfig::default_group = sub { return 'root' };
why do you need to run tests as root?
> # and that nasty chown stuff
> local *Apache::TestRun::adjust_t_perms = sub { 1 };
root can still work with files owned by 'nobody', but of course...
> which worked very well.
>
> now, I'm not suggesting TEST.PL changes as a fix, but couldn't we do
> something similar behind the scenes if the user is running as root?
Sorry, I don't understand you? Do you suggest that the 'root' case should be
optional? How does it help to solve our problem?
let me repeat what the problem is:
cd /root ; mkdir t ; chmod 0777 t ;
sudo -u 'nobody' perl -le 'print -r "t" && -w _ && -x _ ? "OK" : "NOK"'
if you can make it return 'OK', than the problem is solved.
>> Currently the only solution that was suggested is to copy t/ into /tmp
>> and run the tests from there and then cleanup. T
>
>
> yucko!
Got a better idea?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 2) We have a problem with Apache::Test running as root, since when
> Apache "sudoes" into 'nobody' it can't access files under /root or some
> other root owned dir. The current cvs version already tries to tell the
> user about the problem before starting to run the test suite.
I've use A::T to test a SOAP server that runs as root, which means the tests
need to be run as root as well.
the way I handled this was to add the following to my TEST.PL
# override root blocks
local *Apache::TestConfig::default_user = sub { return 'root' };
local *Apache::TestConfig::default_group = sub { return 'root' };
# and that nasty chown stuff
local *Apache::TestRun::adjust_t_perms = sub { 1 };
which worked very well.
now, I'm not suggesting TEST.PL changes as a fix, but couldn't we do
something similar behind the scenes if the user is running as root?
>
> Currently the only solution that was suggested is to copy t/ into /tmp
> and run the tests from there and then cleanup. T
yucko!
--Geoff
Re: Apache::Test oustanding issues
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 29 Jul 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Tue, 29 Jul 2003, Stas Bekman wrote:
> >
> >>In the last few weeks the following two issues were raised:
> >>
> >>1) store a default location of httpd/apxs in Apache::Test so one should
> >>provide it only once.
> >>
> >>I'm +1 on this feature. Is anybody interested to implement it?
> >
> > That sounds like a good idea ... Are you thinking of something
> > like Apache::MyConfig.pm of mod_perl 1, or libnet.cfg of libnet -
> > a file which gets created the first time the user installs the
> > package, and then gets used on subsequent locations, with perhaps
> > an initial dialogue asking the user if they want to keep the
> > stored settings?
>
> Yes. That's the idea Matt brought up earlier on this list.
I'd be interested in taking a look at this ... But just so
I understand the intent,
- this configuration file would get written at the
'perl Makefile.PL' stage?
- if the user supplies -httpd and/or -apxs values to
'perl Makefile.PL', or suitable environment variables
are set, a dialogue should be invoked, confirming
that the user wants to store these values?
- if no such values nor environment variables are supplied,
guesses are made, and again the user is asked to confirm?
- upon later uses of Apache::Test, these stored values
would be used, unless explicit -httpd or -apxs arguments
to t/TEST are given, or the appropriate environment variables
are set?
- is it only httpd and apxs that get stored, or would it
be useful to have others (eg, the Apache user, group, or port)?
--
best regards,
randy
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 29 Jul 2003, Stas Bekman wrote:
>
>
>>In the last few weeks the following two issues were raised:
>>
>>1) store a default location of httpd/apxs in Apache::Test so one should
>>provide it only once.
>>
>>I'm +1 on this feature. Is anybody interested to implement it?
>
>
> That sounds like a good idea ... Are you thinking of something
> like Apache::MyConfig.pm of mod_perl 1, or libnet.cfg of libnet -
> a file which gets created the first time the user installs the
> package, and then gets used on subsequent locations, with perhaps
> an initial dialogue asking the user if they want to keep the
> stored settings?
Yes. That's the idea Matt brought up earlier on this list.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 29 Jul 2003, Stas Bekman wrote:
> In the last few weeks the following two issues were raised:
>
> 1) store a default location of httpd/apxs in Apache::Test so one should
> provide it only once.
>
> I'm +1 on this feature. Is anybody interested to implement it?
That sounds like a good idea ... Are you thinking of something
like Apache::MyConfig.pm of mod_perl 1, or libnet.cfg of libnet -
a file which gets created the first time the user installs the
package, and then gets used on subsequent locations, with perhaps
an initial dialogue asking the user if they want to keep the
stored settings?
--
best regards,
randy
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 28 Jul 2003, David Wheeler wrote:
>
>
>>On Monday, July 28, 2003, at 06:33 PM, Randy Kobes wrote:
>
>
>>>What about just skipping the tests if root is running the
>>>tests, and printing out an explanatory message why the tests
>>>are skipped?
>>
>>I don't think you can necessarily do this, because not all test
>>need to have access to t/. My test suite for
>>MasonX::ApacheHandler::WithCallbacks, for example, doesn't need
>>to have the Apache user access those files. They're loaded up
>>by the user that starts apache (root), and then the process
>>forks off to nobody-owned children that never access the files.
>>So my tests work fine even under root.
>
>
> That's a good point ... As you say below, it'd be better for
> the test writer to decide on an individual basis which tests
> should be skipped if run as root.
this means 99.9% tests in mod_perl 2.0. But we really want to have users run
the tests. Otherwise what's the point of having a test suite. If things are
potentially wrong on a user's system we want him to know about it as early as
possible and not by trial and error with their own code.
I'd suggest to first try to find a real solution so the tests could be run
under root as well. copying -r ./t to /tmp seems to me like a possible
solution, even though an ugly one.
>>And since many, _many_ users simply install modules via CPAN.pm
>>as root, you'd be eliminating a huge group of people who can
>>run tests.
>
>
> That's true, although that practice is discouraged ... I think
> this issue has come up in the context of other CPAN modules,
> where some do skip tests if run as root, for similar reasons -
> some tests aren't designed for being run as root, and in
> principle may give false positive (or negative) results if run as
> such.
the practice was/is discouraged where the problem wasn't dealt with. I'd love
to see it solved and make it transparent for the user.
>>I think a better idea is to introduce a test function like
>>"have_lwp", maybe called "has_access_to_t", that can be used by
>>the module developer to skip the relevant tests, if necessary.
I think we can do it better.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 28 Jul 2003, David Wheeler wrote:
> On Monday, July 28, 2003, at 06:33 PM, Randy Kobes wrote:
> > What about just skipping the tests if root is running the
> > tests, and printing out an explanatory message why the tests
> > are skipped?
>
> I don't think you can necessarily do this, because not all test
> need to have access to t/. My test suite for
> MasonX::ApacheHandler::WithCallbacks, for example, doesn't need
> to have the Apache user access those files. They're loaded up
> by the user that starts apache (root), and then the process
> forks off to nobody-owned children that never access the files.
> So my tests work fine even under root.
That's a good point ... As you say below, it'd be better for
the test writer to decide on an individual basis which tests
should be skipped if run as root.
> And since many, _many_ users simply install modules via CPAN.pm
> as root, you'd be eliminating a huge group of people who can
> run tests.
That's true, although that practice is discouraged ... I think
this issue has come up in the context of other CPAN modules,
where some do skip tests if run as root, for similar reasons -
some tests aren't designed for being run as root, and in
principle may give false positive (or negative) results if run as
such.
> I think a better idea is to introduce a test function like
> "have_lwp", maybe called "has_access_to_t", that can be used by
> the module developer to skip the relevant tests, if necessary.
--
best regards,
randy
Re: Apache::Test oustanding issues
Posted by David Wheeler <da...@kineticode.com>.
On Monday, July 28, 2003, at 06:33 PM, Randy Kobes wrote:
> Depending on where the source directory is, you may have to open
> up a parent directory normally restricted to root to a non-root
> user, which wouldn't be a good idea, even temporarily.
Right. Grr.
> What about
> just skipping the tests if root is running the tests, and
> printing out an explanatory message why the tests are skipped?
I don't think you can necessarily do this, because not all test need to
have access to t/. My test suite for
MasonX::ApacheHandler::WithCallbacks, for example, doesn't need to have
the Apache user access those files. They're loaded up by the user that
starts apache (root), and then the process forks off to nobody-owned
children that never access the files. So my tests work fine even under
root.
And since many, _many_ users simply install modules via CPAN.pm as
root, you'd be eliminating a huge group of people who can run tests.
I think a better idea is to introduce a test function like "have_lwp",
maybe called "has_access_to_t", that can be used by the module
developer to skip the relevant tests, if necessary.
Regards,
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: Apache::Test oustanding issues
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 28 Jul 2003, David Wheeler wrote:
> On Monday, July 28, 2003, at 04:52 PM, Stas Bekman wrote:
>
> > We do that already. The problem is in the parent path.
> > Try:
> > cd /root ; mkdir t ; chmod 0777 t ;
> > sudo -u 'nobody' perl -le 'print -r "t" && -w _ && -x _ ? "OK" : "NOK"'
>
> Oh, right. That's one thing about Unix that I never got the hang of.
> But don't you get the username and group from httpd.conf? Couldn't use
> use that information to do chown and chgrp?
>
> David
Depending on where the source directory is, you may have to open
up a parent directory normally restricted to root to a non-root
user, which wouldn't be a good idea, even temporarily. What about
just skipping the tests if root is running the tests, and
printing out an explanatory message why the tests are skipped?
--
best regards,
randy
Re: Apache::Test oustanding issues
Posted by David Wheeler <da...@kineticode.com>.
On Monday, July 28, 2003, at 04:52 PM, Stas Bekman wrote:
> We do that already. The problem is in the parent path.
>
> Try:
>
> cd /root ; mkdir t ; chmod 0777 t ;
> sudo -u 'nobody' perl -le 'print -r "t" && -w _ && -x _ ? "OK" : "NOK"'
Oh, right. That's one thing about Unix that I never got the hang of.
But don't you get the username and group from httpd.conf? Couldn't use
use that information to do chown and chgrp?
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]
Re: Apache::Test oustanding issues
Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Monday, July 28, 2003, at 03:24 PM, Stas Bekman wrote:
>
>> 2) We have a problem with Apache::Test running as root, since when
>> Apache "sudoes" into 'nobody' it can't access files under /root or
>> some other root owned dir. The current cvs version already tries to
>> tell the user about the problem before starting to run the test suite.
>>
>> Currently the only solution that was suggested is to copy t/ into /tmp
>> and run the tests from there and then cleanup. That doesn't sound good
>> to me, however I don't have any better ideas. I hope that you do.
>
>
> What about
>
> chmod 0777, 't' or die "Can't chmod 't': $!\n";
We do that already. The problem is in the parent path.
Try:
cd /root ; mkdir t ; chmod 0777 t ;
sudo -u 'nobody' perl -le 'print -r "t" && -w _ && -x _ ? "OK" : "NOK"'
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test oustanding issues
Posted by David Wheeler <da...@kineticode.com>.
On Monday, July 28, 2003, at 03:24 PM, Stas Bekman wrote:
> 2) We have a problem with Apache::Test running as root, since when
> Apache "sudoes" into 'nobody' it can't access files under /root or
> some other root owned dir. The current cvs version already tries to
> tell the user about the problem before starting to run the test suite.
>
> Currently the only solution that was suggested is to copy t/ into /tmp
> and run the tests from there and then cleanup. That doesn't sound good
> to me, however I don't have any better ideas. I hope that you do.
What about
chmod 0777, 't' or die "Can't chmod 't': $!\n";
?
David
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
http://kineticode.com/ Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]