Code Monkey home page Code Monkey logo

mod_wsgi's Introduction

Overview

The mod_wsgi package provides an Apache module that implements a WSGI compliant interface for hosting Python based web applications on top of the Apache web server.

Note that the major version 5.0 was introduced not because of any new major features but because from version 5.0 onwards compatability with Python 2.7 is no longer guaranteed. A minimum Python version of 3.8 will be enforced by the Python package installation configuration.

Installation of mod_wsgi from source code can be performed in one of two ways.

The first way of installing mod_wsgi is the traditional way that has been used by many software packages. This is where it is installed as a module directly into your Apache installation using the commands configure, make and make install, a method sometimes referred to by the acronym CMMI. This method works with most UNIX type systems. It cannot be used on Windows.

The second way of installing mod_wsgi is to install it as a Python package into your Python installation using the Python pip install command. This can be used on all platforms, including Windows.

This second way of installing mod_wsgi will compile not only the Apache module for mod_wsgi, but will also install a Python module and admin script, which on UNIX type systems can be used to start up a standalone instance of Apache directly from the command line with an auto generated configuration.

This later mechanism for installing mod_wsgi using Python pip is a much simpler way of getting starting with hosting your Python web application. In particular, this installation method makes it very easy to use Apache/mod_wsgi in a development environment without the need to perform any Apache configuration yourself.

The Apache module for mod_wsgi created when using the pip install method can still be used with the main Apache installation, via manual configuration if necessary. As detailed later in these instructions, the admin script installed when you use pip install can be used to generate the configuration to manually add to the Apache configuration to load mod_wsgi.

Note that although MacOS X is a UNIX type system, the pip install method is the only supported way for installing mod_wsgi.

Since MacOS X Sierra, Apple has completely broken the ability to install third party Apache modules using the apxs tool normally used for this task. History suggests that Apple will never fix the problem as they have broken things in the past in other ways and workarounds were required as they never fixed those problems either. This time there is no easy workaround as they no longer supply certain tools which are required to perform the installation.

The pip install method along with the manual configuration of Apache is also the method you need to use on Windows.

System Requirements

With either installation method for mod_wsgi, you must have Apache installed. This must be a complete Apache installation. It is not enough to have only the runtime packages for Apache installed. You must have the corresponding development package for Apache installed, which contains the Apache header files, as these are required to be able to compile and install third party Apache modules.

Similarly with Python, you must have a complete Python installation which includes the corresponding development package, which contains the header files for the Python library.

If you are running Debian or Ubuntu Linux with Apache 2.2 system packages, and were using the Apache prefork MPM you would need both:

  • apache2-mpm-prefork
  • apache2-prefork-dev

If instead you were using the Apache worker MPM, you would need both:

  • apache2-mpm-worker
  • apache2-threaded-dev

If you are running Debian or Ubuntu Linux with Apache 2.4 system packages, regardless of which Apache MPM is being used, you would need both:

  • apache2
  • apache2-dev

If you are running RHEL, CentOS or Fedora, you would need both:

  • httpd
  • httpd-devel

If you are using the Software Collections Library (SCL) packages with RHEL, CentOS or Fedora, you would need:

  • httpd24
  • httpd24-httpd-devel

If you are running MacOS X, Apache is supplied with the operating system. If running a recent MacOS X version, you will though need to have the Xcode command line tools installed as well as the Xcode application. The command line tools can be installed by running xcode-select --install. The Xcode application can be installed from the MacOS X App Store. If you are using older MacOS X versions, you may be able to get away with having just the command line tools.

If you are running Windows, it is recommended you use the Apache distribution from Apache Lounge (www.apachelounge.com). Other Apache distributions for Windows aren't always complete and are missing the files needed to compile additional Apache modules. By default, it is expected that Apache is installed in the directory C:/Apache24 on Windows.

If you are on Linux, macOS or other UNIX type operating system and can't or don't want to use the system package for Apache, you can use pip to install mod_wsgi, but you should use use the mod_wsgi-standalone package on PyPi instead of the mod_wsgi package.

Installation into Apache

For installation directly into your Apache installation using the CMMI method, see the full documentation at:

Alternatively, use the following instructions to install mod_wsgi into your Python installation and then either copy the mod_wsgi module into your Apache installation, or configure Apache to use the mod_wsgi module from the Python installation.

When using this approach, you will still need to manually configure Apache to have mod_wsgi loaded into Apache, and for it to know about your WSGI application.

Installation into Python

To install mod_wsgi directly into your Python installation, from within the source directory of the mod_wsgi package you can run:

python setup.py install

This will compile mod_wsgi and install the resulting package into your Python installation.

If wishing to install an official release direct from the Python Package Index (PyPi), you can instead run:

pip install mod_wsgi

If you wish to use a version of Apache which is installed into a non standard location, you can set and export the APXS environment variable to the location of the Apache apxs script for your Apache installation before performing the installation.

If you are using Linux, macOS or other UNIX type operating system, and you don't have Apache available, you can instead install mod_wsgi using:

pip install mod_wsgi-standalone

When installing mod_wsgi-standalone, it will also install a version of Apache into your Python distribution. You can only use mod_wsgi-express when using this variant of the package. The mod_wsgi-standalone package follows the same version numbering as the mod_wsgi package on PyPi.

If you are on Windows and your Apache distribution is not installed into the directory C:/Apache24, first set the environment variable MOD_WSGI_APACHE_ROOTDIR to the directory containing the Apache distribution. Ensure you use forward slashes in the directory path. The directory path should not include path components with spaces in the name.

Note that nothing will be copied into your Apache installation at this point. As a result, you do not need to run this as the root user unless installing it into a site wide Python installation rather than a Python virtual environment. It is recommended you always use Python virtual environments and never install any Python package directly into the system Python installation.

On a UNIX type system, to verify that the installation was successful, run the mod_wsgi-express script with the start-server command:

mod_wsgi-express start-server

This will start up Apache/mod_wsgi on port 8000. You can then verify that the installation worked by pointing your browser at:

http://localhost:8000/

When started in this way, the Apache web server will stay in the foreground. To stop the Apache server, use CTRL-C.

For a simple WSGI application contained in a WSGI script file called wsgi.py, in the current directory, you can now run:

mod_wsgi-express start-server wsgi.py

This instance of the Apache web server will be completely independent of, and will not interfere with any existing instance of Apache you may have running on port 80.

If you already have another web server running on port 8000, you can override the port to be used using the --port option:

mod_wsgi-express start-server wsgi.py --port 8080

For a complete list of options you can run:

mod_wsgi-express start-server --help

For further information related to using mod_wsgi-express see the main mod_wsgi documentation.

Non standard Apache installations

Many Linux distributions have a tendency to screw around with the standard Apache Software Foundation layout for installation of Apache. This can include renaming the Apache httpd executable to something else, and in addition to potentially renaming it, replacing the original binary with a shell script which performs additional actions which can only be performed as the root user.

In the case of the httpd executable simply being renamed, the executable will obviously not be found and mod_wsgi-express will fail to start at all.

In this case you should work out what the httpd executable was renamed to and use the --httpd-executable option to specify its real location.

For example, if httpd was renamed to apache2, you might need to use:

mod_wsgi-express start-server wsgi.py --httpd-executable=/usr/sbin/apache2

In the case of the httpd executable being replaced with a shell script which performs additional actions before then executing the original httpd executable, and the shell script is failing in some way, you will need to use the location of the original httpd executable the shell script is in turn executing.

Running mod_wsgi-express as root

The primary intention of mod_wsgi-express is to make it easier for users to run up Apache on non privileged ports, especially during the development of a Python web application. If you want to be able to run Apache using mod_wsgi-express on a privileged port such as the standard port 80 used by HTTP servers, then you will need to run mod_wsgi-express as root. In doing this, you will need to perform additional steps.

The first thing you must do is supply the --user and --group options to say what user and group your Python web application should run as. Most Linux distributions will predefine a special user for Apache to run as, so you can use that. Alternatively you can use any other special user account you have created for running the Python web application:

mod_wsgi-express start-server wsgi.py --port=80 \
    --user www-data --group www-data

This approach to running mod_wsgi-express will be fine so long as you are using a process supervisor which expects the process being run to remain in the foreground and not daemonize.

If however you are directly integrating into the system init scripts where separate start and stop commands are expected, with the executing process expected to be daemonized, then a different process is required to setup mod_wsgi-express.

In this case, instead of simply using the start-server command to mod_wsgi-express you should use setup-server:

mod_wsgi-express setup-server wsgi.py --port=80 \
    --user www-data --group www-data \
    --server-root=/etc/mod_wsgi-express-80

In running this command, it will not actually startup Apache. All it will do is create the set of configuration files and the startup script to be run.

So that these are not created in the default location of a directory under /tmp, you should use the --server-root option to specify where they should be placed.

Having created the configuration and startup script, to start the Apache instance you can now run:

/etc/mod_wsgi-express-80/apachectl start

To subsequently stop the Apache instance you can run:

/etc/mod_wsgi-express-80/apachectl stop

You can also restart the Apache instance as necessary using:

/etc/mod_wsgi-express-80/apachectl restart

Using this approach, the original options you supplied to setup-server will be cached with the same configuration used each time. If you need to update the set of options, run setup-server again with the new set of options.

Note that even taking all these steps, it is possible that running up Apache as root using mod_wsgi-express may fail on systems where SELinux extensions are enabled. This is because the SELinux profile may not match what is being expected for the way that Apache is being started, or alternatively, the locations that Apache has been specified as being allowed to access, don't match where the directory specified using the --server-root directory was placed. You may therefore need to configure SELinux or move the directory used with --server-root to an allowed location.

In all cases, any error messages will be logged to a file under the server root directory. If you are using mod_wsgi-express with a process supervisor, or in a container, where log messages are expected to be sent to the terminal, you can use the --log-to-terminal option.

Using mod_wsgi-express with Django

To use mod_wsgi-express with Django, after having installed the mod_wsgi package into your Python installation, edit your Django settings module and add mod_wsgi.server to the list of installed apps.

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'mod_wsgi.server',
)

To prepare for running mod_wsgi-express, ensure that you first collect up any Django static file assets into the directory specified for them in the Django settings file:

python manage.py collectstatic

You can now run the Apache server with mod_wsgi hosting your Django application by running:

python manage.py runmodwsgi

If working in a development environment and you would like to have any code changes automatically reloaded, then you can use the --reload-on-changes option.

python manage.py runmodwsgi --reload-on-changes

If wanting to have Apache started as root in order to listen on port 80, instead of using mod_wsgi-express setup-server as described above, use the --setup-only option to the runmodwsgi management command.

python manage.py runmodwsgi --setup-only --port=80 \
    --user www-data --group www-data \
    --server-root=/etc/mod_wsgi-express-80

This will set up all the required files and you can use apachectl to start and stop the Apache instance as explained previously.

Connecting into Apache installation

If you want to use mod_wsgi in combination with your system Apache installation, the CMMI method for installing mod_wsgi would normally be used.

If you are on MacOS X Sierra that is no longer possible. Even prior to MacOS X Sierra, the System Integrity Protection (SIP) system of MacOS X, prevented installing the mod_wsgi module into the Apache modules directory.

If you are using Windows, the CMMI method was never supported as Windows doesn't supply the required tools to make it work.

The CMMI installation method also involves a bit more work as you need to separately download the mod_wsgi source code, run the configure tool and then run make and make install.

The alternative to using the CMMI installation method is to use the Apache mod_wsgi module created by running pip install. This can be directly referenced from the Apache configuration, or copied into the Apache modules directory.

To use the Apache mod_wsgi module from where pip install placed it, run the command mod_wsgi-express module-config. This will output something like:

LoadModule wsgi_module /usr/local/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so
WSGIPythonHome /usr/local/lib

These are the directives needed to configure Apache to load the mod_wsgi module and tell mod_wsgi where the Python installation directory or virtual environment was located.

This would be placed in the Apache httpd.conf file, or if using a Linux distribution which separates out module configuration into a mods-available directory, in the wsgi.load file within the mods-available directory. In the latter case where a mods-available directory is used, the module would then be enabled by running a2enmod wsgi as root. If necessary Apache can then be restarted to verify the module is loading correctly. You can then configure Apache as necessary for your specific WSGI application.

Note that because in this scenario the mod_wsgi module for Apache could be located in a Python virtual environment, if you destroy the Python virtual environment the module will also be deleted. In that case you would need to ensure you recreate the Python virtual environment and reinstall the mod_wsgi package using pip, or, take out the mod_wsgi configuration from Apache before restarting Apache, else it will fail to startup.

Instead of referencing the mod_wsgi module from the Python installation, you can instead copy the mod_wsgi module into the Apache installation. To do that, run the mod_wsgi-express install-module command, running it as root if necessary. This will output something like:

LoadModule wsgi_module modules/mod_wsgi-py27.so
WSGIPythonHome /usr/local/lib

This is similar to above except that the mod_wsgi module was copied to the Apache modules directory first and the LoadModule directive references it from that location. You should take these lines and configure Apache in the same way as described above.

Do note that copying the module like this will not work on recent versions of MacOS X due to the SIP feature of MacOS X.

mod_wsgi's People

Contributors

abbra avatar akrherz avatar alejoasd avatar andyneff avatar bdc34 avatar bteague avatar chimosky avatar chrisledet avatar deckar01 avatar encukou avatar frewsxcv avatar funkybob avatar grahamdumpleton avatar greyli avatar jabelone avatar james-prior avatar mesoclever avatar natashamm avatar paihu avatar pieterdp avatar praiskup avatar pyhalov avatar reduxionist avatar roblui avatar sandrotosi avatar sjemens avatar stephenorjames avatar tiran avatar yn-coder avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mod_wsgi's Issues

Mac Port version of mod_wsgi crashes at initialisation

I am using the Mac Ports version of mod_wsgi. I have apache2 @2.2.27_0+preforkmpm, python27 @2.7.8_1 and mod_wsgi @4.2.8_0+python27 installed in Mac OS X 10.9.4. Enabling "LoadModule wsgi_module modules/mod_wsgi.so" in httpd.conf results in a crash as soon as Apache is started. The crash report shows:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 mod_wsgi.so 0x00000001101fec13 wsgi_python_init + 55
1 mod_wsgi.so 0x00000001102000da wsgi_hook_child_init + 133
2 httpd 0x000000010f30c140 ap_run_child_init + 51
3 httpd 0x000000010f32fa6a child_main + 263
4 httpd 0x000000010f32f2fc make_child + 207
5 httpd 0x000000010f32ed68 ap_mpm_run + 2089
6 httpd 0x000000010f3114ce main + 2314
7 libdyld.dylib 0x00007fff8ef675fd start + 1

Commenting out the LoadModule line allows Apache to run, but of course without mod_wsgi.

What could be the problem?

Add directive to undo HEAD to GET mapping when output filters exist.

If Apache output filters are detected that could care about seeing the actual content for a HEAD, the mod_wsgi will remap a HEAD request to a GET request. This is to ensure that output filters will generate the same response headers where they are generating some based on the actual content. If this isn't done it is technically breaking the HTTP specification that response headers for GET and HEAD should be the same.

Even though this is the case, provide a directive to disable this auto mapping for those people who believe that they aren't using any Apache output filters where this would matter.

See:

Original commentary about the GET vs HEAD problem at:

Not able to install mod_wsgi in Windows 7

C:\Users\gbs03566\Desktop\mod_wsgi-4.3.0>python setup.py install
Traceback (most recent call last):
File "setup.py", line 41, in
'Apache httpd server packages.' % APXS)
RuntimeError: The 'apxs' command appears not to be installed or is not executable. Please check the list of prerequisites in the documentation for this package and install any missing Apache httpd server packages.

Response headers when using daemon mode not visible to Apache output filters.

As detailed in:

A response header set by the WSGI application is visible to mod_headers when running in embedded mode, but not when using daemon mode.

To test use:

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output))),
                        ('X-Value', 'XXX')]
    start_response(status, response_headers)

    return [output]

and in Apache configuration:

Header edit X-Value ^ "YYY"

If in embedded mode and use curl -v see:

< HTTP/1.1 200 OK
< Date: Fri, 02 May 2014 03:02:25 GMT
< Server: Apache/2.2.26 (Unix) DAV/2 mod_wsgi/4.1.0 Python/2.7.2 mod_ssl/2.2.26 OpenSSL/0.9.8y
< X-Value: YYYXXX
< Transfer-Encoding: chunked
< Content-Type: text/plain
<
* Connection #0 to host localhost left intact

If in daemon mode with:

WSGIDaemonProcess xxx
WSGIProcessGroup xxx

see:

< HTTP/1.1 200 OK
< Date: Fri, 02 May 2014 03:03:03 GMT
< Server: Apache/2.2.26 (Unix) DAV/2 mod_wsgi/4.1.0 Python/2.7.2 mod_ssl/2.2.26 OpenSSL/0.9.8y
< X-Value: XXX
< Content-Length: 12
< Content-Type: text/plain
<
* Connection #0 to host localhost left intact

Preserve authentication headers returned from daemon mode as is.

The ap_scan_script_header_err_brigade() from Apache used to process response headers from daemon mode processes will merge WWW-Authenticate header values onto one line. This caused issues so mod_wsgi was changed to split them again. The splitting though cause problems where WWW-Authenticate header values weren't completely valid and used comma in their values.

What needs to be done is that parser needs to be duplicated with it leaving the headers as is and neither splitting or joining.

For prior discussion see:

Also see #3 which also requires the parser function to be duplicated.

Add a --debug-mode option to allow use of pdb.

When using mod_wsgi express, even though it will default to staying in foreground, the WSGI application still runs in a separate daemon process group.

Add a --debug-mode option which will run a single process for the whole of Apache with a single thread using the Apache -DONE_PROCESS option and mod_wsgi in embedded mode with a single thread. In using this, Apache attaches stdin/stdout to that of the console you can the command in. This then allows the use of pdb to debug your WSGI application.

Daemon process crash in new_threadstate after graceful reload

After moving from mod_wsgi 3.3 (Ubuntu 12.04) to mod_wsgi 3.4 (Ubuntu 13.10), we have seen several occasions where multiple daemon processes segfault at the same time when I touch the main wsgi.py file to perform a graceful restart.

Here's the stack trace from the core file:

Core was generated by `(wsgi:xxxxxxx)    -k start'.
Program terminated with signal 11, Segmentation fault.

(gdb) bt
#0  new_threadstate (init=1, interp=0x0) at ../Python/pystate.c:202
#1  PyThreadState_New (interp=0x0) at ../Python/pystate.c:213
#2  0x00007f7460a9ca3c in PyGILState_Ensure () at ../Python/pystate.c:600
#3  0x00007f7460e63c68 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#4  0x00007f74653c6f6e in start_thread (arg=0x7f745f2ad700) at pthread_create.c:311
#5  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) bt full
#0  new_threadstate (init=1, interp=0x0) at ../Python/pystate.c:202
        tstate = 0x7f74580008c0
#1  PyThreadState_New (interp=0x0) at ../Python/pystate.c:213
No locals.
#2  0x00007f7460a9ca3c in PyGILState_Ensure () at ../Python/pystate.c:600
        current = <optimized out>
        tcur = 0x0
#3  0x00007f7460e63c68 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
No symbol table info available.
#4  0x00007f74653c6f6e in start_thread (arg=0x7f745f2ad700) at pthread_create.c:311
        __res = <optimized out>
        pd = 0x7f745f2ad700
        now = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140137789576960, 7677402908759434006, 0, 140137902719072, 140137902460528, 4096, -7754315576225815786, 
                -7754258218053393642}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
        pagesize_m1 = <optimized out>
        sp = <optimized out>
        freesize = <optimized out>
        __PRETTY_FUNCTION__ = "start_thread"
#5  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Other threads:

(gdb) thread apply all bt

Thread 4 (Thread 0x7f744de40700 (LWP 15917)):
#0  0x00007f74650b885d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f74650b8701 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
#2  0x00007f7460e667a9 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#3  0x00007f74653c6f6e in start_thread (arg=0x7f744de40700) at pthread_create.c:311
#4  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 3 (Thread 0x7f745faae700 (LWP 25971)):
#0  0x00007f74650e9de3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f74655ffe25 in apr_sleep () from /usr/lib/libapr-1.so.0
#2  0x00007f7460e63f37 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#3  0x00007f74653c6f6e in start_thread (arg=0x7f745faae700) at pthread_create.c:311
#4  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7f7465e85780 (LWP 25876)):
#0  0x00007f7454376724 in _fini () from /usr/lib/x86_64-linux-gnu/libtiff.so.5
#1  0x00007f7465c80f47 in _dl_fini () at dl-fini.c:258
#2  0x00007f7465033071 in __run_exit_handlers (status=-1, listp=0x7f74653b86a8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77
#3  0x00007f74650330f5 in __GI_exit (status=<optimized out>) at exit.c:99
#4  0x00007f7460e709ca in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#5  0x00007f7460e71ca5 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#6  0x00007f7465ee9ef1 in ap_run_post_config (pconf=0x7f7465e83028, plog=0x7f7465e57028, ptemp=0x7f7465e4d028, s=0x7f7465e49d80) at config.c:104
#7  0x00007f7465ecabd7 in main (argc=3, argv=0x7fffdd66c548) at main.c:765

Thread 1 (Thread 0x7f745f2ad700 (LWP 25972)):
#0  new_threadstate (init=1, interp=0x0) at ../Python/pystate.c:202
#1  PyThreadState_New (interp=0x0) at ../Python/pystate.c:213
#2  0x00007f7460a9ca3c in PyGILState_Ensure () at ../Python/pystate.c:600
#3  0x00007f7460e63c68 in ?? () from /usr/lib/apache2/modules/mod_wsgi.so
#4  0x00007f74653c6f6e in start_thread (arg=0x7f745f2ad700) at pthread_create.c:311
#5  0x00007f74650f19cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Have mod_wsgi express generate Linux system startup init scripts.

The mod_wsgi express options for creating a server configuration suitable for start/stop via an apachectl command allow the generated configuration to be used from system init scripts. It still requires those init scripts be generated. So, extend what is generated to also include any startup scripts for direct integration into the system startup process manager. All that would then be required is to copy or link the startup scripts into the appropriate location and let the system know about them. Should generate startup scripts suitable for Ubuntu, Debian and RedHat.

Early set headers not see by mod_wsgi.

If use:

Header set X-Special-Header "XXX" early

then this isn't visible as HTTP_X_SPECIAL_HEADER in auth scripts or in WSGI application.

Would expect it should since should be set before request is even mapped and so should be picked up later.

May or may not be some relationship to #5.

wsgi process drop off

We run site through Apache/2.2.16 (Debian) + mod_wsgi/3.3 + Python/2.6.6. The Apache config is shown below:

<VirtualHost *:80>
    ...
    WSGIDaemonProcess <site name> processes=8 threads=1 home=/tmp maximum-requests=500 display-name=%{GROUP} user=nobody
    WSGIProcessGroup <site name>
    WSGIScriptAlias / /xx
    ...
</VirtualHost>

But as time goes by, wsgi process num was reduced from 8 to 6 through shell command ps aux | grep <site name> . Though Apache error log, we found the two processes (pid=10779 and pid=10772) has been shutdown but not restarted.

[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Maximum requests reached 'xxx'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Shutdown requested 'xxx'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Stopping process 'xxx'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Destroying interpreters.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Destroy interpreter 'xxx:80|'.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Cleanup interpreter ''.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Terminating Python.
[Wed Oct 15 22:31:12 2014] [info] mod_wsgi (pid=10779): Python has shutdown.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Maximum requests reached 'xxx'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Shutdown requested 'xxx'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Stopping process 'xxx'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Destroying interpreters.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Destroy interpreter 'xxx:80|'.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Cleanup interpreter ''.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Terminating Python.
[Wed Oct 15 22:31:56 2014] [info] mod_wsgi (pid=10772): Python has shutdown.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Maximum requests reached 'xxx'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Shutdown requested 'xxx'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Stopping process 'xxx'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Destroying interpreters.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Destroy interpreter 'xxx:80|'.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Cleanup interpreter ''.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Terminating Python.
[Wed Oct 15 22:32:13 2014] [info] mod_wsgi (pid=10904): Python has shutdown.
[Wed Oct 15 22:32:14 2014] [info] mod_wsgi (pid=12726): Attach interpreter ''.
[Wed Oct 15 22:32:18 2014] [info] mod_wsgi (pid=12726): Create interpreter 'xxx:80|'.
[Wed Oct 15 22:32:18 2014] [info] [client 219.136.134.164] mod_wsgi (pid=12726, process='xxx', application='xxx:80|'): Loading WSGI script '/xxx'.

Look forward to your reply.

Response chunking and daemon process crash or application exception.

If the daemon mode process crashes when yielding a chunked response by virtue of not setting a content length, or if either embedded or daemon mode is used and the WSGI application triggers an exception while yielding data, then the chunked response is being closed off with a final '0' chunk as if the response was complete rather than it leaving a hanging block with no '0' chunk.

This is possibly undesirable, but then it also isn't really known whether a client could even rely on absence of a '0' chunk to indicate that some sort of error occurred. This is because chunked transfer encoding is a hop by hop header and so a proxy can technically change the chunking due to buffering. It isn't known whether a proxy is required to preserve the absence of a '0' chunk so that a client is aware of it, or whether it is completely within its rights to add a '0' chunk with a subsequent loss of information.

Looking at the Apache HTTP proxy module it does try and ensure that not '0' chunk is added if the connection is broken:

        /* RFC 2616, Section 3.6.1
         *
         * If there is an EOS bucket, then prefix it with:
         *   1) the last-chunk marker ("0" CRLF)
         *   2) the trailer
         *   3) the end-of-chunked body CRLF
         *
         * We only do this if we have not seen an error bucket with
         * status HTTP_BAD_GATEWAY. We have memorized an
         * error bucket that we had seen in the filter context.
         * The error bucket with status HTTP_BAD_GATEWAY indicates that the
         * connection to the backend (mod_proxy) broke in the middle of the
         * response. In order to signal the client that something went wrong
         * we do not create the last-chunk marker and set c->keepalive to
         * AP_CONN_CLOSE in the core output filter.
         *
         * XXX: it would be nice to combine this with the end-of-chunk
         * marker above, but this is a bit more straight-forward for
         * now.
         */
        if (eos && !f->ctx) {
            /* XXX: (2) trailers ... does not yet exist */
            e = apr_bucket_immortal_create(ASCII_ZERO ASCII_CRLF
                                           /* <trailers> */
                                           ASCII_CRLF, 5, c->bucket_alloc);
            APR_BUCKET_INSERT_BEFORE(eos, e);
        }

Other modules such as when proxying SCGI don't try and do this though and always add a EOS bucket after the bucket for the socket, meaning a client couldn't know if the connection was lost. For SCGI at least, this is because there is no chunking of data from SCGI process and so it couldn't know.

Right now have similar problem with responses from daemon mode as don't have any framing of data using chunked encoding or otherwise.

As to when an exception is raised, it looks like the EOS bucket will always be added automatically at the end of a request. The only thing one can appear to do is set r->eos_sent to true to fake out that EOS has already been sent. That should prevent automatic sending of EOS bucket and thus disable sending to '0' chunk if chunked transfer encoding on response.

Have apachectl complain when started as root and non root user/group not specified.

If mod_wsgi-express is run as root and the --user and --group options were not supplied, Apache will fail to startup and give the real worrying error message of:

Error:\tApache has not been designed to serve pages while\n\trunning as root.  There are known race conditions that\n\twill allow any local user to read any file on the system.\n\tIf you still desire to serve pages as root then\n\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n\tand then rebuild the server.\n\tIt is strongly suggested that you instead modify the User\n\tdirective in your httpd.conf file to list a non-root\n\tuser.\n

The mod_wsgi-express script should detect this case itself and instead output an error message first stating that when being run as root that the --user and --group options should be supplied. That way users don't get to see Apache's own nasty message and get worried of specific think that mod_wsgi express is doing something wrong.

mod_wsgi - mod_wsgi-express error AH00526: Syntax error on line 16

This question is related with my question.

Actually I use the Apacha Version over Ubuntu 14.04 LTS 64bits:
Server version: Apache/2.4.7 (Ubuntu)
Server built: Jul 22 2014 14:36:38

When I type command mod_wsgi-express start-server to check if it runs. It seems not running and I have an error:

root@website:/home/website# mod_wsgi-express start-server
Server URL        : http://localhost:8000/
Server Root       : /tmp/mod_wsgi-localhost:8000:0
Server Conf       : /tmp/mod_wsgi-localhost:8000:0/httpd.conf
Error Log File    : /tmp/mod_wsgi-localhost:8000:0/error_log
AH00526: Syntax error on line 16 of /tmp/mod_wsgi-localhost:8000:0/httpd.conf:
Error:\tApache has not been designed to serve pages while\n\trunning as root.  There are known race conditions that\n\twill allow any local user to read any file on the system.\n\tIf you still desire to serve pages as root then\n\tadd -DBIG_SECURITY_HOLE to the CFLAGS env variable\n\tand then rebuild the server.\n\tIt is strongly suggested that you instead modify the User\n\tdirective in your httpd.conf file to list a non-root\n\tuser.\n

I have the same problem during installation to doom. Any suggest is welcome!

More Information:

Modules used in Apache:

Compiled in modules:
  core.c
  mod_so.c
  mod_watchdog.c
  http_core.c
  mod_log_config.c
  mod_logio.c
  mod_version.c
  mod_unixd.c

Python Version:

>>> print (sys.version) 
2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2]

mod_wsgi-4.2.7 doesn't compile with Python 2.4

I was trying to install mod_wsgi-4.2.7 from source using Python 2.4, And It fails at during make execution.
Also, It works with Python 2.7 just fine.

Are these versions incompatible by design or it's bug?
Can someone please look into it?

This is the log it generates:

./configure --with-python=/usr/bin/python2.4 --with-apxs=/usr/sbin/apxs

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for prctl... yes
checking Apache version... 2.2.3
configure: creating ./config.status
config.status: creating Makefile
make

/usr/sbin/apxs -c -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE  -Wc,-g -Wc,-O2  src/server/mod_wsgi.c src/server/wsgi_*.c -L/usr/lib -L/usr/lib/python2.4/config  -lpython2.4 -lpthread -ldl  -lutil -lm
/usr/lib/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fno-strict-aliasing  -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I/usr/include/httpd  -I/usr/include/apr-1   -I/usr/include/apr-1  -g -O2 -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE  -c -o src/server/mod_wsgi.lo src/server/mod_wsgi.c && touch src/server/mod_wsgi.slo
src/server/mod_wsgi.c: In function 'wsgi_log_stack_traces':
src/server/mod_wsgi.c:8107: warning: implicit declaration of function '_PyThread_CurrentFrames'
src/server/mod_wsgi.c:8107: warning: assignment makes pointer from integer without a cast
src/server/mod_wsgi.c:8118: error: 'Py_ssize_t' undeclared (first use in this function)
src/server/mod_wsgi.c:8118: error: (Each undeclared identifier is reported only once
src/server/mod_wsgi.c:8118: error: for each function it appears in.)
src/server/mod_wsgi.c:8118: error: expected ';' before 'i'
src/server/mod_wsgi.c:8124: error: 'i' undeclared (first use in this function)
apxs:Error: Command failed with rc=65536
.
make: *** [src/server/mod_wsgi.la] Error 1

Invalid argument error in mod_wsgi 4.1

I'm getting a '503 Service Unavailable' with the following error in the ErrorLog when connecting to the wsgi app:

(22)Invalid argument: mod_wsgi (pid=22944): Unable to connect to WSGI daemon process 'localhost:8000' on '/tmp/mod_wsgi-localhost:8000:12145/wsgi.22942.0.1.sock'

I'm running mod_wsgi-4.1.1 + python 2.7.6 + apache 2.2.15 + Linux 2.6.32 x86_64

I started a simple hello world app using mod_wsgi-express:

mod_wsgi-express start-server hello.wsgi

I checked that the sock file exist and has rwx permission by the owner.

Restrictions on amount of response data buffered in Apache child worker processes.

When using mod_wsgi daemon mode, when the Apache child worker process is proxying the response it simply copies the response from the socket and writes it back through the output filter chain. If the HTTP client is slow and isn't reading the response quick enough, then technically this might mean that data gets buffered up in the Apache child worker processes and the proxying code isn't detecting when it is being buffered and forcing a flush when a limit is reached. Thus the per thread memory pool used by Apache grows and not sure if Apache internal applies a limit and forces thing to block until HTTP client has read more. If MaxMemFree isn't set or is large, then that memory will also be retained just by that thread and so can cause unnecessary overall memory usage by the process.

Make response header size limit for daemon mode configurable.

The ap_scan_script_header_err_core_ex() function util_script.c in Apache is used to scan response headers from daemon mode processes. This enforces a fixed limit on the size of the response header values.

This cause a problem for OpenStack keystone which can generate authentication tokens which are longer.

Lift the size limit and/or make it configurable so can be set to be larger.

Record mod_wsgi express command line in apachectl.

When running setup-server or start-server, record the original command line from sys.argv as a comment at the top of apachectl so that one can determine later what command was used to create the configuration.

The home option is adding empty string to sys.path rather than the actual directory.

When the mod_wsgi core was changed to update sys.path when the home option was given to WSGIDaemonProcess so that directory was also searched, a short cut was done of just adding in the empty string. The problem with this is that it only works so long as the current working directory isn't changed.

In order to mirror what happens when you use python script.py, it should be adding the actual absolute directory so that it will always be searched, even if the current working directory changes.

Reference counting errors in wsgi_hook_check_user_id() etc.

In wsgi_hook_check_user_id(), wsgi_check_password(), wsgi_get_realm_hash(), wsgi_groups_for_user() and wsgi_allow_access() there appear to be bugs in the way that reference counting is handled for the object variable.

Initialisation occurs as:

        object = PyDict_GetItemString(module_dict, "load_session");

This is a borrowed reference, yet have:

            adapter = newHandlerObject(r, rconfig);

            if (adapter) {
            }
            else
                Py_DECREF(object);

Technically creating the handler object shouldn't fail, but if it did, then we would decrement reference on borrowed reference.

Next problem is that have:

                /* Close the log object so data is flushed. */

                method = PyObject_GetAttrString(adapter->log, "close");

                if (!method) {
                    PyErr_Format(PyExc_AttributeError,
                                 "'%s' object has no attribute 'close'",
                                 adapter->log->ob_type->tp_name);
                }
                else {
                    args = PyTuple_New(0);
                    object = PyEval_CallObject(method, args);
                    Py_DECREF(args);
                }

                Py_XDECREF(object);
                Py_XDECREF(method);

If there was no close() on the handler object, then the object variable wouldn't have been overridden, yet we try and decrement reference.

Technically the handler object will always have a close(), but if it didn't for some read, would decrement on borrowed reference.

mod_wsgi 4.2.8 install fails with Python 3.4 on OSX 10.9.4

If I do pip install mod_wsgi in my virtualenv I get this error:

error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.8" but "10.9" during configure

If I instead pip install mod_wsgi==4.2.7, it installs without issue.

P.S. Thanks for all your work! Just saw your blog posts discussing the current state of mod_wsgi and excited to try the new features. Had no idea it was a simple pip install away. Cheers!

Destroy memory pools and shutdown aprlib on process exit.

In various situations mod_wsgi currently simply calls exit() to kill the process. This means it doesn't destroy Apache memory pools and allow any cleanup functions to be called. This may mean that Apache modules could crash on shutdown if they had finalisers (such as C++ global object destructors) which expect the memory pool cleanup to have occurred.

Example of where this may be the case is discussed in:

In Apache itself, rather than just call exit() is actually does:

    /*
     * Register a cleanup in the config apr_pool_t (normally pconf). When
     * we do a restart (or shutdown) this cleanup will cause the
     * shared object to be unloaded.
     */
    apr_pool_cleanup_register(cmd->pool, modi, unload_module, apr_pool_cleanup_null);


int main(…) {
    …

    destroy_and_exit_process(process, 0);

    return 0; /* Termination 'ok' */
}

static void destroy_and_exit_process(process_rec *process,
                                     int process_exit_value)
{
    /*
     * Sleep for TASK_SWITCH_SLEEP micro seconds to cause a task switch on
     * OS layer and thus give possibly started piped loggers a chance to
     * process their input. Otherwise it is possible that they get killed
     * by us before they can do so. In this case maybe valueable log messages
     * might get lost.
     */
    apr_sleep(TASK_SWITCH_SLEEP);
    apr_pool_destroy(process->pool); /* and destroy all descendent pools */
    apr_terminate();
    exit(process_exit_value);
}

Need to look at whether mod_wsgi needs to do something similar, destroying the main process pool and then calling apr_terminate() before exiting.

Bootstrap issue when loading mod_wsgi

Recently I started looking into mod_wsgi running under Windows (Apache/2.2.22). The issue I'm facing is:

  • I wish to run against a specific Python version, installed along with my app, in a given directory
  • I do not want to depend on a PATH variable, or the presence of a python27.dll in C:\Windows\System32 or C:\Windows\SysWOW64
  • However, in order for mod_wsgi to load, it (seems to) need this dll, because when I copy the dll to the Apache bin directory, Apache can load the module. If the dll is not there, I end up with exactly the issue described earlier (#272 on the old tracker).
  • Because the module itself can not be loaded, it is also impossible to use the WSGIPythonHome directive

I would expect to be able to load the module (without having a dependency on python27.dll), and only after it has been loaded, have the WSGIPythonHome directive determine which Python installation to use.

I haven't tried building a static version of the module, which presumably would get me out of this circular dependency. But that really is not the direction I like to take. Is there another way out?

Compiling on OS X Yosemite ..

./apxs -c -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -Wc,-g -Wc,-O2 -Wc,'-arch x86_64' src/server/mod_wsgi.c src/server/wsgi__.c -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -arch x86_64 -lpython2.7 -ldl -framework CoreFoundation
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/mod_wsgi.lo src/server/mod_wsgi.c && touch src/server/mod_wsgi.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_apache.lo src/server/wsgi_apache.c && touch src/server/wsgi_apache.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_buckets.lo src/server/wsgi_buckets.c && touch src/server/wsgi_buckets.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_convert.lo src/server/wsgi_convert.c && touch src/server/wsgi_convert.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_daemon.lo src/server/wsgi_daemon.c && touch src/server/wsgi_daemon.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_interp.lo src/server/wsgi_interp.c && touch src/server/wsgi_interp.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_logger.lo src/server/wsgi_logger.c && touch src/server/wsgi_logger.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_metrics.lo src/server/wsgi_metrics.c && touch src/server/wsgi_metrics.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_restrict.lo src/server/wsgi_restrict.c && touch src/server/wsgi_restrict.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_server.lo src/server/wsgi_server.c && touch src/server/wsgi_server.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_stream.lo src/server/wsgi_stream.c && touch src/server/wsgi_stream.slo
./libtool --silent --mode=compile /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -I/usr/include/apache2 -I/usr/include/apr-1 -I/usr/include/apr-1 -g -O2 -arch x86_64 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apr-1/ -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/apache2/ -DENABLE_DTRACE -DMACOSX -DNDEBUG -DNDEBUG -DENABLE_DTRACE -c -o src/server/wsgi_validate.lo src/server/wsgi_validate.c && touch src/server/wsgi_validate.slo
./libtool --silent --mode=link /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -o src/server/mod_wsgi.la -rpath /usr/libexec/apache2 -module -avoid-version src/server/wsgi_validate.lo src/server/wsgi_stream.lo src/server/wsgi_server.lo src/server/wsgi_restrict.lo src/server/wsgi_metrics.lo src/server/wsgi_logger.lo src/server/wsgi_interp.lo src/server/wsgi_daemon.lo src/server/wsgi_convert.lo src/server/wsgi_buckets.lo src/server/wsgi_apache.lo src/server/mod_wsgi.lo -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -arch x86_64 -lpython2.7 -ldl -framework CoreFoundation
./libtool: line 8962: /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.10.xctoolchain/usr/bin/cc: No such file or directory
apxs:Error: Command failed with rc=8323072
.
make: *_* [src/server/mod_wsgi.la] Error 1

madhus-MacBook-Pro:mod_wsgi-4.2.1 madhu$ ls

Added a few includes in makefile as it is searching for it. Not sure what to do with libtool looking for cc in wrong directory, editing apxs doesn't seem like a good option. Any suggestions?

Backport header spoofing changes to mod_wsgi 3.X.

Change is:

This blocks passing of headers which characters in name other than alpha numerics and '-'.

There are two parts to this.

Fix the Apache 2.4 authnz problems where it could occur even though it was okay for the WSGI application due to Apache 2.4 itself doing it.

Apply the restriction to Apache 2.2.

Add a --application-type option to allow module and Paste ini for application.

Right now mod_wsgi express accepts a UNIX file system path to a WSGI script file. It does not allow you to specify a Python module to be imported.

Add a --application-type option, which defaults to 'script', which can then be set to either 'module' or 'paste'.

For 'module' mod_wsgi express would organise for that module, which would contain the WSGI application entry point, to be loaded and used for the WSGI application.

For 'paste', it would interpret the the file as a Paste .ini file, with application pipeline being setup in it, and load and use it.

mod_wsgi for Python 2 as well as Python 3 on one Apache server.

Currently we run mod_wsgi compiled against Python 2 (installed through the Ubuntu package manager). I just realised the Python 3 package for mod_wsgi can not be installed at the same time because the module name and apache directives would conflict. Is there a possibility to have two versions of mod_wsgi, one for python 2 and one for python3, on the same apache server?

Silent Limit of 107 Characters on Socket Path causes Weird Errors

Due to the UNIX_PATH_MAX defined on the struct sockaddr_un:

#define UNIX_PATH_MAX    108

struct sockaddr_un {
    sa_family_t sun_family;               /* AF_UNIX */
    char        sun_path[UNIX_PATH_MAX];  /* pathname */
};

There is a limit of 107 (108 including the null byte) on the length of a path for a socket - but when the bind is called, the silently truncated path starts causing problems, and you start seeing -1 EADDRINUSE (Address already in use) errors in the strace.

This happens when WSGISocketPrefix is set to a path that might be shorter than 107 characters, but can be longer once the extra information is added (like pid and extension). However the log outputs the full path when it says it can't bind to the socket. As a result, Apache just hangs when talking to WSGI.

This only affects Daemon mode.

While the underlying system can't be changed, it'd probably be useful to somehow catch this weird edge case.

Here's the strace output if you're curious:

$ strace -f ./bin/apache
...
7619  bind(8, {sa_family=AF_FILE, path="/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/ws"}, 110) = -1 EADDRINUSE (Address already in use)
7619  unlink("/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgitest.7619.0.1.sock") = -1 ENOENT (No such file or directory)
7619  bind(8, {sa_family=AF_FILE, path="/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/ws"}, 110) = -1 EADDRINUSE (Address already in use)
7633  connect(11, {sa_family=AF_FILE, path="/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/ws"}, 110) = -1 ECONNREFUSED (Connection refused)
...

And the log:

src/server/mod_wsgi.c(7267): mod_wsgi (pid=7370): Socket for 'graphite-w-otsdb' is '/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgi.7370.0.1.sock'.
(98)Address already in use: mod_wsgi (pid=7370): Removing stale unix domain socket '/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgi.7370.0.1.sock'.
(98)Address already in use: mod_wsgi (pid=7370): Couldn't bind unix domain socket '/some-really-long-path-that-hits-a-linux-max-and-that-also-happens-to-include-a-gitsha-digest/apache/run/wsgi.7370.0.1.sock'.

cannot find -lpython

I am trying to install mod_wsgi into a virtualenv with Python 2.7.6 and setuptools 3.6 (but otherwise empty).

pip install mod_wsgi dies with ...

/usr/bin/ld: cannot find -lpython

I am working around this via ...

diff --git a/setup.py b/setup.py
index 09ad4040..27de7ff5 100644
--- a/setup.py
+++ b/setup.py
@@ -88,7 +88,7 @@ with open(os.path.join(os.path.dirname(__file__),
 # Work out location of Python library and how to link it.

 PYTHON_VERSION = get_python_config('VERSION')
-PYTHON_LDVERSION = get_python_config('LDVERSION') or ''
+PYTHON_LDVERSION = get_python_config('LDVERSION') or PYTHON_VERSION

 PYTHON_LIBDIR = get_python_config('LIBDIR')
 PYTHON_CFGDIR =  get_python_lib(plat_specific=1, standard_lib=1) + '/config'

... but I don't know if that's correct for all versions of Python and setuptools. My distutils.sysconfig doesn't seem to define LDVERSION, but it does (I think correctly) define VERSION as '2.7'.

Support for chunked request encoding in daemon mode.

Chunked request content is actually not allowed by the WSGI specification.

The mod_wsgi does provide the:

WSGIChunkedRequest On

option for enabling a non WSGI specific feature to allow it, but a web application would still need to technically violate the WSGI specification to make use of it by way of ignoring CONTENT_LENGTH on the request.

Although this works in embedded mode, it doesn't work in daemon mode of mod_wsgi. To have it work in daemon mode will entail a bit of work which has been previously discussed in:

In implementing it, should also chase down proposal by Armin Ronacher of how a WSGI server could flag that chunked request content was supported and being used.

unable to compile /mod_wsgi-develop

followed the instructions here but I am getting this error:

copying src/server/apxs_config.py -> build/lib.linux-x86_64-2.6/mod_wsgi/server
running build_ext
building 'mod_wsgi.server.mod_wsgi-py26' extension
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fwrapv -fPIC -I/usr/include/apache2 -I/usr/include/python2.6 -c src/server/wsgi_logger.c -o build/temp.linux-x86_64-2.6/src/server/wsgi_logger.o -I/usr/include/apache2 -I. -I/usr/include/apr-1 -DSSL_EXPERIMENTAL_ENGINE -DMAX_SERVER_LIMIT=200000 -DLDAP_DEPRECATED -DMAXLINE=4096 -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC -Wall -fno-strict-aliasing -DLDAP_DEPRECATED -pthread
In file included from src/server/wsgi_apache.h:74,
from src/server/wsgi_logger.h:25,
from src/server/wsgi_logger.c:21:
/usr/include/apache2/mpm_common.h:46:17: error: mpm.h: No such file or directory
error: command 'gcc' failed with exit status 1

Any ideas?

group authorization not working

Hello,

I followed https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/apache-auth/ to restrict the access to a webdav shared directory only to users belonging to "DI" group (a group on a django project's database), and ended up with the following apache directives:

LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_lock_module modules/mod_dav_lock.so
LoadModule wsgi_module modules/mod_wsgi.so

<Directory />
    AllowOverride none
    Require all denied
</Directory>

<Directory "/srv/http">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Alias /dav /srv/http/dav

WSGIScriptAlias / /path/to/django/project/projectname/wsgi.py
WSGIPythonPath /path/to/django/project/
WSGIProcessGroup %{GLOBAL}
WSGIApplicationGroup django

DavLockDB /http/.davlockdb

<Location "/dav">
  Dav On
  AuthType Basic
  AuthName "Top Secret"
  AuthBasicProvider wsgi
  WSGIAuthUserScript /path/to/django/project/projectname/wsgi.py
  WSGIAuthGroupScript /path/to/django/project/projectname/wsgi.py
  Require wsgi-group DI
  Require valid-user
</Location>

However, when I access to the dav directory with a webdav client authenticating with a user that doesn't belong to DI group, it anyway can read and write. Apache's error_log, multiple times, says:

mod_wsgi (pid=5815): Authorization of user '(null)' to access '/dav/' failed. User is not a member of any groups.
mod_wsgi (pid=5815): Authorization of user 'prov2' to access '/dav/' failed. User is not a member of designated groups.

Note that it always first says something about a "null" user, then it shows the right username, in this case prov2. As I said, prov2 doesn't belong to DI group on django database.

On the Require line, I wrote 'wsgi-group' instead of just 'group'. If I switch it to group, then the apache error_log says: "AH01664: No group file was specified in the configuration", but the user is still allowed to read and write on dav directory.

My goal is only to allow users belonging to a specific group on django project's database to read and write on this directory... what could be wrong?

My setup is:
apache: 2.4.10-1
mod_wsgi: 3.5-1
python: 3.4.1-1
django: 1.8 (dev)

Greetings,
H.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.