Nach Update auf DSM5 Webseiten eigene nicht mehr erreichbar "No input file specified"

[Christoph_K]

Nach Update auf DSM5 Webseiten eigene nicht mehr erreichbar "No input file specified"

Hi Leute.
Habe auf DSM 5 geupdated. Jetzt gehen meine Webprojekte nicht mehr (vhost File pflege ich immer selbst).
Die VHost Config ist noch da. Aber wenn ich auf den dort angegebenen Website-Hostnamen zugreifen will, bekomme ich einfach nur: "No input file specified" im Borwser zu sehen (404).
Habe bisschen gegooglet. Anscheinend ist das, wenn PHP irgendwie im FastCGI mode oder so ähnlich läuft und den Parameter nicht kennt worüber das zu ladende Script übergeben werden soll.
Aber da hören meine Linuxkenntnisse dann auch schon auf....

Könnt Ihr mir helfen?

Weiß nicht, wo ich anfangen soll, zu suchen.
Bisher habe ich "nur" das obige in Erfahrung gebracht und eben ausprobiert meine Websiteadresse "http://meinproject.diskstation.local" aufzurufen (vhost, auch eingetragen in der windows hosts datei). Da erscheint dann wie gesagt im Browser als Inhalt nur "No input file specified"!

Brache Hilfe ;-)

Danke Euch.
CHRIS

 

[suissechris]

Schwierig zu sagen, da ich ja nicht weiss, was Du für Webprojekte hostest.

3 Hinweise, vielleicht bringen die Dich weiter:

- mit DSM 5.0 ist Synology offenbar auf Apache 2.2 umgestiegen. Dort sind einige Module anders, aufgeteilt usw., so dass gewisse Direktiven in den conf files nicht mehr genau so funktionieren (habe genau die Erfahrung mit mod_auth gemacht). Dann started aber meistens der Apache gar nicht und die Fehlermeldung ist eine andere (cannot connect to host oder was immer Dein Browser sagt, wenn der Webserver nicht antwortet).

- Mit DSM 5 liegen die Config Files für vhosts woanders (neu unter /etc/httpd/sites-enabled-user/) ... und vieleicht findet er in Deinem vhost da irgendein Include File nicht mehr ...

- wenn es um PHP geht, können neu die PHP Extensions im UI ausgewählt werden (WebServices --> PHP Settings --> Select PHP extension). Vielleicht fehlt da was für Deine Projekte ...

- ansonsten bleibt nur log files durchforsten ...

 

[Christoph_K]

die files habe ich schon gefunden an dem neuen ort. die vhosts datei ist ok, hab schon gemerkt dass er sie richtig laden kann. host wird gefunden.

habe symfony php projekte dort laufen. liefen vorher 1a. ärgerlich :-(
war ich rausgefunden habe:
gebe ich
/~homename/ ein, geht es! index.php wird geladen. gebe ich /~homename/unterverzeichnis/ ein, kommt:
"Internal Server Error
Script "/var/services/homes/homename/www/unterverzeichnis/index.php" not within configured docroot
suPHP 0.7.2"

editiere ich die suPHP config und füge halt :/var/services/homes an den docroot an, so erhalte ich dann:
"Internal Server Error
Directory /volume1/homes/homename/www/unterverzeichnis is not owned by einadminuser
suPHP 0.7.2"

das gefällt mir alles nicht und ich bin da gleich mitm linux latein am ende...
haste ne idee, wo ich suchen kann? welche logfiles? was ist eigentlich suPHP ? das ist neu in dsm 5 oder?

 

[suissechris]

Eine Doku zu suphp ist hier zu finden: https://wiki.archlinux.org/index.php/Suphp


Kann sein, dass das neu verwendet wird - keine Ahnung. Jedenfalls führt es - so wie es im DSM konfiguriert ist - in der Tat dann dazu, dass php via php-cgi ausgeführt wird.
Es erlaubt, php im context des Webserver User laufen zu lassen, ohne dessen Passwort zu kennen - und damit alle dessen Rechte zu erben - alle Files zu sehen und zu öffnen etc.
Ausserdem muss jedes directory, das in docroot spezifiziert ist eben einem admin user (z.B. root) gehören. Also chown root.root /volume1/homes/homename/www/unterverzeichnis sollte es tun.

Das Module wir in der Tat nur für die User Directories geladen und zwar in /etc/httpd/conf/extra/httpd-userdir.conf-user.

Eventuell musst Du dieses anfassen und mod_suphp NICHT laden und die entsprechenden Direktiven auskommentiern ... wäre einen Versuch wert.

Habe keine DSM 4.3 mehr und kann nicht sagen, wie es vorher war ...

 

[Christoph_K]

also 1. hab ich selber glaub n fehler gemacht was zur diesem "not owned by" führte...
hatte in diesen ordner ne datei gelegt die ich erstellt habe und dann hat sie aber nicht dem benutzer gehört, dem das verzeichnis gehörte.. habe dann mit chown die datei geändert und den besitzer auf den des ordner gesetzt. hat er gefressen erstmal.

danke für deine hinweise... das ist echt ein versuch wert!!

siehe da, ich hab in der httpd error log folgende gefunden:
[Sat Mar 15 19:08:49 2014] [error] [client 192.168.0.103] PHP Warning: Unknown: open_basedir restriction in effect. File(/volume1/homes/someuser/www/officehours/web/frontend_dev.php) is not within the allowed path(s): (/etc.defaults:/etc:/usr/syno/synoman:/tmp:/var/se$
[Sat Mar 15 19:08:49 2014] [error] [client 192.168.0.103] PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0

habe in der dsm oberfläche mal den open_basedir pfad angepasst. den kann man ja dort ändern (häkchen vorher setzen). hab :/volume1/homes hinten angehängt. leider immern och die gleiche fehlermeldung im error log...hilft uns das weiter?? scheint ja EIGENTLICH nur noch dieser fehler zu sein......., wenn der schon im log steht?

 

[jahlives]

Es erlaubt, php im context des Webserver User laufen zu lassen, ohne dessen Passwort zu kennen - und damit alle dessen Rechte zu erben - alle Files zu sehen und zu öffnen etc.
Nicht ganz ;-) Es erlaubt die Ausführung von PHP eben für andere User als den User unter dem der Webserver läuft. Vorher mit PHP als Apache Modul wurde das PHP immer unter dem Webserveruser ausgeführt.
Ausserdem muss jedes directory, das in docroot spezifiziert ist eben einem admin user (z.B. root) gehören. Also chown root.root /volume1/homes/homename/www/unterverzeichnis sollte es tun
Das dürfte aber der Server verweigern. Denn der Eigentümer muss identisch sein zum User unter dem das PHP schlussendlich ausgeführt wird. In diesem Beispiel könnte es nur gehen wenn PHP unter root ausgeführt wird und das wäre ein sehr sehr grosses Sicherheitsrisiko!

PHP als cgi resp fcgi ist neu mit DSM 5 gekommen. Vorher wurde PHP über ein Apache Modul ausgeführt

 

[suissechris]

jahlives:

Hast vollkommen recht, war Unsinn, was ich da geschrieben habe.

 

[Christoph_K]

Also Leute ich bin übrigens noch kein Stück weiter. Tappe im Dunkeln irgendwie. :-(

 

[Christoph_K]

ok, ich vermute es liegt lediglich an dem open_basedir!

das problem hatte ich schonmal!

die lösung war dann, open_basedir auf none zu setzen.
habe eben mal getestet: in dsm 6 gui open_basedir auf '' gesetzt (none).

die webseiten lassen sich nun aufrufen!!!
jetzt ist mir das aber nicht lieb! vorher habe ich das pro vhost deaktiviert mit php_admin_value open_basedir none.
wenn ich das jetzt aber in die vhost config schreibe und httpd neustarte, erreiche ich gar keine website mehr (server nicht gefunden). also schluckt er nach dem dsm update auf 5 das kommando "php_admin_value" nicht mehr.
also kann ich für meine projekte separat nicht mehr open_basedir auf none setzen.

was kann ich tun?
jetzt ist ja für den kompletten webserver open_basedir auf none.
das ist ein hohes sicherheitsrisiko, richtig? was kann da passieren? und habt ihr eine idee wie ich es doch pro projekt auf "none" setzen kann?
und wieso um alles in der welt sagt er dass der pfad
"/volume1/homes/someuser/www/officehours/web/index.php"
nicht im open_basedir
"/etc.defaults:/etc:/usr/syno/synoman:/tmp:/var/services/tmp:/var/services/web:/var/services/homes:/volume1/homes"
ist? ist er doch?!

 

[Feuereisen]

nach Update auf DSM5 funktioniert Webseite doch wieder

im Grunde trat alles zuvor beschriebene ein... ich war auf's übelste frustriert...

Zunächst einmal sah ich in der DSM Hilfe nach. Die habe ich dann so verstanden, das nur das admin-Konto eine Persönliche Webseite mit PHP unterstützt. Alle anderen Konten unterstützen dies nicht, da keine Pfadanweisungen für das HOMES-Verzeichnis erlaubt ist. Also OPEN_BASEDIR braucht nicht verändert werden und kann in der Systemvoreinstellung belassen werden.

Jetzt habe ich meinen vorhandenen persönlichen WWW-Ordner in den WEB-Ordner komplett kopiert. (kann jetzt, falls gewünscht umbenannt werden)
Unter Webdienste muß jetzt ein virtueller Host eingetragen werden und den Haken bei Persönlicher Webseite wegnehmen. Wähle erstellen aus, jetzt den WWW-Ordnernamen und einen Seitennamen eingeben.

In DSM5 wurde eine neue Gruppe eingeführt: http
Man muß in der Gruppe HTTP die Berechtigungen für die Ordner WEB und HOMES auf Lesen/Schreiben setzen. Genauso auch in der Gruppe administrators.
Der Benutzer ADMIN und mein Konto müssen der Gruppe HTTP beitreten(anklicken).

Mit der File Station den WEB-Ordner mit rechten Mausklick auswählen und Eigenschaften wählen. Jetzt auf Berechtigungen klicken. Hier muß je ein Haken bei Lesen/Schreiben beim admin und meinem Konto sein. Genauso auch mit dem HOMES-Ordner verfahren.

So nun sollte alles wieder wie gewohnt funktionieren.
Die Webseite kann nun einfach aufgerufen werden:
http://{Ihre Name}.myds.me/{z.b. www} bzw. http://192.168.1.1/{z.b. www}

Ich hoffe, das ich euch helfen konnte.