[jira] Created: (MODPYTHON-56) Error 404 importing module from the same folder
Error 404 importing module from the same folder --- Key: MODPYTHON-56 URL: http://issues.apache.org/jira/browse/MODPYTHON-56 Project: mod_python Type: Bug Versions: 3.1.3, 3.1.4 Environment: Red Hat 9 + Apache 2.0.48 Debian Sarge + Apache 2.0.54 Reporter: Humberto Diogenes Using the Publisher handler, if I try to import a module from the same directory as the script, I _sometimes_ get an Object Not Found - Error 404 message. It was tricky the discover that the solution was just to append the directory to PythonPath because of two problems: 1- Sometimes it just worked! You just reloaded the page and it opened. And then you reload it again and get a 404... 2- ModPython didn't issue _any_ error or warning about this anywhere. It just logged the usual (re)importing module -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-56) Error 404 importing module from the same folder
[ http://issues.apache.org/jira/browse/MODPYTHON-56?page=comments#action_66430 ] Graham Dumpleton commented on MODPYTHON-56: --- Might be the same problem as MODPYTHON-9. More information is required about the names of actual files and whether the same named file is used in multiple directories. Specific instructions on how to duplicate it, like as described for MODPYTHON-9 would be required to investigate it further. Error 404 importing module from the same folder --- Key: MODPYTHON-56 URL: http://issues.apache.org/jira/browse/MODPYTHON-56 Project: mod_python Type: Bug Versions: 3.1.3, 3.1.4 Environment: Red Hat 9 + Apache 2.0.48 Debian Sarge + Apache 2.0.54 Reporter: Humberto Diogenes Using the Publisher handler, if I try to import a module from the same directory as the script, I _sometimes_ get an Object Not Found - Error 404 message. It was tricky the discover that the solution was just to append the directory to PythonPath because of two problems: 1- Sometimes it just worked! You just reloaded the page and it opened. And then you reload it again and get a 404... 2- ModPython didn't issue _any_ error or warning about this anywhere. It just logged the usual (re)importing module -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Namespace confusion
Installed: Apache2::Request Apache2::Cookie Apache2::Upload APR::Request APR::Request::Cookie In a recent posting: ...the APR::* classes will be the ones we recommend nowadays. We debated whether to chuck the Apache2::* classes entirely, but we left them in for back-compat reasons. Now: I'm at a loss Should I be using the APR::Request / APR::Request::Cookie methods instead of Apache2 ? If so, why no APR::Request::Upload?
Re: [PATCH] stop killing piped loggers
On 5/20/05, Joe Orton [EMAIL PROTECTED] wrote: On Fri, May 20, 2005 at 07:50:04AM -0400, Jeff Trawick wrote: On 5/20/05, Joe Orton [EMAIL PROTECTED] wrote: As discussed previously; this patch stops killing piped loggers; except that prefork still kills them at shutdown and ungraceful restart since it signals the entire process group, so it's not entirely consistent. Something I'd like to confirm: If the httpd code remains the same: a) all existing piped loggers continue to work with all levels of Apache b) a piped logger which wants to stay alive long enough to read until eof can simply ignore SIGTERM (or better yet, use SIGTERM to set some kind of alarm/timeout so that it doesn't stay around forever if it never reaches eof due to some httpd or application misbehavior) Yes, I believe that's true. I think it would be pretty unreasonable to require that piped loggers are changed to ignore SIGTERM to fix this, simply because httpd sends SIGTERM at the wrong time. Deliberately ignoring SIGTERM is not something you'd generally advocate at all. (btw: I checked cronolog again and it actually does just exit() on eof; don't know what I was thinking of which didn't) makes sense
Re: Multiple AAA providers
Is there any remaining/ongoing interest in this development area? The need to authenticate a single resource against multiple disparate (non-failover/non-redundant) LDAP servers looms large and I'd like to think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] -- Jess Holle
Re: Multiple AAA providers
Jess Holle wrote: Is there any remaining/ongoing interest in this development area? The need to authenticate a single resource against multiple disparate (non-failover/non-redundant) LDAP servers looms large and I'd like to think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] I have a JAAS LoginModule which I wrote for Jetty that does exactly this (if I understand what you mean, that is :). At work, I have our website authentication first checking OpenLDAP, then falling back to Win2k Active Directory. I want to be able to do the same from Apache, and am pretty tempted to start coding up a module to do it. -- Russell Howe [EMAIL PROTECTED] Today's Nemi: http://www.metro.co.uk/img/pix/nemi_may27.jpg smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple AAA providers
Russell Howe wrote: Jess Holle wrote: Is there any remaining/ongoing interest in this development area? The need to authenticate a single resource against multiple disparate (non-failover/non-redundant) LDAP servers looms large and I'd like to think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] I have a JAAS LoginModule which I wrote for Jetty that does exactly this (if I understand what you mean, that is :). At work, I have our website authentication first checking OpenLDAP, then falling back to Win2k Active Directory. In our case it does not depend which is checked first (except perhaps for performance) as there will not be any overlap between the directories. For instance, one LDAP might be for corporation X and another for one of their partners. Another example: one might be a read-only corporate directory and another might be an application writable directory (for pseudo-users, guest accounts, etc). [By disparate/non-failover/non-redundant, I mean that each LDAP would be checked for a given user until that user entry was found (at which point no other LDAPs would be checked for the given user regardless of the success/failure of the bind). This differs from strictly failover LDAPs wherein Apache keeps trying to contact LDAP URLs until it finds one that responds (is up) and then just uses that one as "the" LDAP -- we have that now but it does not help in these use cases.] I want to be able to do the same from Apache, and am pretty tempted to start coding up a module to do it. There was discussion some time back (under the same title as this thread) about doing this in a somewhat general fashion so one could have multiple LDAP providers, multiple password file providers, etc... That would be a great grand unified theory (and I see it as useful) but what I care most about is multiple LDAPs. If we could just have the existing mod_auth_ldap handle multiple LDAPs (beyond in a strict failover capacity) that would be *huge*. If we can't get the grand unified approach, I'd at least like to see multiple LDAP handling. -- Jess Holle
Re: Multiple AAA providers
On 27-May-05, at 10:53 AM, Jess Holle wrote: Russell Howe wrote:Jess Holle wrote: Is there any remaining/ongoing interest in this development area? The need to authenticate a single resource against multiple disparate (non-failover/non-redundant) LDAP servers looms large and I'd like to think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] I have a JAAS LoginModule which I wrote for Jetty that does exactly this (if I understand what you mean, that is :). At work, I have our website authentication first checking OpenLDAP, then falling back to Win2k Active Directory. [By disparate/non-failover/non-redundant, I mean that each LDAP would be checked for a given user until that user entry was found (at which point no other LDAPs would be checked for the given user regardless of the success/failure of the bind). This differs from strictly failover LDAPs wherein Apache keeps trying to contact LDAP URLs until it finds one that responds (is up) and then just uses that one as the LDAP -- we have that now but it does not help in these use cases.] I want to be able to do the same from Apache, and am pretty tempted to start coding up a module to do it. That would be a great grand unified theory (and I see it as useful) but what I care most about is multiple LDAPs. If we could just have the existing mod_auth_ldap handle multiple LDAPs (beyond in a strict failover capacity) that would be *huge*. If we can't get the grand unified approach, I'd at least like to see multiple LDAP handling. I'm very interested in implementing this myself. To make what I'm doing more generally useful, I'd like to know what people expect from the implementation of Require after a multiple LDAP search. Should you be able to put the ldap server name in a Require? Or are you only concerned with require valid-user?
Re: Multiple AAA providers
Jess Holle wrote: In our case it does not depend which is checked first (except perhaps for performance) as there will not be any overlap between the directories. For instance, one LDAP might be for corporation X and another for one of their partners. Another example: one might be a read-only corporate directory and another might be an application writable directory (for pseudo-users, guest accounts, etc). Same for me here. We actually have a mixture - ldap search for collective accounts shared by groups of people (these will go, given time), LDAP search on an OpenLDAP server (hopefully a redundant pair) and an LDAP search on the Win2k domain controllers (two of them, if one's not available, fall back to the other). JAAS does all the hard work for me in Java though, as regards trying multiple authentication modules. Apparently they copied the configuration scheme from PAM, or at least tried to make it PAM-like. There was discussion some time back (under the same title as this thread) about doing this in a somewhat general fashion so one could have multiple LDAP providers, multiple password file providers, etc... That would be a great grand unified theory (and I see it as useful) but what I care most about is multiple LDAPs. If we could just have the existing mod_auth_ldap handle multiple LDAPs (beyond in a strict failover capacity) that would be *huge*. If we can't get the grand unified approach, I'd at least like to see multiple LDAP handling. Ah, I see what you mean - it would appear that while you can chain authentication methods, they have to be different methods, taking different options. Am I getting that right? If so, I can't readily port my Java authentication scheme to Apache :/ Here is my latest posting to jetty-discuss, talking about the LoginModule. Hopefully it is enough to give a rough idea of what it does. http://news.gmane.org/navbar.php?group=gmane.comp.java.jetty.generalarticle=5749next=5750prev=5756newsrc=,5749-5750,5763 -- Russell Howe [EMAIL PROTECTED] Today's Nemi: http://www.metro.co.uk/img/pix/nemi_may27.jpg smime.p7s Description: S/MIME Cryptographic Signature
Re: Multiple AAA providers
Brad Nicholes wrote: It done and checked into 2.2. I posted several messages to this mailing list last week and this week. There is a new module called mod_auth_alias that allows you to create alias providers giving you the ability to to create alternate providers to different ldap servers that will be called during a single authentication request. Check out http://httpd.apache.org/docs-2.1/mod/mod_authn_alias.html Cool. I'll have to check this out! [I don't know how I missed this!] -- Jess Holle [EMAIL PROTECTED] Friday, May 27, 2005 9:22:52 AM Is there any remaining/ongoing interest in this development area? The need to authenticate a single resource against multiple disparate (non-failover/non-redundant) LDAP servers looms large and I'd like to think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] -- Jess Holle
Re: Multiple AAA providers
It done and checked into 2.2. I posted several messages to this mailing list last week and this week. There is a new module called mod_auth_alias that allows you to create alias providers giving you the ability to to create alternate providers to different ldap servers that will be called during a single authentication request. Check out http://httpd.apache.org/docs-2.1/mod/mod_authn_alias.html Brad [EMAIL PROTECTED] Friday, May 27, 2005 9:22:52 AM Is there any remaining/ongoing interest in this development area? The need to authenticate a single resource against multiple disparate (non-failover/non-redundant) LDAP servers looms large and I'd like to think that this would be part of Apache 2.2 soon... [I'd rather not have to hack this in in a narrow, special-cased, hackish way myself...] -- Jess Holle
ANN: Linux TestFest
Love Linux? Love TESTING on Linux? We're SpikeSource, a bunch of passionate open source testing folks, and we're holding our first-ever TestFest on June 17th. We'll give you the chance to show how good your code really is by testing it using our new 'test harness'. We run 22,000 tests per day on over 63 open source components using this harness. This event kicks off our free testing service for the open source community. Mix and mingle with our developers to chat about open source testing. Hear from SpikeSource founder CTO Murugan Pal on Participatory Testing and our architect, Sastry Malladi, about our Core stack product. Testing demonstrations on popular open source software will also be held for attendees. All developers are welcome! Check us out at www.spikesource.com/testfest.html, where you can register and learn how to package and test your code. On June 17th, 3pm, head over to SpikeSource offices in Redwood City to receive a report on your test results with helpful feedback from our staff. Lots of free food beer to go around. Heck, we're even hiring. Should be a real geek fest! We hope to see you there. -- Surendra Singhi http://www.public.asu.edu/~sksinghi
Re: Problem with -path in Apache2::Cookie?
Just to add onto the issue below:
my $cookie = Apache2::Cookie-new($r, -path = $mypath...)
I experienced something similar -- domain and path both were set to
what i specified for path
I tried a workaround for domain, and ended up having the path set to
the expiration argument ('+365'), while expiration was set to the
expiration date ('Sun, 28-May-2006 04:54:37 GMT')
specifiying the domain and path, re: the workaround, fixes it all up
Mac OSX 10.3.9
libapreq whatever is current.tgz on May 28
apache 2.0.5.4
modperl whatever is current.bz2 on May 28
perl 5.8.1 (stock osx)
On May 13, 2005, at 1:05 AM, Joe Schaefer wrote:
Fred Moyer [EMAIL PROTECTED] writes:
[cc'ing the apreq-dev@httpd.apache.org list]
Pete Houston wrote:
Yes, I found exactly the same behaviour yesterday, and it did affect
Firefox too. I used the same workaround which seems to work in all
the
scenarios I tested.
So it sounds like this is an issue with dev_2.05. I'll dig into it
if I
get a chance, but this is probably a no-brainer for someone
experienced
with the codebase.
Problem ack'd; I've no clue why this happens tho. Must be some
XS-related bug. I'll add a new test to trunk which tickles it,
so others can whittle away as well.
--
Joe Schaefer
