How to deploy django application on OS X Server?

Question

How can I deploy a Django application on OS X Server 2.0 without using homebrew or another python flavor than the one that comes with OS X 10.8.1? I use cocoa bindings in a Django application and cannot get it to work with homebrew on my desktop computer (works with OS X 10.8.1); therefore, a request to deploy the application on the installed Python version system.

I have the following OS X Server environment with the following already installed:

• OS X 10.8.1
• OS X Server 2.0
• Python 2.7.2
• Apache 2.2.22

Django 1.4.1 was installed using the following command:

sudo easy_install django 

My first attempt is to deploy an empty website, and once that succeeds, deploy the real application that will be used in production. The project was created in /Library/Server/Web/Data/WebApps/mysite/ using the following command

 django-admin.py startproject mysite 

I launched the application using the following command. He simply confirmed that the application was running. This is the standard "It worked!" when you first created the project.

 python manage.py runserver 8080 

Then I created the file /Library/Server/Web/Config/apache2/httpd_mysite.conf with the following contents:

 WSGIScriptAlias /mysite /Library/Server/Web/Data/WebApps/mysite/mysite/wsgi.py 

I also created the file /Library/Server/Web/Config/apache2/webapps/com.example.mysite.wsgi.plist with the following contents:

 <?xml version="1.0" encoding="UTF-7"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>name</key> <string>com.example.mysite.wsgi</string> <key>displayName</key> <string>Python "My Site" app</string> <key>launchKeys</key> <array/> <key>proxies</key> <dict/> <key>installationIndicatorFilePath</key> <string>/Library/Server/Web/Data/WebApps/mysite/mysite/wsgi.py</string> <key>includeFiles</key> <array> <string>/Library/Server/Web/Config/apache2/httpd_mysite.conf</string> </array> <key>requiredModuleNames</key> <array> <string>wsgi_module</string> </array> </dict> </plist> 

The com.example.mysite.wsgi.plist file was adapted from com.apple.webapp.wsgi.plist and httpd_mysite.conf adapted from httpd_wsgi.conf . Both of these files are used to successfully launch a "stand-alone" python application when configured using the server manager.

Then I created a site with a server manager, confirmed that my application was on the list of web applications. However, when I am http://example.com/mysite , I get a 500 error. The logs have the following entries (IP addresses changed to 1.2.3.4):

 [Sat Sep 01 21:49:17 2012] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366) [Sat Sep 01 21:49:17 2012] [notice] Apache/2.2.22 (Unix) PHP/5.3.13 with Suhosin-Patch mod_wsgi/3.3 Python/2.7.2 mod_fastcgi/2.4.6 mod_ssl/2.2.22 OpenSSL/0.9.8r DAV/2 configured -- resuming normal operations [Sat Sep 01 21:50:13 2012] [error] [client 1.2.3.4] (8)Exec format error: exec of '/Library/Server/Web/Data/WebApps/mysite/mysite/wsgi.py' failed [Sat Sep 01 21:50:13 2012] [error] [client 1.2.3.4] Premature end of script headers: wsgi.py 

It does not look like the WSGI module is processing the request, but instead the request can be processed using FCGI. However, the log shows that mod_wsgi/3.3 was loaded.

When I created a standard Python application that looks like this:

 def application(environ, start_response): status = '200 OK' output = 'Hello World!' response_headers = [('Content-type', 'text/plain'), ('Content-Length', str(len(output)))] start_response(status, response_headers) return [output] 

And update the files to point to /Library/Server/Web/Data/WebApps/helloworld.wsgi , not to /Library/Server/Web/Data/WebApps/mysite/mysite/wsgi.py , after which it will display "Hello World " Therefore, I assume that wsgi is correctly configured and able to run applications, and that something else is wrong with my setup.

Answer 1

Some Apache configurations with map.py distribution for CGI or FASTCGI, and this will contradict mod_wsgi. This is why mod_wsgi recommends using the .wsgi extension. So rename 'wsgi.py' to 'site.wsgi' and then use 'site.wsgi' in WSGIScriptAlias.

By the way, you can confirm that there is a precompiled mod_wsgi.so sent with the Mountain Lion server.

Answer 2

I found myself struggling to migrate my macports django to Mountain Lion Server 10.8.2, and for some reason the answers here helped me remember the differences of mod_wsgi.so.

I overwrote /Applications/Server.app/Contents/ServerRoot/usr/libexec/apache2/mod_wsgi.so with my / opt / local / apache 2 / modules / mod_wsgi.so.

I was hoping to completely remove MacPorts apache2, but I think it's better to support it. I still prefer MacPorts Python at the moment, as it is easier to update numerically intensive packages.

Yes, also make sure you change wsgi.py to wsgi.wsgi.

I copied httpd_wsgi.conf to httpd_mywsgi.conf; I added django.wsgi to / Library / Server / Web / Data / WebApps.
In / Library / Server / Web / Config / apache 2 / webapps, I copied the file com.apple.webapp.wsgi.plist.

It looks like you have chosen the same plist template.

I am still developing my static content, however I thought that finding mod_wsgi.so might help someone else migrate from MacPorts.

Answer 3

Two things:

• If you want to use the WSGIScriptAlias ​​directive, you need to have the mod_wsgi apache module. I do not have an OS X server, but as far as I can see, the module does not exist in the / usr / libexec / apache 2 folder on the mountain lion standard. You will need to download it from here . I don’t know if the command line tools are enabled on the OS X server. I need to install the X code to get them on the standard version. There seems to be instructions on how to install it on macos x

• Take a look at Homebrew . This is a great way to add additional software for Mac. In a twist, you can install the latest python, nginx and uwsgi. Nginx and uwsgi are a great way to deploy django applications. I find it more flexible and efficient than mod_wsgi (this second point is very subjective).

Good luck.