Udo Rader wrote:
Am Tue, 26 Aug 2003 16:07:21 +0000 schrieb Stas Bekman:

As you posted in the followup, this is a problem with all Apache:: modules. The problem originates within Apache, not us.


Didn't know that apache rejects to run as root. Strange (but safe) behaviour.

It starts as root alright, but won't spawn workers as root.


Ideas how to solve this are *very* welcome.


The best idea I have is to serve the htdocs directory from outside the
~root hierarchy. Apache is initially started as root and thus has no
difficulties to get the configuration stuff needed to start up.

A quick (non MSWormOS compatible) fix would be to patch
lib/Apache/TestConfig.pm as follows:

-------CUT--------
--- TestConfig.pm 2003-06-07 01:43:28.000000000 +0200
+++ TestConfig.pm.docroot_patched 2003-08-27 12:13:26.000000000 +0200
@@ -214,7 +214,7 @@
$vars->{t_dir} ||= catfile $vars->{top_dir}, 't';
$vars->{serverroot} ||= $vars->{t_dir};
- $vars->{documentroot} ||= catfile $vars->{serverroot}, 'htdocs';
+ $vars->{documentroot} ||= "/tmp/Apache-Test.$$/htdocs";
$vars->{perlpod} ||= $self->find_in_inc('pods') ||
$self->find_in_inc('pod');
$vars->{perl} ||= $^X;
-------CUT--------

this is only needed for root-run tests, which most of us don't do.


Moving the entire t/ directory to temp is IMHO not necessary, but depending on
the test needs it may also be required to copy a cgi-bin directory to /tmp as well.

Other dirs top-level t/ dirs may need to be copied as well, e.g. t/logs if they have some custom logs written from the handlers. Ideally it should be configurable by the developer that uses Apache::Test.


But I agree that it's certainly a good idea to copy only the minimal amount of files.

For a better solution of course it would also be reasonable to query the ENV settings that even exist on MSWorm (IIRC) and even better check that directory's permissions and fallback again to /tmp, if nothing else is found. But this is maybe something that File::Spec, which nathan mentioned, already does.

Yup, this is going to be the hardest part. We need a good portable test. Currently I do this check. I have no idea how portable it is. Please tell me if there is some problem with it.


You can find it in Apache-Test/lib/Apache/TestRun.pm of the current modperl-2.0 cvs:

sub check_perms {
    my ($self, $user, $uid, $gid) = @_;

    # test that the base dir is rwx by the selected non-root user
    my $vars = $self->{test_config}->{vars};
    my $dir  = $vars->{t_dir};
    my $perl = $vars->{perl};
    my $check = qq[sudo -u '#$uid' $perl -e ] .
        qq['print -r "$dir" &&  -w _ && -x _ ? "OK" : "NOK"'];
    warning "$check\n";
    my $res   = qx[$check] || '';
    warning "result: $res";
    unless ($res eq 'OK') {
        #$self->restore_t_perms;
        error(<<"EOI") && die "\n";
You are running the test suite under user 'root'.
Apache cannot spawn child processes as 'root', therefore
we attempt to run the test suite with user '$user' ($uid:$gid).
The problem is that the path:
  $dir
must be 'rwx' by user '$user', so Apache can read and write under that
path.

There several ways to resolve this issue. For example move
'$dir' to '/tmp/' and repeat the 'make test' phase.

You can test whether the location is good by running the following test:
  % $check
EOI
    }
}

IMHO again the build dir in general should default to /tmp/cpan_$USER (or /var/tmp/cpan_$USER if you prefer), so it would be a good thing to change the default setting of CPAN's initial configuration for future CPAN releases.

In some ways CPAN packages are very similar to SRPMS and I think CPAN could learn
a lot from RPM here.

Well, that is the wrong forum to discuss the CPAN issues, at least because those who control CPAN.pm aren't listening ;)



__________________________________________________________________ Stas Bekman JAm_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



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Reply via email to