Python Scritpe werden heruntergeladen statt ausgeführt. Fehler in vhost.conf?

renky

New Member
Ich hatte heute zum ersten Mal den Versuch gestartet ein Python Script über den Browser aufzurufen und bin damit kläglich gescheitert, da das Script immer downgeloaded wird (Mozilla) bzw. als Plain-Text angezeigt wird (Chrome). Ich habe lange probiert und hin und her experimentiert, zig Tutorials und auch Einträge bei HowtoForge gewälzt und die Verschiedensten Wege ausprobiert - alles ohne Erfolg. Erst eine kleine Änderung in der Site-vhost-config brachte mich dann zum erfolg.

Und zwar war dort bei der Python-Configuration als Directory der Web-Pfad angegeben - also /var/www/domain.tld/web
als ich das auf den absoluten Pfad geändert habe, (/var/www/clients/clientx/weby/web) wurde das Script ordnungsgemäß ausgeführt.
Ich habe dann die vhost-template-Datei geprüft und in der Tat wird dort (scheinbar ja absichtlich) das obere Verzeichnis gewählt:
<Directory {tmpl_var name='web_document_root_www'}>

Ist ein solches Problem bekannt - hatte das auch schon jemand anders? Ist das eventuell tatsächlich ein Fehler?
Ich wundere mich nur, falls es ein Fehler wäre, dass da sonst noch nie einer drüber gestolpert ist?!

Installation ist Debian Jessie, IspConfig 3.0.x, Python 2.7.9
ich habe eben auch gitlab gecheckt, aber auch die ISPConfig 3.1-er vhost-Template-Datei hat noch web_document_root_www drin stehen.
Das script ist denkbar primitiv:
 

Till

Administrator
Problem ist nicht bekannt, aber Pythin wird sicherlich auch nicht so oft verwendet. Ich habe mal einen Eintrag im Bugtracker dafür angelegt, damit wird das mal für das nächste Release testen.
 

renky

New Member
Hallo Till

auch wenn das jetzt tatsächlich eingebaut wurde - ich habe hier nun den Fall, dass es mit der neuen Lösung nicht klappt... Ich habe jetzt mehrer Server laufen und auf zweien habe ich bei Kunden Python in Betrieb - und ohne, dass ich bisher dahinter gestiegen bin warum das so ist: auf einem funktioniert es nur mit dem /var/www/clients/clientx/weby/web (das ist der Grund, warum ich hier den Artikel eröfnet hatte) und auf dem anderen funktioniert es damit nicht - dafür aber mit dem verlinkten web-root... ich habe bisher keinen Anhaltspunkt warum das so ist - beide laufen mit Debian Jessie und haben die gleichen mod_python Versionen drauf...
Der letztere ist ca. 2 Jahre neuer - es könnte also durchaus sein, dass auf dem neureren ein paar andere Default-Configurationen laufen... habe aber noch keinen echten Grund gefunden.

D.h. jetzt aber, dass die neue Lösung eventuell bei anderen auch nicht funktioniert...
 

renky

New Member
Ok, habe jetzt doch einen Unterschied gefunden. Leider bin ich trotzdem nicht weiter - im Gegenteil - die Indizien verdichten sich, dass der Thread hier auf falschen Annahmen basierte und der Fix damit falsch war!!

Im einen Paket habe ich eine gechrootete Umgebung und im anderen nicht - Bei dem Paket mit der gechrooteten Umgebung funktioniert es nur mit /var/www/domain.tld/web - also dem gelinkten Verzeichnis so wie es früher war - mit dem Paket ohne die gechrootete Umgebung funktioniert es nur mit dem vollen echten Pfad /var/www/clients/client/webxx/web

ich habe dann mal auf dem ersten Server, wo es nur mit vollem Pfad funktionierte ein anderes Paket mit gechrooteter Umgebung gesucht und siehe da: tatsächlich ging es dort nur mit /var/www/domain.tld/web
Aber der Gegencheck war leider nicht erfolgreich: bei einem Paket auf dem zweiten Server ohne Chroot geht es auch nur mit /var/www/domain.tld/web

d.h. jetzt: ich habe zwei Server und vier Pakete getestet - bei dreien geht es nur so wie es früher implementiert war, und bei einem einzigen geht es so wie ich es hier beschrieben hatte und es jetzt gefixt wurde... das spricht alles für ein Rückabwickeln des Fixes...

Leider bin ich kein bisschen schlauer - ich sehe keinen Grund, warum das erste Paket hier etwas anderes verlangt als alle anderen...
 

Werbung

Top