Debian Etch: Django, mod_wsgi, Apache2 => 500er Server Er

[macroslk]

Hi,

nachdem ich inzwischen Stunden und zig Installation-Anleitungen durchforstet habe, und meine Installation leider immernoch nicht zum laufen kriege, hoffe, ich, dass hier jemand eine Lösung findet.

Ich erhalte immer ein 500 Internal Server Error.

Meine Server-Konstellation ist folgende:
- Debian Etch
- Python 2.5
- Apache2
- mod_wsgi
- Mysql5

Auf dem Server laufen übrigens parallel PHP5 Projekte.

Meine Configs sehen so aus:
(Ich habe die IP-Adresse mit 111.222.333.444 und den Domainnamen mit meinedomain.de ersetzt.)

Ausschnitt aus der vhost.conf:

Code: Alles auswählen

<VirtualHost 111.222.333.444:80>
  ServerName meinedomain.de
  ServerAlias www.meinedomain.de
  ServerAdmin serveradmin@meinedomain.de
  ErrorLog "/opt/log/error.log"
  CustomLog "/opt/log/access.log" combined
  LogLevel debug
         Alias /admin/media /usr/lib/python2.5/site-packages/django/contrib/admin/media
         <Location /usr/lib/python2.5/site-packages/django/contrib/admin/>
               Order allow,deny
                Allow from all
        </Location>

        WSGIScriptAlias / /opt/www/testproject/wsgi_handler.py
        <Directory /opt/www/testproject/>
                Order deny,allow
                Allow from all
        </Directory>

        WSGIDaemonProcess www.meinedomain.de user=pywww group=pywww processes=1 threads=10
        WSGIProcessGroup www.meinedomain.de
</VirtualHost>

/opt/www/testproject/wsgi_handler.py:

Code: Alles auswählen

import sys
import os

sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')
os.environ['DJANGO_SETTINGS_MODULE'] = 'testproject.settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

In der Error-Logdatei steht bei Loglevel Debug folgendes beim Restart vom Apache und erstem Aufruf der Seite:

Code: Alles auswählen

Fri Nov 28 13:34:27 2008] [info] mod_wsgi (pid=25531): Shutdown requested 'www.meinedomain.de'.
[Fri Nov 28 13:34:27 2008] [info] mod_wsgi (pid=25531): Stopping process 'www.meinedomain.de'.
[Fri Nov 28 13:34:27 2008] [info] mod_wsgi (pid=25531): Cleanup interpreter ''.
[Fri Nov 28 13:34:27 2008] [info] mod_wsgi (pid=25531): Terminating Python.
[Fri Nov 28 13:34:30 2008] [info] mod_wsgi (pid=25597): Attach interpreter ''.
[Fri Nov 28 13:34:30 2008] [info] mod_wsgi (pid=25597): Enable monitor thread in process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8301): mod_wsgi (pid=25597): Deadlock timeout is 300.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8304): mod_wsgi (pid=25597): Inactivity timeout is 0.
[Fri Nov 28 13:34:30 2008] [info] mod_wsgi (pid=25597): Enable deadlock thread in process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8449): mod_wsgi (pid=25597): Starting 10 threads in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 1 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 2 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 3 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 4 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 5 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 6 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 7 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 8 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 9 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:30 2008] [debug] mod_wsgi.c(8455): mod_wsgi (pid=25597): Starting thread 10 in daemon process 'www.meinedomain.de'.
[Fri Nov 28 13:34:34 2008] [debug] mod_cache.c(129): Adding CACHE_SAVE filter for /
[Fri Nov 28 13:34:34 2008] [debug] mod_cache.c(136): Adding CACHE_REMOVE_URL filter for /
[Fri Nov 28 13:34:34 2008] [info] mod_wsgi (pid=25597): Create interpreter 'meinedomain.de|'.
[Fri Nov 28 13:34:34 2008] [debug] mod_cache.c(129): Adding CACHE_SAVE filter for /favicon.ico
[Fri Nov 28 13:34:34 2008] [debug] mod_cache.c(136): Adding CACHE_REMOVE_URL filter for /favicon.ico

Der User pywww existiert, hat aber kein Homeverzeichnis. Wobei es auch ohne der Userdefinition nicht funktioniert.

Das Projekt "testproject" ist ein komplett neu angelegtes Projekt (mit "django-admin.py startproject testproject") ohne jegliche Anpassungen.

Was ich noch nicht überprüft habe, sind die Rechte. Leider weiß ich nicht, auf welchen User bzw. mit welchen Rechten man diese in dem Fall setzen muss.

Hat jemand eine Idee, woran es liegen könnte, dass ich einen 500er Internal Server Error bekommen?

Besten Dank schonmal im Voraus!

[ferix]

Ich hatte das Problem bei der Umsetzung mit FastCGI.

Da hing es an den Zugriffsrechten des Projektverzeichnisses und der fcgi-File.

chmod o+rx wsgi_handler.py
chmod o-rw+x projekt

Entnommen aus der folgendem Tutorial: http://www.icoost.com/programmiersprach ... nd-apache/

Allerdings weiß ich nicht, ob das des Rätsels Lösung wäre, da ich wie gesagt nur Erfahrung mit FastCGI habe.

[macroslk]

Vielen Dank für die Antwort.

Leider war das nicht des Rätsels Lösung.
Keine Veränderung - auch nicht in den Logs.
Immer noch der 500 Internal Server Error.

[nemomuk]

Nutzt du suexec?

[Y0Gi]

Im Log sehe ich keine Fehlermeldung, die einem 500 entsprechen könnte - fehlt da was?

Hast du mal das Script direkt ausgeführt? Das klappt je nach erforderlichen Umgebungsvariablen und anderen Faktoren nur bedingt, schließt aber zumindest einige Fehlerklassen aus. Scheint mir sowas aber auch sauber zu starten.

Hier ein WSGI-bezogener Auszug aus einer meiner Configs:

Code: Alles auswählen

AliasMatch ^/(((behaviour|download|images|style)/.*)|robots\.txt)$ /var/www/www.example.com/public/$1
WSGIApplicationGroup example
WSGIDaemonProcess www.example.com user=example group=example threads=4 \
    python-path=/var/www/www.example.com/lib/python2.5/site-packages \
    home=/var/www/www.example.com
WSGIPassAuthorization On
WSGIProcessGroup www.example.com
WSGIScriptAlias / /var/www/www.example.com/serve.wsgi

Dabei setze ich Apache 2.2, mod_wsgi 2.3 sowie virtualenv ein.

[macroslk]

Ich verwende kein suexec.
Übrigens verwende ich auch kein virtualenv.

Du meinst, die URL zur wsgi_handler.py Datei direkt aufrufen?
Klappt leider auch nicht.

Im Apache Access-Log tauch nur diese Meldung auf:

Code: Alles auswählen

"GET / HTTP/1.1" 500 545 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; de-de) AppleWebKit/525.26.2 (KHTML, like Gecko) Version/3.2 Safari/525.26.12"
"GET /favicon.ico HTTP/1.1" 500 545 "http://www.meinedomain.de/" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; de-de) AppleWebKit/525.26.2 (KHTML, like Gecko) Version/3.2 Safari/525.26.12"

Hat jemand vielleicht eine Idee, wie ich den 500er Error besser debuggen könnte? Momentan weiß ich ja noch nicht was ganz genau der verursacher ist.

[Leonidas]

Nein, es ging darum, das Skript selbst, via Interpreter auszuführen.

[macroslk]

Also ein Aufruf auf der Console direkt gibt keine Fehler.

Aber ich habe grade eine Neuerung.
Nachdem ich die beiden Definitionen in der vhost.conf für das ErrorLog rausgenommen habe, bekomme ich in der normalen Apache-Errorlog folgende Meldungen:

Code: Alles auswählen

[error] mod_wsgi (pid=26530): Exception occurred processing WSGI script '/opt/www/testproject/wsgi_handler.py'. [error] Traceback (most recent call last):
 [error] [client 77.191.40.216]   File "/usr/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 228, in __call__
 [error] [client 77.191.40.216]   File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py", line 40, in load_middleware
 [error] [client 77.191.40.216] ImproperlyConfigured: Error importing middleware django.middleware.common: "No module named common"
 [error] [client 77.191.40.216] mod_wsgi (pid=26530): Exception occurred processing WSGI script '/opt/www/testproject/wsgi_handler.py'.
 [error] [client 77.191.40.216] Traceback (most recent call last):
 [error] [client 77.191.40.216]   File "/usr/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 239, in __call__
 [error] [client 77.191.40.216]   File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py", line 128, in get_response
 [error] [client 77.191.40.216]   File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py", line 141, in handle_uncaught_exception
 [error] [client 77.191.40.216] ImportError: No module named mail

Ich habe mal etwas recherchiert. Eigentlich sollte das Logging-Problem mit der Error-Logdefinition im Vhost-Bereich nur bei der 1er Version von mod_wsgi auftauchen. Nachdem nicht bekannt war, wann das auftritt und wann nicht, wird der Fehler wohl doch noch vorhanden sein.
Wie dem auch sei: Jetzt gibt es wenigsten konkrete Anhaltpunkte.

Hat jemand eine Idee, woran's nun hängt?

[Leonidas]

Django falsch installiert?

[macroslk]

Interessanterweise funktionert auf der python-Konsole ein "import django" einwandfrei.

Muss ich eventuell noch irgendwo in der WSGI-Config den Django-Pfad mit reinladen?

[Leonidas]

Interessanterweise funktionert auf der python-Konsole ein "import django" einwandfrei.

Das wird ja im Traceback auch gar nicht angemeckert, sondern django.middleware.common. Ich schätze mal dass du DJANGO_SETTINGS_MODULE nicht gesetzt hast. Siehe hier oder auch hier.

[macroslk]

In der wsgi_handler.py steht diese Zeile ja drin:
os.environ['DJANGO_SETTINGS_MODULE'] = 'testproject.settings'

Ich habe es jetzt aber auch mal in der Vhost-Config eingefügt.
Macht aber keinen Unterschied. Immernoch der selbe Fehler.

Gibt es eine Möglichkeit noch mehr Debugging Infos dazu zu erhalten?

[nemomuk]

Hast du Django per apt-get/aptitude aus dem Stable vonD ebian installiert? Wenn ja, dann installier es manuell... Da diese Version sehr veraltet ist.

[Leonidas]

Hast du Django per apt-get/aptitude aus dem Stable vonD ebian installiert?

Nein, hat er nicht, da Debian Django in den Ordner von ``python-support`` kopiert, siehe hier.

[macroslk]

Django hab ich mir aus dem SVN geholt.

Die WSGI Schnittstelle als solche funktioniert.
Herausgefunden habe ich das in dem ich in meiner wsgi_handler.py folgenden Code von dieser Seite (http://code.google.com/p/modwsgi/wiki/D ... Techniques) ganz am Schluss eingesetzt habe:

Code: Alles auswählen

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

    print >> environ['wsgi.errors'], "application debug #1"

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

    print >> environ['wsgi.errors'], "application debug #2"

    return [output]

Die Anzeige ist dann "Hello World".

So wie es aussieht scheint es an Django selbst zu liegen.
Mir fehlt allerdings noch der Anhaltspunkt, was die Ursache sein könnte.

Django selbst liegt in "/opt/framework/django-trunk/django/".
Ich hab für Django nen Symlink nach /usr/lib/python2.5/site-packages/django eingerichtet.

Meine WSGI relavanten Einträge in der vhost.conf sehen momentan so aus:

Code: Alles auswählen

        WSGIScriptAlias / /opt/www/mysite/wsgi_handler.py
        WSGIApplicationGroup meinedomain
        WSGIDaemonProcess meinedomain.de user=pywww group=pywww processes=1 threads=10 \
            python-path=/usr/lib/python2.5/site-packages \
            home=/opt/www/mysite
        WSGIProcessGroup meinedomain.de

    SetEnv DJANGO_SETTINGS_MODULE mysite.settings

Meine wsgi_handler.py sieht momentan so aus :

Code: Alles auswählen

import os, sys

# path is the parent directory of this script ('/opt/www' in this case)
path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

# we check for path because we're told to at the tail end of
# http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIReloadMechanism
if path not in sys.path:
    sys.path.append(path)

os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Allerdings macht es bei allen keinen Unterschied.
Das Problem ist also scheinbar nur noch bei Django selbst.

Ich mach jetzt einfach nochmal nen Sync und hol mir die aktuelle Revision aus dem SVN und installiert Django nochmal neu.

[macroslk]

So, das Ganze funktioniert nun - Satchmo auch. Nach langen Mühen...
Ich habe Django nochmal gesynct. Scheinbar lief der erste Sync nicht sauber.

Dann kam noch dazu, dass das python-mysql Modul noch gefehlt hat.
Da ich mod_wsgi aus Debian SID (=unstable) geholt habe (denn nur da gibt es das per apt-get) hatte ich das Problem, dass python-mysql Modul nicht installierbar war, weil die Programmversionen der erforderlichen Komponenten durch die vorher installation per apt-get nicht zusammenpassen.
Per apt-get lässt sich das Python-mysql Modul übrigens sowieso nur für Python 2.4 installieren.
Also musste ich das python-mysql modul manuell runterladen, die fehlenden Komponenten auch aus dem Debian SID holen. Dann konnte ich auch das Mysql Modul für Python installieren.

Also meine Empfehlung für alle anderen die Django unter Python nutzen wollen:

Solange es alle erforderlichen Komponenten nicht für Python 2.5 gibt. Lieber Python 2.4 installieren. Das erleichtert einiges.
Und das mod_wsgi nicht per apt-get installieren, sondern direkt herunterladen und manuell installieren.

Viel Erfolg noch allen

[Leonidas]

Anderer Tipp: Unter Etch einfach FastCGI nutzen. Ich habe Python 2.6 (Backports aus den Ubuntu-PPAs) + selbstkompiliertes psycopg2 (via easy_install) + Django aus dem Mercurial-Mirror. mod_wsgi ist schoen und gut, aber sobald man versucht Binaries aus Sid zu holen, hat man was falsch gemacht.

[macroslk]

Binaries ist SID zu holen war sicher nicht die geschickteste Handlung.
Allerdings ist soweit ich weiß der Weg über WSGI performanter als über FastCGI.

Aber sicher ist je nach Bedarf der eine oder andere Weg sinnvoller.

PS: Was ich an dieser Stelle noch erwähnen will, falls jemand die Entscheidung FastCGI, WSGI oder mod_python treffen möchte.
Mod_python ist nur für Python 2.4 verfügbar und bzgl. der Performance die ungünstigste Lösung.

[Y0Gi]

mod_wsgi ist schon seit Ewigkeiten in Lenny und einen Backport für Etch gibt es auch - so isses ja nu nich.

[Leonidas]

Binaries ist SID zu holen war sicher nicht die geschickteste Handlung.
Allerdings ist soweit ich weiß der Weg über WSGI performanter als über FastCGI.

Wenn da ein Unterschied besteht, dann ist der so marginal, dass man ihn wohl in aller Regel vernachlässigen kann. Ich schätze dass es eher andere Bottenecks geben wird.

Mod_python ist nur für Python 2.4 verfügbar und bzgl. der Performance die ungünstigste Lösung.

mod_python ist so ziemlich aus jeder Sicht die schlechteste Lösung, da ist der Weg über den mod_wsgi-Backport in Etch sinnvoller.