On May 4, 9:17 pm, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote: > One module I saw someday on my list of new packages on Debian: > > from apt-cache show apache2-mpm-itk > Description: multiuser MPM for Apache 2.2 > The ITK Multi-Processing Module (MPM) works in about the same way as the > classical "prefork" module (that is, without threads), except that it > allows > you to constrain each individual vhost to a particular system user. This > allows you to run several different web sites on a single server without > worrying that they will be able to read each others' files. > . > Please note that this MPM is highly experimental, and is not from the same > tree as the other MPMs.
The ITK MPM is a variation of the PerChild MPM, as are the PerUser and METUX MPMs, both of which were also an attempt to implement the concept of separation that PerChild was trying to implement. Apart from general stability issues with some of these MPMs, the problem is that not all third party Apache modules will necessarily work with them without needing to be changed. The mod_python module in particular needs to be hacked to get it to work under the ITK MPM (and probably the others as well), otherwise the global session locking code in mod_python may break and cause mod_python to fail on some platforms. This comes about because the different users the processes run as may not have the appropriate privileges to lock the global mutex. Details of this specific problem with mod_python are documented at: http://issues.apache.org/jira/browse/MODPYTHON-202 Just on the basis that some third party modules may not work as is, I suspect that these MPMs will not really become mainstream even if they can in time made to be stable. Ie., module developers may not want to change their packages to support such a non main stream MPM. > The day it becomes "stable" it can be a nice thing, but for now the most > secure way is FastCGI ;) FastCGI being the only solution will hopefully not be the case for too much longer as mod_wsgi when complete will also have the ability to have requests for specific applications handled within a distinct daemon process running as a different user. With mod_wsgi, because the module is targeted specifically at supporting WSGI, it will not be necessary to use a separate infrastructure package such as flup. Instead, it will just take the addition of a couple of directives in the Apache configuration and your WSGI application script as it would run embedded within Apache, will instead be run in the distinct daemon process. Ie., no change required to your WSGI application script file. Some details of this feature of mod_wsgi have been described previously at: http://groups.google.com/group/modwsgi/browse_frm/thread/c1ba08c3cea384c Note though that some aspects of what was described have changed, such as directive can now indicate how many daemon processes to startup in a specific named group thereby avoiding any rewrite tricks to load balance as such distribution of request across multiple daemons for same application will happen automatically, just like requests are distributed between Apache child processes in the first place. Thus, don't need rewrite tricks as described unless you did specifically want to control how many daemon processes used without restarting Apache. Anyway, the code in mod_wsgi for this is still being developed and all the bits are not yet available, so you will need to wait a bit longer. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
