jvandal / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

Support in daemon mode for ITK MPM. #187

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Daemon mode will not work with ITK MPM for Apache because the Apache server 
child processes 
change uid for each request to that related to resource being processed. As 
such, they cannot 
access the daemon process listener sockets as they are owned and only 
accessible to Apache user.

One solution to this is that when ITK MPM being used, make the listener sockets 
be owned by the 
same user as the daemon process runs. This way, so long as WSGI applications 
are not delegated to 
a daemon process running as a different user to the resource itself, then would 
allow use of daemon 
mode subject to that restriction.

One could determine what MPM is being used by such definitions as:

#define PREFORK_MPM

#define MPM_NAME "Prefork"

in mpm.h file that MPM. Presumably the ITK MPM has such definitions.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 4 Mar 2010 at 11:37

GoogleCodeExporter commented 8 years ago
Hi Graham,

MPM-ITK indeed has the definition: #define MPM_NAME "ITK" in mpm.h :) 

Cheers!

Nick

Original comment by rootst...@gmail.com on 4 Mar 2010 at 2:40

GoogleCodeExporter commented 8 years ago
The official website is http://mpm-itk.sesse.net/ and the official patchset 
(which is applied against prefork) is at: 
http://mpm-itk.sesse.net/apache2.2-mpm-itk-2.2.11-02/

There is also a #define ITK_MPM.

Original comment by Graham.Dumpleton@gmail.com on 6 Mar 2010 at 11:43

GoogleCodeExporter commented 8 years ago
For ITK MPM, do:

     if (!geteuid()) {
+#if defined(MPM_ITK)
+        if (chown(process->socket, process->uid, -1) < 0) {
+#else
         if (chown(process->socket, ap_unixd_config.user_id, -1) < 0) {
+#endif
             ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(errno), wsgi_server,
                          "mod_wsgi (pid=%d): Couldn't change owner of unix "
                          "domain socket '%s'.", getpid(),

Thus, set UNIX listener socket to be owned by the same user as daemon process 
runs as.

This means that Apache server processes could still at least connect when they 
have switched to user which is 
the same to handle a request.

Another possibility is to also change group ownership of the UNIX listener 
socket. This would allow the Apache 
server process to also connect when the user of process handling the request is 
within the group that daemon 
process group runs as.

For now, only do user change. Have added this to subversion trunk for mod_wsgi 
4.0 at revision 1545.

Feedback about the group ownership appreciated.

Original comment by Graham.Dumpleton@gmail.com on 10 Mar 2010 at 10:43

GoogleCodeExporter commented 8 years ago
Still like to see some feedback on this. Still marking it though as being in 
mod_wsgi 4.0.

Original comment by Graham.Dumpleton@gmail.com on 1 Apr 2010 at 4:44

GoogleCodeExporter commented 8 years ago
Backport to mod_wsgi 3.X branch for 3.3 in revision 1602.

Original comment by Graham.Dumpleton@gmail.com on 12 Jul 2010 at 2:05

GoogleCodeExporter commented 8 years ago
Version 3.3 has been released.

Original comment by Graham.Dumpleton@gmail.com on 31 Jul 2010 at 10:39

GoogleCodeExporter commented 8 years ago
Hi, i can still reproduce the problem using MPM ITK and mod_wsgi 3.3 (socket is 
still owned by apache user). Is this really supposed to work ? Thnx.

Original comment by azu...@pobox.sk on 14 Dec 2011 at 2:43

GoogleCodeExporter commented 8 years ago
You need to ensure that mod_wsgi is built against the correct Apache header 
files for the ITK MPM. If you are using a binary package for Apache from a 
distro you likely still have the dev package with worker or prefork MPM header 
files installed.

Original comment by Graham.Dumpleton@gmail.com on 14 Dec 2011 at 8:37

GoogleCodeExporter commented 8 years ago
Hm, maybe this could be done by some config settings instead ? I'm using Debian 
and it's original packages.

Original comment by azu...@pobox.sk on 16 Dec 2011 at 5:01

GoogleCodeExporter commented 8 years ago
Technically that is probably not possible. The different MPMs have a different 
header file defining important parameters and structures related to that MPM. 
So, when you build an Apache module against a header file for a specific MPM 
you are only supposed to use it with an Apache built with that MPM.

Some Linux Apache distributions try and cheat and for some Apache modules will 
try and use the same .so for Apache's with different MPM compiled in. For 
prefork/worker a single mod_wsgi.so seems to work, but it certainly is not 
guaranteed. I would have less confidence that the same mod_wsgi.so would also 
work against ITK MPM as it is somewhat different to how prefork/worker MPM work 
as far as process management.

Original comment by Graham.Dumpleton@gmail.com on 16 Dec 2011 at 8:51

GoogleCodeExporter commented 8 years ago
Ok but back to my previous question - would it be possible to tell mod_wsgi to 
change ownership of socket file via configuration settings ? It's much better 
solution in my point of view. Or maybe a setting which can be used to set 
different permissions for socket file. What do you think ?

Original comment by azu...@pobox.sk on 17 Dec 2011 at 1:20

GoogleCodeExporter commented 8 years ago
That is not the correct solution and it will serve no practical purpose. This 
is because the socket ownership and permissions can only be set in one way for 
the specific MPM in use. Having the ability to change it dynamically therefore 
would serve no point.

If you really insist in not actually installing your Apache properly so that 
development header files for the in use MPM are available, the simplest 
solution for you would be to compile mod_wsgi source code yourself and change 
mod_wsgi source code so that instead of:

  #if defined(MPM_ITK)

it says:

  #if 1

As I said before though, this isn't guaranteed to work overall because you 
would be compiling mod_wsgi against wrong header files for the MPM in use, so 
definitions and structure sizes could be wrong. This may result in strange 
behaviour or cause Apache or mod_wsgi to crash in use.

Ultimately the real problem here is the maintainers of the ITK MPM binary 
package, if that is what you are using, not providing a -dev package for Apache 
for the ITK MPM worker. Go lodge a bug report against your Linux distribution 
as that is what really needs to be fixed.

Original comment by Graham.Dumpleton@gmail.com on 18 Dec 2011 at 12:32

GoogleCodeExporter commented 8 years ago
Ok, thank you!

Original comment by azu...@pobox.sk on 19 Dec 2011 at 8:03

GoogleCodeExporter commented 8 years ago
Hi there,
I found that after I start apache, I can chown <user_for_vhost>:<apache_group> 
wsgi.sock, and the error disappears. Upon apache restart, the permissions for 
the newly created .sock file are reset, creating the error. it's a pain in the 
butt, so I have to give up itk for worker for now.

Original comment by cutestr...@gmail.com on 30 Apr 2012 at 7:13

GoogleCodeExporter commented 8 years ago
cutestrike. You aren't using mod_wsgi compiled against ITK MPM. It is that 
simple. You need to compile mod_wsgi from source code against an Apache 
installation which has the correct ITK MPM developer header files installed. 
Some distros don't provide the development header files for ITK MPM, so you 
have no choice but to build and install Apache from source code yourself and 
compile against and use it.

Original comment by Graham.Dumpleton@gmail.com on 30 Apr 2012 at 11:32

GoogleCodeExporter commented 8 years ago
Yep, thank you Graham.

Original comment by cutestr...@gmail.com on 2 May 2012 at 10:13

GoogleCodeExporter commented 8 years ago
Hello, how can I apply this solution in FreeBSD ports Apache?

Original comment by jeltoeso...@aol.com on 25 Jun 2012 at 2:52

GoogleCodeExporter commented 8 years ago
I have no idea how FreeBSD handles things. The only guaranteed way to be sure 
is not to use binary packages for Apache but build it from source code yourself 
so know have right development header files installed.

Original comment by Graham.Dumpleton@gmail.com on 27 Jun 2012 at 12:11