Re: Apache::Test oustanding issues
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
But I don't see anything in Apache-Test/Changes. Can you please fix that? Thanks. done --Geoff
Re: Apache::Test oustanding issues
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
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 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: Apache::Test oustanding issues
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
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
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 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: Apache::Test oustanding issues
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 [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Apache::Test oustanding issues
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
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 [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Apache::Test oustanding issues
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
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
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 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: Apache::Test oustanding issues
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 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: Apache::Test oustanding issues
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
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 [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
