Das deutsche Python-Forum

Hallo zusammen,

ich möchte meine Django-Projekt gern bei Uberspace hosten, scheitere aber an der Einrichtung.

Ich bin der Anleitung auf https://lab.uberspace.de/guide_django/ gefolgt. Leider ist aber schon bei der Installation von gunicorn schluss.

> pip3.6 install gunicorn --user hat noch funktionier. Dann habe ich die Datei "~/etc/services.d/gunicorn.ini" angelegt und mit "

[Program:gunicorn]
command=gunicorn --error-logfile - --reload --chdir ~/MyDjangoProject --bind 0.0.0.0:8000 MyDjangoProject.wsgi:application

gefüllt.

Die beiden nächsten Eingaben haben funktioniert.

Nach supervisortctl status kam aber die Fehlermeldung "FATAL Exited too quickly (process log may have details)" (Im log steht: Error: can't chdir to '~/MyDjangoProject')

Ich habe dann noch den Ordner ~/MyDjangoProject' angelegt. (Mit > cd ~/MyDjangoProject kann ich auch in den Ordner wechseln.)

An der Fehlermeldung hat sich leider nichts geändert.

hier der ganze log vom letzten Versuch:

Error: can't chdir to '~/MyDjangoProject'

2022-11-21 11:04:15,442 DEBG fd 7 closed, stopped monitoring <POutputDispatcher at 140571134914784 for <Subprocess at 140571134758416 with name gunicorn in state STARTING> (stdout)>
2022-11-21 11:04:15,443 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 140571134914928 for <Subprocess at 140571134758416 with name gunicorn in state STARTING> (stderr)>
2022-11-21 11:04:15,443 INFO exited: gunicorn (exit status 1; not expected)
2022-11-21 11:04:15,444 DEBG received SIGCLD indicating a child quit
2022-11-21 11:04:16,445 INFO gave up: gunicorn entered FATAL state, too many start retries too quickly
2022-11-21 11:27:22,269 INFO spawned: 'gunicorn' with pid 23178
2022-11-21 11:27:22,617 DEBG 'gunicorn' stderr output:
[2022-11-21 11:27:22 +0100] [23178] [INFO] Starting gunicorn 20.1.0

Kann mir jemand sagen was ich falsch mache?

"~" steht unter Linux für das Heimatverzeichnis des Benutzers und das wird von der Shell automatisch durch diesen Pfad ersetzt: Diese Ersetzung funktioniert aber nicht überall ausserhalb der Shell, und es kommt auch immer auf das Benutzerkonto an unter dessen Rechten ein Programm ausgeführt wird, ich würde da komplette Pfade angeben.

Und dann ist das in der Anleitung etwas komisch von der Reihenfolge her, dass dort erst gunicorn installiert und konfiguriert wird, und *gestartet* wird, und *danach* erst die Beschreibung kommt wie das Djangoprojekt angelegt wird, welches mit gunicorn ausgeführt werden soll. Wenn man der Anleitung in der Reihenfolge nachgeht, muss das erste Starten von gunicorn mit einem angegebenen aber noch gar nicht existierenden Djangoprojekt zwangsläufig zu einem Fehler führen.

Vielen Dankf für die Info. Ich werde es heute Abend mit dem kompletten Pfad versuchen (und die Anleitung schon mal bis zum Ende durchlesen

Das hat leider auch nicht funktioniert. Ich habe jetzt eine Mail an den Suport von Uberspace geschickt. Die sollten mir helfen können. Sobale ich eine Lösung habe, werde ich sie hier mitteilen.

Ich bin einen Schritt weiter. Wenn ich in den Ordner wechsel in dem die Datei manage.py liegt, kann ich mit:

gunicorn --error-logfile - --reload --bind 0.0.0.0:8000 MyDjangoProject.wsgi:application (also ohne chdir)

gunicorn starten. Was ich damit mache, weiß ich noch nicht. Werde ich aber rausfinden.

Der Suport von Uberspace war für mich keine Hilfe. Auf die Idee in das Verzeichnis von manage.py zu wechseln, bin ich hier gekommen: https://docs.gunicorn.org/en/stable/run.html#gunicorn

Hallo,

korrekt, der Befehl
erwartet, dass die Datei `MyDjangoProject.wsgi` Verzeichnis liegt, wo man den Befehl ausführt. Wenn das nicht der Fall ist, dann muss man für die Datei entweder eine relativen oder absoluten Pfad setzen oder in das Verzeichnis der Datei wechseln. Letzteres sollte gehen, wenn du in die Direktiven für supervisorctl `directory=~/MyDjangoProject` einbaust.

Der Befehl `gunicorn` bewirkt, dass dein Django-Projekt auf Port 8000 des Servers verfügbar ist. Wie du dem Webserver von uberspace beibiegst, das Anfragen von außen auch dahin weiter geleitet werden, wird weiter unten im Tutorial erklärt.

Was IMHO im Tutorial fehlt ist das ausliefern von statischen Content (also Bilder, CSS-Dateien etc), darum kümmert sich Django _nicht_, wenn es nicht über den Entwicklungsserver läuft. Persönlich finde ich für statischen Content ja Whitenoise praktisch. Lässt sich in Django einbinden und kümmert sich dann um den statischen Content.

Gruß, noisefloor

Ich bin wieder ein Stück weiter. Jedenfalls denke, dass das hier eine positive Rückmeldung ist:

[pschp@pavo MyDjangoProject]$ curl -I https://pschp.uber.space
HTTP/2 200
date: Mon, 28 Nov 2022 07:24:23 GMT
content-type: text/html; charset=UTF-8
content-length: 1171
vary: Accept-Encoding
server: nginx
last-modified: Sat, 26 Nov 2022 07:45:50 GMT
etag: "493-5ee5ad3c410d4"
accept-ranges: bytes
x-xss-protection: 1; mode=block
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin

Aber mit dem "make the application accesibble from outside" gibt es noch Probleme.

ich habe es mit 'uberspace web backend set / --http --port 8000' versucht. Das sind aber zu wenig arguments. (Ich habe auch die Vermutung, wenn man <port> nur durch 8000 ersetzen müsste, hätten sie es vermutlich gleich hingeschrieben. (backend list: / apache (default))

(Im Beispielprojekt gibt es nur eine html-Seite, später brauche ich dann auch statische Inhalte
...wird dann der nächste Schritt

Ich habe es hinbekommen!

Man kann der Anweisung von https://lab.uberspace.de/guide_django/ folgen. Wichtig ist aber mit dem zweiten Teil zu beginnen und erstmal Django zu installieren und einzurichten. Bei der Veröffentlichung ist zu beachten dass man den Port auf 8000 setzt.

Was mir geholfen hat: Die Umleitung auf die Fehler-Seiten von uberspace auszuschalten. (Auf den Fehlerseiten ist ein Hinweis verlinkt) Wenn auch in Django der Debug-Modus noch auf True steht. Ist das sehr hilfreich bei der Fehlersuche.

@ooHeinzz: Wobei man den Debug-Modus von Webrahmenwerken eigentlich nicht öffentlich freischalten will. Das ist gefährlich.

@ooHeinz: ergänzend zu dem was __blackjack__ sagt: Man schaltet bei einer öffentlich erreichbaren Django-Installation den Debug-Modus aus. Django hat einen Mechanismus um die entsprechend auftretenden Fehler per Mail an den Administrator zu senden.