Re: [MP2] failed to resolve handler `Apache::PerlSections'
On Fri, 2003-12-05 at 20:46, Stas Bekman wrote:
> Stas Bekman wrote:
> > Stas Bekman wrote:
> >
> >> Stas Bekman wrote:
> >> [...]
> >>
> >>> The problem seems to be as following: Apache::Status somehow
> >>> autovivifies Apache::PerlSections stash, while Apache/PerlSections.pm
> >>> wasn't loaded yet. That's why preloading Apache::PerlSections solves
> >>> the problem. Our code does not attempt to load packages whose stashes
> >>> exist, which is obviously wrong. I'll post a patch soonish. I think
> >>> instead of checking for the stash, we need to check %INC.
[...]
> >
> > I think it at least gives users more control, rather than having obscure
> > problems when an autovivified stash will prevent the package loading.
> > Like in the case posted by Enrico.
>
> Or may be we should do the following:
>
> If the package is not loaded (not in %INC), try to load it, but don't bail out
> if it fails (like in the case with Unloaded). Next try to lookup the stash, if
> it's found (which should be the case with Unloaded, since Loaded will load it)
> , then move on, and only if the stash is not found bail out with the loading
> failure error?
Sounds to me like a pretty good way to do what the user would expects
;-) But I wonder, how exactly does Perl do this internally when I do
"use Module", and could we not reuse that ?
> __
> 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
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [MP2] failed to resolve handler `Apache::PerlSections'
Philippe M. Chiasson wrote: The problem seems to be as following: Apache::Status somehow autovivifies Apache::PerlSections stash, while Apache/PerlSections.pm wasn't loaded yet. That's why preloading Apache::PerlSections solves the problem. Our code does not attempt to load packages whose stashes exist, which is obviously wrong. I'll post a patch soonish. I think instead of checking for the stash, we need to check %INC. [...] I think it at least gives users more control, rather than having obscure problems when an autovivified stash will prevent the package loading. Like in the case posted by Enrico. Or may be we should do the following: If the package is not loaded (not in %INC), try to load it, but don't bail out if it fails (like in the case with Unloaded). Next try to lookup the stash, if it's found (which should be the case with Unloaded, since Loaded will load it) , then move on, and only if the stash is not found bail out with the loading failure error? Sounds to me like a pretty good way to do what the user would expects ;-) But I wonder, how exactly does Perl do this internally when I do "use Module", and could we not reuse that ? It only checks %INC. perl -le '$Foo::Bar::x = 1; require Foo::Bar' Can't locate Foo/Bar.pm in @INC We could do the same, but then we will have to drop the magic-behind-the-scene-loading of Foo::Bar when Foo::Bar::handler is configured in httpd.conf. Currently we require to preload the module explicitly only if a different from ::handler sub is used. (And a few other cases, like filters) __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MP2] failed to resolve handler `Apache::PerlSections'
Enrico Sorcinelli wrote: On Thu, 04 Dec 2003 17:16:38 -0800 Stas Bekman <[EMAIL PROTECTED]> wrote: Hi Stas, [...] The problem seems to be as following: Apache::Status somehow autovivifies Apache::PerlSections stash, while Apache/PerlSections.pm wasn't loaded yet. That's why preloading Apache::PerlSections solves the problem. Our code does not attempt to load packages whose stashes exist, which is obviously wrong. I'll post a patch soonish. I think instead of checking for the stash, we need to check %INC. It was a bit trickier than I thought, but now the code is even simpler to follow. This should solve your problem Enrico. 'make test' pass 100% with this patch. I've applied the patch (manually because 'patch' fails) to mp 1.9911 (Perl 5.8.1): all tests pass and the problem seems to be solved. Great, thanks for testing, Enrico. The patch may have failed as it was against the cvs tree, not 1.9911. You will insert it into the current CVS or we should apply the patch each time (or we should be preload Apache::PerlSections)? Watch this thread's resolution (which wasn't reached yet) and some sort of solution will be applied. Many 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
[EMAIL PROTECTED] wrote: geoff 2003/12/08 11:31:53 Modified:xs/APR/SockAddr APR__SockAddr.h xs/maps apr_functions.map xs/tables/current/Apache FunctionTable.pm xs/tables/current/ModPerl FunctionTable.pm Log: more APR deprecation: apr_sockaddr_port_get and apr_sockaddr_port_set Hmm, how come there are deprecated? This is from apr/include/apr_network_io.h APR_0_9_BRANCH /** * Set the port in an APR socket address. * @param sockaddr The socket address to set. * @param port The port to be stored in the socket address. */ APR_DECLARE(apr_status_t) apr_sockaddr_port_set(apr_sockaddr_t *sockaddr, apr_port_t port); /** * Return the port in an APR socket address. * @param port The port from the socket address. * @param sockaddr The socket address to reference. */ APR_DECLARE(apr_status_t) apr_sockaddr_port_get(apr_port_t *port, apr_sockaddr_t *sockaddr); AFAIK, httpd-2.0 uses that branch. Or had they switched that? In any case, shouldn't these function be replaced with new equivalents rather than being removed? __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
Stas Bekman wrote: > [EMAIL PROTECTED] wrote: > >> geoff 2003/12/08 11:31:53 >> >> Modified:xs/APR/SockAddr APR__SockAddr.h >>xs/maps apr_functions.map >>xs/tables/current/Apache FunctionTable.pm >>xs/tables/current/ModPerl FunctionTable.pm >> Log: >> more APR deprecation: apr_sockaddr_port_get and apr_sockaddr_port_set > > > Hmm, how come there are deprecated? This is from > apr/include/apr_network_io.h APR_0_9_BRANCH you need to look at 1.0, of course. from CHANGES *) The following deprecated interfaces have been removed: ... apr_sockaddr_port_get-> (access directly) apr_sockaddr_port_set-> apr_sockaddr_info_get > In any case, shouldn't these function be replaced with new equivalents > rather than being removed? apr_sockaddr_info_get is the replacement for a few things. however, it's currently defined as MODULE=APR::SockAddr !apr_sockaddr_info_get and I figured there was a reason for that (I didn't do it). --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
Geoffrey Young wrote: Stas Bekman wrote: [EMAIL PROTECTED] wrote: geoff 2003/12/08 11:31:53 Modified:xs/APR/SockAddr APR__SockAddr.h xs/maps apr_functions.map xs/tables/current/Apache FunctionTable.pm xs/tables/current/ModPerl FunctionTable.pm Log: more APR deprecation: apr_sockaddr_port_get and apr_sockaddr_port_set Hmm, how come there are deprecated? This is from apr/include/apr_network_io.h APR_0_9_BRANCH you need to look at 1.0, of course. Why? httpd-2.0 runs with APR_0_9_BRANCH, not 1.0. Or doesn't it? As you can see it was never deprecated, they just yanked the functions... > from CHANGES *) The following deprecated interfaces have been removed: ... apr_sockaddr_port_get-> (access directly) apr_sockaddr_port_set-> apr_sockaddr_info_get In any case, shouldn't these function be replaced with new equivalents rather than being removed? apr_sockaddr_info_get is the replacement for a few things. however, it's currently defined as MODULE=APR::SockAddr !apr_sockaddr_info_get and I figured there was a reason for that (I didn't do it). May be it was disabled because the other functions (that you've now removed) gave that information already? In any case should we log that somewhere in todo lists till someone asks for it and we don't have to try to recall why it's not there? It'd be also nice to add explanations in the map file, why certain functions are marked with '!'. Perhaps ask Doug? __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
>>> Hmm, how come there are deprecated? This is from >>> apr/include/apr_network_io.h APR_0_9_BRANCH >> >> >> >> you need to look at 1.0, of course. > > > Why? httpd-2.0 runs with APR_0_9_BRANCH, not 1.0. Or doesn't it? well, it does for the moment, yes. but I've been cleaning things up so that the perl interfaces to APR are 1.0 compliant. that was the goal a few months ago, IIRC. it also keeps mod_perl compiling with 2.1, which I thought we had agreed was a worthy goal so long as we could keep 2.0 running at the same time. since none of these changes affect our ability to interact with httpd 2.0, I thought it was safe to remove them. this all assumes that the APR:: interfaces are focused on 1.0 compatibility and not 0.9 (which was my assumption). >> MODULE=APR::SockAddr >> !apr_sockaddr_info_get >> >> and I figured there was a reason for that (I didn't do it). > > > May be it was disabled because the other functions (that you've now > removed) gave that information already? perhaps. I'll look into whether that function can be opened up. > In any case should we log that > somewhere in todo lists till someone asks for it and we don't have to > try to recall why it's not there? it's pretty obvious why it's not there if you look at the maps, which I tend to do all the time now. but if you want to log it that's fine. > > It'd be also nice to add explanations in the map file, why certain > functions are marked with '!'. Perhaps ask Doug? you can if you like :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/xs/tables/current/ModPerl FunctionTable.pm
Geoffrey Young wrote: Hmm, how come there are deprecated? This is from apr/include/apr_network_io.h APR_0_9_BRANCH you need to look at 1.0, of course. Why? httpd-2.0 runs with APR_0_9_BRANCH, not 1.0. Or doesn't it? well, it does for the moment, yes. but I've been cleaning things up so that the perl interfaces to APR are 1.0 compliant. that was the goal a few months ago, IIRC. it also keeps mod_perl compiling with 2.1, which I thought we had agreed was a worthy goal so long as we could keep 2.0 running at the same time. Sure, as long as we don't just drop things. since none of these changes affect our ability to interact with httpd 2.0, I thought it was safe to remove them. this all assumes that the APR:: interfaces are focused on 1.0 compatibility and not 0.9 (which was my assumption). httpd-2.0, yes. Not apr. I'm not sure how important for us to have a complete APR:: glue (at least for functions that could be useful for perl users) asap. I'm fine with not having this as a priority as a moment, only spending time on APR:: APIs which are really useful in the mod_perl context. Until someone will start using APR:: outside mod_perl and then they hopefully will lead the effort to add/fix missing/broken things in APR::. In any case should we log that somewhere in todo lists till someone asks for it and we don't have to try to recall why it's not there? it's pretty obvious why it's not there if you look at the maps, which I tend to do all the time now. but if you want to log it that's fine. Hmm, how is it obvious if you have removed those functions from the map file, instead of marking them as disabled? I'm sure the map files miss quite a few of the C functions, so you can't just say that if it's not in the map file it's because it's disabled. As a C user wanting to use a function apr_sockaddr_port_get in Perl, I'll grep the mp2 source for it and won't find it mentioned anywhere... well, I'll in Changes... It'd be also nice to add explanations in the map file, why certain functions are marked with '!'. Perhaps ask Doug? you can if you like :) what I meant is that since you said you're going to check why that function is '!' once you figure out, cache that info in the comment so that we don't have to repeat that process in the future. Just like with C function API docs, we don't have the resources to go and them to all functions, but adding them as we write new functions or after spending some time trying to wrap our head around to understand what an existing function does, is a doable thing. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] mod_perl test suite fails
[Volker has sent me the long output offline, so I'm just quoting the
interesting parts here]
I also want to see the console messages (not error_log) when you run
from under /root/mod_perl-1.99_11/ as you did it in first place.
> ulimit -c unlimited; t/TEST -bugreport -verbose=0
> *** root mode: changing the files ownership to 'nobody' (99:99)
> *** /usr/bin/perl -e ' require POSIX; POSIX::setuid(99);
> POSIX::setgid(99); print -r q{/root/mod_perl-1.99_11/t} && -w _ &&
> -x _ ? q{OK} : q{NOK}; '
>
> *** result: OK
That explains the problem. My test to check whether user 'nobody' will be able
to access files under /root seems to pass, but when Apache starts as nobody it
doesn't.
Can you please show us the perms of your /root directory? e.g. on my machine it's:
drwx-- 43 root root 4096 Dec 8 14:31 root
I also want to see:
% grep nobody /etc/passwd
May be POSIX::setuid(99) fails? Does running the following as root:
% /usr/bin/perl -le 'require POSIX; POSIX::setuid(99); POSIX::setgid(99); \
print -r q{/root} && -w _ && -x _ ? q{OK} : q{NOK}; '
gives you:
OK?
If it does, the following will probably fail too:
perl -le 'require POSIX; POSIX::setuid(99) or die "failed to run: $@";'
and this?
% /usr/bin/perl -le 'require POSIX; \
POSIX::setuid(99) or die "NOK"; \
POSIX::setgid(99) or die "NOK"; \
print -r q{/root} && -w _ && -x _ ? q{OK} : q{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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
