Re: Few issues with new mod_python.publisher.
Jim Gallacher wrote: Interestingly, section 5.1.1 says that The methods GET and HEAD MUST be supported by all general-purpose servers., so it would seem that mod_python has not been compliant to the RFC. FWIW, the Debian Woody package of mod_python (libapache-mod-python 2.7.8-0.0woody5) running under apache 1.3.26 displays HEAD properly, while a compiled mod_python 3.1.4/apache 2.1.3-beta system does not. Perhaps mod_python underwent a change or Debian already includes a patch for HEAD.
Re: mod_python package maintainers - are you out there?
Juha-Matti Tapio wrote: On Wed, Aug 10, 2005 at 09:04:04AM -0400, Jim Gallacher wrote: Nicolas Lehuen wrote: Having some contact with them directly is probably a good idea anyway. Subscribing to a bunch of mailing lists could result in a lot of uninteresting mail. ;) I think it would be unfair to expect that upstream developers track all the major distributions. But it's easy enough to download their source packages and inspect them for interesting patches every once in a while. I think package maintainers will respond favorably if their work was acknowledged. Maybe they tried to submit a bug in the past, but couldn't, for some reason.
Re: mod_python 3.2.1b available for testing
Nicolas Lehuen wrote: Hi, Could we focus on Apache 2.0 for the 3.2 release ? Put 2.1 on the agenda for a later release (why not 3.3 ?). For the moment I don't see any quick and easy way to support both 2.0 and 2.1, from what you wrote. I'd rather we try to get 3.2 out with a proper 2.0 support, and try to fix things for 2.1 when it goes at least beta. Sorry, the socket errors were a side effect of the build environment I used. New results: +1 Slackware Linux 10.1 gcc version 3.3.4 Python 2.4.1 Apache 2.0.54 +1 (if patched) Slackware Linux 10.1 gcc version 3.3.4 Python 2.4.1 Apache 2.1.6 Alpha Patches for Apache 2.1.x: Remove APR_STATUS_IS_SUCCESS references in: src/filterobject.c src/connobject.c Change in test.py: /mod_auth/mod_auth_basic/ /auth_module/auth_basic_module/ I don't expect any immediate changes for apache 2.1.x, but I thought it might be helpful to document these issues, since fixing them will be inevitable. :)
Re: mod_python 3.2.2b available for testing
+1 (slightly patched for Apache 2.1.x) Slackware Linux 10.1 gcc version 3.3.4 Python 2.4.1 Apache 2.1.6 Alpha Jim Gallacher wrote: A new mod_python 3.2.2 beta tarball is now available for testing. Hopefully this will be the last beta before the official 3.2 release. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher
Re: glue between apache and python logging
Where do I file a documentation bug? Rule #6 appears to be missing. ;) Sydney Nolan Nick wrote: In that case, let us just apply Rule #6 to this situation. Bruce Jim Gallacher wrote: Well, this is python, so everyone really should be called Bruce. Maybe that will help. Regards, Bruce
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote:
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close',
'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name',
'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
python 2.4.1 on windows:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x0099FBA8
type(t)
type 'instance'
dir(t)
['__doc__', '__getattr__', '__init__', '__module__', '__repr__',
'close_called', 'file', 'name']
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
I think we should correct it. I'm sure users don't care that we
implement this with TemporaryFile. That being said, I wonder how many
applications on Windows we may break by fixing this? Version 3.1.4 also
used TemporaryFile, so this is not a new bug.
Are you sure there is anything to correct? In both cases, the object has
the same methods available for manipulating files (t.write('a'), for
example). They are not the same type of object, so they have different
dir() output, but don't they have the same functionality? What
specifically gets broken in util.FieldStorage?
Re: Various musings about the request URL / URI / whatever
Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: I don't know what the specific issue is with parsed_uri, if this is a mod_python bug it should just be fixed BUT if this is an issue with httpd, I don't think we should cover the problem up by having mod_python fix it. Since we are part of the HTTP Server project, we should just fix it in httpd. Either way, it should be fixed. I think maybe it's not really broken. In case anyone is not familiar with the issue, a request for http://example.com/tests/mptest?view=form currently gives a tuple that looks something like this: That's not true. That's what you might see in your client browser, but (usually) it only asks for /tests/mptest?view=form, regardless of the name it used to find the server. It may use the Host: header to negotiate the right virtual host, but the Host: header is not part of the string that parsed_uri is actually parsing. (None, None, None, None, None, None, '/tests/mptest', 'view=form', None) which is not what we expect. This is what the mod_python docs have to say: parsed_uri Tuple. The URI broken down into pieces. (scheme, hostinfo, user, password, hostname, port, path, query, fragment). The apache module defines a set of URI_* constants that should be used to access elements of this tuple. Example: fname = req.parsed_uri[apache.URI_PATH] (Read-Only) This is all correct. I think the problem is that developers are hoping to use parsed_uri in a use case for which it is inappropriate. Those values are populated *if present* in the supplied request URI, but the only *minimal* requirement would be a / for the path. If you want to know what resource the client *really* requested (and inquiring minds do), you *must not* attempt to rewrite or repopulate this.
Re: Apache 2.2 released - apparently breaks the mod API compatibility with 2.0
Nicolas Lehuen wrote: Is there a wait to use macro directives so that we don't need to maintain two separate branches ? A define that we could pass when building mod_python to select the Apache version we're building against, maybe ? If it's possible to make the code in connobject.c filterobject.c compatible with both Apache 2.0 2.2, then the only unavoidable incompatibility is in test.py (with the auth stuff). Since that script already calls httpd, it could discover the version with httpd -v (unless mod_python has an internal record of this, already) and adapt accordingly. These diffs were really tiny to get a seemingly working version to run with Apache 2.2. Finding compatible alternatives to the deprecated items will deliver better results than version sniffing, IMHO. I just wish I was bright enough to comprehend what the lines in question actually do. :P
Re: input/output filters and .htaccess
Graham Dumpleton wrote: Anyone know if there are any technical reasons why input/output filters as they exist at the moment, applying only to body content and not headers, can not be specified in a .htaccess files? Specifically, the SetInputFilter, SetOutputFilter, AddInputFilter and AddOutputFilter directives of Apache can be specified in either main server configuration or .htaccess files, yet the PythonInputFilter and PythonOutputFilter directives are only allowed to be specified in the main server configuration. This is because mod_python.c contains: AP_INIT_TAKE12( PythonInputFilter, directive_PythonInputFilter, NULL, RSRC_CONF|ACCESS_CONF, Python input filter.), AP_INIT_TAKE12( PythonOutputFilter, directive_PythonOutputFilter, NULL, RSRC_CONF|ACCESS_CONF, Python output filter.), If however I change it to: AP_INIT_TAKE12( PythonInputFilter, directive_PythonInputFilter, NULL, OR_ALL, Python input filter.), AP_INIT_TAKE12( PythonOutputFilter, directive_PythonOutputFilter, NULL, OR_ALL, Python output filter.), it is then possible to use the mod_python directives in a .htaccess file. Running the code this way appears to work for both input and output filters when specified in the .htaccess file without problems. So, does anyone know why this might be a bad idea? I can't really think of any reasons why it shouldn't be okay. If there is some confirmation that it all sounds reasonable, I'll create a JIRA issue for it to be a future enhancement. Are there any conflicts when a directive appears in both places? If not, how do they cascade (does the .htaccess trump the one in the conf file, is it additive, does it respect virtual host or directory boundaries, etc...)?
Re: mod_python 3.2.6b available for testing
+1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 Jim Gallacher wrote: $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py What are the chances of enhancing the procedure as follows: $ ./configure --with-apxs=/wherever/it/is $ make $ make test $ (su) # make install Doesn't it make more sense to run tests before installing? Do we have everything necessary to run the tests after make? I'll assume this will require some path manipulation, but I'd rather see and fix errors before installing to the system.
Re: mod_python 3.2.6 testing on debian/colinux
Mike Looijmans wrote: Since I have a CoLinux instance on my machine here, I wanted to give it a go with mod_python as well (need a linux test environment for mod_python anyway). It's running a Debian distro, I have gcc-3.3 on it, as well as apache2-dev and python-dev (version 2.3). Can't get the tests to run though, even though Apache itself appears to run okay (I can get the manual pages from it). Here's an example session (running as root, also tried normal user): colinux:/home/mike/mod_python/test# python test.py If you compiled it as mike, you need to run the tests as mike, not root.
Re: please set up a mod_python core group
Roy T. Fielding wrote: It looks like mod_python is making good progress and everyone is collaborating in the Apache way of testing and voting. That's great! Unfortunately, I have almost no insight into who these great people are that are doing the RM task and testing and voting and preparing for a next release. That's not so great, since it is my job (as VP of Apache HTTP Server Project) to be sure that the ASF knows all this work is being done in its name and so that all of the people doing it are appropriately recognized for their work. So, please, take a few moments to decide amongst yourselves who should have binding votes on mod_python (i.e., who has earned it), keeping in mind that you need at least three binding +1 votes in order to make any release at Apache, and send me a list of names and email addresses of those people so that I can properly record them in our records. I vote that Grisha gets all three votes. Benevolent dictatorship is the Python way, after all.
Re: please set up a mod_python core group
Jim Gallacher wrote: Jorey Bump wrote: IOW, could you guys list the OS on which you run, and not merely test, mod_python? By you guys I assume you mean the above 4 people? Yeah, youse 4 guys. :) On the other hand, you may mean *all* the people on python-dev who test a release candidate should list their production platform. This would be useful to the core group as another data point in deciding on casting a binding vote to proceed to release. No, I'm just interested in the core group. Everyone else gets an opportunity to list platforms when testing new releases, in pass/fail feedback responses. Your point on making sure we don't overlook any key platforms in our testing is a good one. Should we (python-dev people) put together a list of key platforms as a future guide? It's likely a good idea, even at the risk of a flamewar. ;) I thought I'd put together a summary of 3.2.6 test results in the next few days anyway, which should be a good starting point for the key list. A small checklist might be useful, such as Windows/Mac/Linux/UNIX/BSD. This has been handled fairly well in the past, but that might be due to luck. I'm concerned that some last minute fix will be checked into a stable release candidate without sufficient cross-platform testing. I mainly use Python in UNIX-like environments, and I forget how popular it is on Windows (the same goes for Apache). Ideally, it would be nice to solicit feedback from package maintainers. I use Slackware, which doesn't include Apache 2 or mod_python, so I can tell immediately how it's going to perform in my production systems. Users of stock Red Hat, Debian, SUSE, Mandriva, FreeBSD, Mac, etc. can't be so sure. The package maintainers are in the best position to flag potential problems. But this is an issue shared by many open source projects, and we'll need to be satisfied with the participation we get, and try our best to create a stable release.
Re: [jira] Created: (MODPYTHON-120) Connection handler test fails on virtual hosting system such as OpenVPS.
Graham Dumpleton (JIRA) wrote: On a virtual hosting environment such as OpenVPS, localhost does not map to the IP address 127.0.0.1 but the actual IP of the host. import socket socket.gethostbyname(localhost) '207.126.122.36' This fact causes the connection handler test to fail because it sets up the virtual host listener definition as something like: Listen 59180 VirtualHost 127.0.0.1:59180 SetHandler mod_python PythonPath [r'/home/grahamd/mod_python-3.2.7/test/htdocs']+sys.path PythonConnectionHandler tests::connectionhandler /VirtualHost In this case it really needs to be: Listen 59180 VirtualHost 207.126.122.36:59180 SetHandler mod_python PythonPath [r'/home/grahamd/mod_python-3.2.7/test/htdocs']+sys.path PythonConnectionHandler tests::connectionhandler /VirtualHost I'd never do it in production, but, for testing purposes, wouldn't it be easier to use localhost directly? Listen 59180 VirtualHost localhost:59180 SetHandler mod_python PythonPath [r'/home/grahamd/mod_python-3.2.7/test/htdocs']+sys.path PythonConnectionHandler tests::connectionhandler /VirtualHost This should be portable across platforms.
Re: site.
Jim Gallacher wrote: The generated output can be found at http://people.apache.org/~jgallacher/mod_python/website-test. The only links that you should really trust are under the Get Involved meun heading. There is likely all sorts of incorrect or missing content. This is only intended as a rough demonstration. If we decide this is the route we want to take I'll commit the files to my svn sandbox and we can get to work on the content. The mod_python site never bothered me until I saw this. Good work, Jim! The easy access to JIRA is definitely welcome.
Re: [DRAFT] [ANNOUNCE] Mod_python 3.2.8 (security)
Gregory (Grisha) Trubetskoy wrote: If you see any problems with this text, let me know. -- Forwarded message -- Date: Sat, 12 Feb 2005 22:00:56 -0500 (EST) From: Gregory (Grisha) Trubetskoy [EMAIL PROTECTED] To: announce@httpd.apache.org, [EMAIL PROTECTED] Cc: python-dev@httpd.apache.org Subject: [ANNOUNCE] Mod_python 3.2.8 (security) The Apache Software Foundation and The Apache HTTP Server Project are pleased to announce the release of versions 3.2.8 of mod_python. versions - version This release addresses a vulnerability in mod_python's FileSession object whereby a carefully crafted session cookie could potentially permit an attacker to execute code on the server. FileSession was introduced in mod_python 3.2.7 released on February 15 2006 and is not enabled by default, therefore only a very small number of installations, if any, are likely to be affected by this issue. There are no other changes or improvements from the previous version in this release. Mod_python is available for download from: http://httpd.apache.org/modules/python-download.cgi For more information about mod_python visit http://www.modpython.org/ Regards, Gregory Trubetskoy
Re: Vote on whether to integrate server side include (SSI) support.
+1
Graham Dumpleton wrote:
I have had patches for adding server side include support into
mod_python ready for a while now. See:
https://issues.apache.org/jira/browse/MODPYTHON-104
In short, it would add the ability to add Python code into files
being served up through the INCLUDES output filter. More
commonly this is known as server side include (SSI). For example:
!--#python exec=
from mod_python import apache
import cgi
import sys
parts = apache.import_module('parts')
def _escape(object):
return cgi.escape(str(object))
--
html
body
pre
!--#python eval=_escape(str(globals().keys()))--
!--#python eval=_escape(str(locals().keys()))--
!--#python exec=
print filter
for key in filter.req.subprocess_env:
print filter, _escape((key, filter.req.subprocess_env[key]))
--
!--#python eval=parts.content()--
/pre
/body
/html
One could say that there is an overlap between this and the
mod_python.psp handler, but the SSI feature is a builtin feature of
Apache and it make sense to support it. Using SSI, if one was mad
enough, you could even have Python and Perl code appearing in the one
file.
Anyway, the point of this email is to get a decision on whether this
major new feature should or should not be added into mod_python.
Core developer votes obviously matter the most, but others are more
than welcome to voice an opinion.
So, is it a Yes or a No?
Graham
Re: mod_python 3.3.0-dev-20060321 available for testing
-1 Slackware 10.1, Apache 2.2.0 (mpm-prefork), Python 2.4
My applications are working, but make check produces these errors:
==
FAIL: test_req_auth_type (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File test.py, line 673, in test_req_auth_type
self.fail(`rsp`)
AssertionError: '!DOCTYPE HTML PUBLIC -//IETF//DTD HTML
2.0//EN\nhtmlhead\ntitle500 Internal Server
Error/title\n/headbody\nh1Internal Server Error/h1\npThe
server encountered an internal error or\nmisconfiguration and was unable
to complete\nyour request./p\npPlease contact the server
administrator,\n [no address given] and inform them of the time the
error occurred,\nand anything you might have done that may have\ncaused
the error./p\npMore information about this error may be
available\nin the server error log./p\n/body/html\n'
--
Ran 60 tests in 231.452s
FAILED (failures=1)
F Stopping Apache...
/usr/local/apache2/bin/httpd -k stop -f
/home/jorey/src/mod_python-3.3.0-dev-20060321/test/conf/test.conf
==
FAIL: testPerRequestTests (__main__.PerInstanceTestCase)
--
Traceback (most recent call last):
File test.py, line 2467, in testPerRequestTests
self.failUnless(result.wasSuccessful())
AssertionError
--
Jim Gallacher wrote:
mod_python-3.3.0-dev-20060321 is available for testing.
We are asking the mod_python development community for assistance in
testing the current development branch. Hopefully this will allow us to
catch new bugs or regressions early, and when we are ready for the next
release the beta cycle will be much shorter.
This snapshot addresses 33 issues since 3.2.7 was released, including
apache 2.2 support and the introduction of a new module importer.
The files are (temporarily) available here:
http://people.apache.org/~jgallacher/mod_python/dist/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ make check
or if you prefer to run the tests the old way:
$ cd test
$ python test.py
Make a note of any failing tests.
If all the tests pass, give the new module importer a workout by
uncommenting line 328 in test/test.py:
#PythonOption('mod_python.future.importer *'),
and then re-run the tests.
$ make check
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
Re: [jira] Created: (MODPYTHON-169) Add feature to allow mod_python to be an auth provider.
+1
But I think any example functions in the documentation should return
apache.AUTH_DENIED by default, with the conditionals checking for
success, not failure:
def authbasicprovider(req, user, password):
if user in users:
if users[user] == password:
return apache.AUTH_GRANTED
else:
return apache.AUTH_USER_NOT_FOUND
return apache.AUTH_DENIED
Graham Dumpleton (JIRA) wrote:
Add feature to allow mod_python to be an auth provider.
---
Key: MODPYTHON-169
URL: http://issues.apache.org/jira/browse/MODPYTHON-169
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assigned to: Graham Dumpleton
In Apache 2.2, the implementation of authentication has been split into two
parts. The first is that which handles the specifics of negotiating with a
client for a specific authentication mechanism type, for example, Basic or
Digest authentication. The second part is that which handles the specifics of
verifying the actual users credentials, for example, by looking the user up in
a dbm database, ldap or some other type of user database.
The second part of this is referred to as the auth provider and in Apache 2.2
it is possible to hook in additional providers. This means that the any builtin
support in Apache for Basic and Digest authentication mechanism can be used,
but the verification could be done by some arbitrary user code. Such
verification could be done in Python, if mod_python allowed one to define the
necessary auth provider hooks.
To this end, proposed that mod_python be extended such that when using Apache
2.2, that it is possible to say:
AuthType Basic
AuthName Restricted Files
AuthBasicProvider mod_python
PythonAuthBasicProvider somemodule
or:
AuthType Digest
AuthName Restricted Files
AuthDigestProvider mod_python
PythonAuthDigestProvider somemodule
That is, by specifying mod_python in conjunction with AuthBasicProvider or
AuthDigestProvider directives, it triggers mod_python to be given option of
satisfying need to perform verification of user credentials. The function to be
called for each being given by the PythonAuthBasicProvider and
PythonAuthDigestProvider respectively.
The argument to these directives would be a module name, in which case a function of the name
authbasicprovider or authdigestprovider will be expected to exist. If
wanting to specify a particular module, like in handler directives, would also be possible to say:
PythonAuthBasicProvider somemodule::check_password
PythonAuthDigestProvider somemodule::get_realm_hash
Note that the prototype of the function for each would not be like existing
handlers and is different in each case. For the Basic auth mechanism, an
example function would be:
users = { ... }
def authbasicprovider(req, user, password):
# could consult req.auth_name() to get realm
if user not in users:
return apache.AUTH_USER_NOT_FOUND
# assuming passwords are stored in clear text
if users[user] != password:
return apache.AUTH_DENIED
return apache.AUTH_GRANTED
Exceptions would be translated into apache.AUTH_GENERAL_ERROR, or function
could explicitly return it. Could also allow explicit exception of type
apache.SERVER_RETURN like in handlers but where argument is auth values.
For Digest authentication, function would be:
def authdigestprovider(req, user, realm):
# could select database based on 'realm'
if user not in users:
return None
# assuming passwords are stored in clear text
return md5.new(%s:%s:%s % (user, realm, users[user])).hexdigest()
In this later function, return None indicates apache.AUTH_USER_NOT_FOUND. An
apache.SERVER_RETURN exception could also be used with that value as argument.
Returning of an actual string would imply apache.AUTH_USER_FOUND. Unexpected
exceptions taken as apache.AUTH_GENERAL_ERROR, or could be raised explicitly
using apache.SERVER_RETURN exception.
What all this would mean is that you would never need to write an authenhandler
again using mod_python, as you could rely on any type of authenhandler builtin
to Apache or as as supported by some third party Apache module. All you would
need to do is supply the auth provider or Basic or Digest authentication as
necessary to support verification of the user.
Re: mod_python 3.2.9-rc3 available for testing
+1 Linux Slackware 10.1, Apache 2.0.55, Python 2.4.1 +1 Linux Slackware 10.2, Apache 2.2.0, Python 2.4.1 +1 Linux Zenwalk 2.6, Apache 2.2.2, Python 2.4.3 Jim Gallacher wrote: The mod_python 3.2.9-rc3 tarball is available for testing. This release adds support for apache 2.2 as well as some other useful backports from the development branch. For information on the changes from 3.2.8 take a look at doc-html/node98.html in the tarball. The only difference from 3.2.9-rc2 is that the FieldStorage modifications (MODPYTHON-93) that were causing problems for some applications such as Trac have been reverted. FieldStorage behaviour should now be the same as in 3.2.8. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://people.apache.org/~jgallacher/mod_python/dist/ http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.2.9-rc3.tgz http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.2.9-rc3.tgz.md5 Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). If this tarball looks good, I'll tag it svn and create a 3.2.9 final tarball. Thank you for your assistance, Jim Gallacher
Re: mod_python 3.2.9-rc2 available for testing
Jim Gallacher wrote: Mike Looijmans wrote: I think this surprised many of us, as no one on the list seems to have thought of that use case. Trac subclasses FieldStorage to get behaviour more in line with cgi.py. We don't have any prohibitions on subclassing, so although we didn't foresee this usage I think it is still legitimate. I don't have a clue what the trac software is, but I imagine that even for this particular piece of software, I may be able to come up with some form of emulation (e.g. using __setattr__ hooks) that still keeps it working with the patch. The question is of course, where does it stop? Trac is bugtracker / wiki that seems to be getting some traction. ;) It's also a frontend to subversion (and other version control systems, using plugins), which I think is responsible for its explosive popularity. It may well become the premier application using (but not exclusively dependent on) mod_python. I haven't used it (I'm waiting for a stable darcs plugin), but you can get an idea of its features here: http://projects.edgewall.com/trac/ This definitely a project we don't want to break. If I get a chance I'll try to set up a test bed to make sure future release candidates are compatible. Do we have any trac developers on this list?
Re: mod_python 3.2.9-rc3 test results
Jim Gallacher wrote: Graham Dumpleton wrote: On 29/06/2006, at 9:29 PM, Jim Gallacher wrote: +1 Linux Slackware 10.1, Apache 2.0.55, Python 2.4.1 +1 Linux Slackware 10.2, Apache 2.2.0, Python 2.4.1 +1 Linux Zenwalk 2.6, Apache 2.2.2, Python 2.4.3 These 3 were all prefork. In respect of testing in the future, can everyone make a note though which MPM, ie., worker or prefork , they are using when testing on UNIX like system. I would feel much more comfortable if I know there is a mix of prefork and worker across the range of UNIX like systems. Good point. In the future when I send an email to the list requesting a round of testing I'll include a reminder. Jim
Re: release 3.2.10?
Gregory (Grisha) Trubetskoy wrote: (we'll just have to make a 3.2.11 then). Let's call that one the Spinal Tap version. :)
Re: mod_python 3.2.10 available for testing
+1 Linux Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4.1 Jim Gallacher wrote: The mod_python 3.2.10 tarball is available for testing. Part way through the release process for 3.2.9 a fix was found for several memory leaks (MODPYTHON-172). We've decided to skip the official 3.2.9 release and proceed directly to 3.2.10, which is the same as 3.2.9 but with the leak fixes back-ported from trunk. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://people.apache.org/~jgallacher/mod_python/dist/ http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.2.10.tgz http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.2.10.tgz.md5 Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Apache, Apache-mpm, Python, the test output, and suggestions, if any). Please present your test results in the following format: +1 OS version, Apache version (apache mpm), Python Version For example: +1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5 Presenting your information in a consistent format will help in tabulating the results. You can include additional information in each section, just don't use extra commas. There is no need to include the mod_python version in this string as that information is available in the email subject. Who knows, one day I may actually write a script to extract this information automatically. :) Thank you for your assistance, Jim Gallacher
Re: Fix to compile trunk on windows
Graham Dumpleton wrote: The only area I guess one may have to be careful with is if you have used PythonPath directive to extend module search path, especially if you reference directories in the document tree. This may result in mod_python complaining in the Apache error log at you and in worst case, if you have Python packages in document tree, it will not find them. Can you clarify this a bit? Does it follow that the use of PythonPath to extend the module search path to directories *outside* of the document tree will still be safe? I use this extensively to isolate code to virtual hosts. I *never* include packages or modules that exist in the document tree in PythonPath, if that's a consideration.
Re: mod_python 3.3.0-dev-20061109 available for testing (release candidate)
Jim Gallacher wrote: The mod_python 3.3-0-dev-20061109 tarball is available for testing. As this is a minor version bump, is there a link to the changelog so we know what new behaviour to expect/test?
Re: mod_python 3.3.0-dev-20061109 available for testing (releasecandidate)
Graham Dumpleton wrote: There are two things you can do to gauge where any loss arises. First is to ensure that module reloading is turned off and see how that changes things. PythonAutoReload Off The second is to reenable the old module importer as a comparison. This needs to be done at global scope within main Apache configuration: PythonOption mod_python.legacy.importer * The argument is actually a comma separated list of interpreter names for which to use the old importer. Listing just '*' has the effect of using the old importer for all interpreter instances. I'm getting the same results with either or both options, so it may be a simple system glitch or a performance hit elsewhere.
Re: mod_python 3.3.0-dev-20061109 available for testing (release candidate)
Jim Gallacher wrote: Jorey Bump wrote: I've installed it on a lightly used production server so I can test it against some real-world apps. Initial testing indicates that it's 10-20% slower than 3.2.10; I'm not sure why. Ouch. Is that from a benchmark or just a gut feeling? It was from ab, running against my own handler and consistently getting 950+ requests/sec with 3.2.10. Then I stopped apache, installed 3.3, started apache, and got no more than 850 requests/sec or worse. I took it on faith that nothing could have changed in the environment in the meantime, but I just switched back to 3.2.10 and am still experiencing the lower numbers, so this is unlikely to be a mod_python problem. Moral: Don't trust benchmarks, and don't report the results without exhaustive testing. The sad part is that I want to know what caused the earlier performance boost so I can get it back!
Re: [Mod_python Wiki] Update of MostMinimalRequestHandler by JoreyBump
Hi, Jim:
Jim Gallacher wrote:
The following page has been changed by JoreyBump:
http://wiki.apache.org/mod_python/MostMinimalRequestHandler
--
Let's begin at the beginning. Here is the most minimal request
handler possible:
+ {{{
def handler(req):
return 0
+ }}}
This is my first use of moinmoin, so I saved more frequently than
necessary. I've already improved the page and discovered the preview
button. :)
FYI, you can get python syntax highlighting by starting your code block
with {{{#!python
Thanks for the tip.
Also I would avoid using return 0. I know you want it to be the most
minimal handler possible, but I think it's better to encourage good
coding habits by using return apache.OK. It will then be more logical
when users move on to more sophisticated handlers, perhaps in other
phases, where the handler may be returning something other than 0.
I've explained this in the final draft, and moved on to using apache.OK
in the next example. This handler is obviously meant to do nothing, but
to the uninitiated, the mod_python voodoo is quite thick. We take it for
granted, but I think a novice will appreciate that the return code
should be an integer (after all, that's what the debugger complains
about if there's a related error).
One of the things we're up against is that I suspect a good chunk of our
audience has no Python experience whatsoever, and they come to
mod_python investigating alternatives to other web application
development languages, like PHP. We can't assume they'll have many
Python (or Apache) skills at all, so we should take the opportunity to
ease them into basic concepts upfront (without dumbing it down, of course).
You could argue that it would be silly for a novice to start out by
writing a custom handler, but the mailing list indicates that it happens
all of the time.
Re: Are we ready for 3.3.1?
It might be prudent to test against Apache 2.2.4, which was released two days ago. I'll try to do this over the weekend and submit the results. Jim Gallacher wrote: We don't seem to be getting any more feedback on 3.3.0b (+1's across the board), so how does everyone feel about rolling out 3.3.1 this weekend? Or should we wait another week? 3.3.0b test result summary: +1 FreeBSD 6.1, Apache 2.2.3 (mpm-prefork), Python 2.4.3,1 +1 Linux Debian 3.1 Sarge, Apache 2.0.54 (mpm-prefork), Python 2.3.5 +1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.3.5 +1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.4.4 +1 Linux Debian Sid, Apache 2.2.3 (mpm-worker), Python 2.5 +1 Linux Fedora Core 2 (OpenVPS) i386, Apache 2.0.51 (mpm-prefork), Python 2.3.3 +1 Linux Fedora Core 4 i386, Apache 2.0.54 (mpm-prefork), Python 2.5 +1 Linux Fedora Core 5 i386, Apache 2.2.2 (mpm-prefork), Python 2.4.3 +1 Linux Fedora Core 5 i386, Apache 2.2.2 (mpm-prefork), Python 2.4.3 +1 Linux Fedora Core 6, Apache 2.2.3 (mpm-prefork), Python 2.4.4 +1 Linux Fedora Core 6 i386, Apache 2.2.3 (mpm-prefork), Python 2.4.4 +1 Linux Fedora Core 6 x86_64, Apache 2.2.3 (mpm-prefork), Python 2.4.4 +1 Linux Slackware 10.2, Apache 2.2.3 (mpm-prefork), Python 2.4.1 +1 Linux Ubuntu 6.0.6, Apache 2.0.55 (mpm-worker), Python 2.4.3 +1 Linux Ubuntu 6.10, Apache 2.0.55 (mpm-prefork), Python 2.4.4c1 +1 Mac OS 10.4.8 (Intel), Apache 2.0.59 (mpm-prefork), Python 2.5 +1 Mac OS X (Darwin 8.8.1, Intel), Apache 2.2.3 (mpm-prefork), Python 2.4.2 +1 Mac OS X (PowerPC), Apache 2.0.55 (mpm-worker), Python 2.3.5 (OS Supplied Version) +1 Mac OS X (PowerPC), Apache 2.2.1 (mpm-worker), Python 2.3.5 (OS Supplied Version) +1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.4 +1 Microsoft Windows XP, Apache 2.0.58 (mpm_winnt), Python 2.5 +1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.4 +1 Microsoft Windows XP, Apache 2.2.2 (mpm_winnt), Python 2.5 +1 Solaris 10 (Sparc), Apache 2.0.59 (mpm-prefork), Python 2.5 Jim
Re: mod_python 3.3.1 available for testing
+1 Slackware Linux 10.2, Apache 2.2.3 (mpm-prefork), Python 2.4.1 Jim Gallacher wrote: The mod_python 3.3.1 tarball is available for testing. Hopefully Nicolas will have a chance to create Windows installers for testing in the next couple of days. There have been no changes in the code since the 3.3.0 beta. Indeed the only thing that has changed is the version strings so we don't need extensive testing this time around - just a few people to check that I haven't done something stupid in creating the tarball. Once we have a handful of +1's I'll call for a vote from the core committers. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.3.1.tgz http://people.apache.org/~jgallacher/mod_python/dist/mod_python-3.3.1.md5 Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ make check Or for you Windows folks $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Apache, Apache-mpm, Python, the test output, and suggestions, if any). Please present your test results in the following format: +1 OS version, Apache version (apache mpm), Python Version For example: +1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5 Presenting your information in a consistent format will help in tabulating the results. You can include additional information in each section, just don't use extra commas. There is no need to include the mod_python version in this string as that information is available in the email subject. Who knows, one day I may actually write a script to extract this information automatically. :) Thank you for your assistance, Jim Gallacher
Re: [VOTE] does mod_python want to be a TLP
Gregory (Grisha) Trubetskoy wrote: 1. Python is not a good name for this project because Apache Python will just be too confusing and probably infringes on a PSF trademark. So if you have any creative suggestions, send them in, don't be shy, even if you think they may sound a little stupid at first :-) Apache includes a feather in its logo, and Python is associated with a snake. Quetzalcoatl means feathered snake and does not appear to be used by any other software project.
Re: [VOTE] does mod_python want to be a TLP
Mike Looijmans wrote: Apache includes a feather in its logo, and Python is associated with a snake. Quetzalcoatl means feathered snake and does not appear to be used by any other software project. Which I can fully understand, because Quetzalcoatl is harder to pronounce than the 16 character password for the mainframe that was generated using /dev/random. I admit I like the logic more than the name itself. I liked Asphyxia though. Makes a nice password too. To me, Asphyxia has *extremely* negative connotations, and really stretches the limits of clever association. Another name that comes to mind is Scales, playing on the Apache feather motif, but I fear it will be lost in search results among pages that discuss how well Apache scales.
Re: TLP Name
For me, it's a tie between Quetzalcoatl Scales. Gregory (Grisha) Trubetskoy wrote: So I think we've got (in no particular order): PythonScript Pythonidae PyPache pythonalia Quetzalcoatl Asphyxia Scales Pythonistas PigeonPy Pungi Would people (ANYONE here on the list, yes, that includes *YOU*) please respond with the one they like most and I will compile the results? Thanks! Grisha
