nicht angemeldet
Apache-Konfiguration: STRATO WILL es NICHT richtig machen
Der MartinMoin!
Wenn auf Strato-Servern (shared hosting) Skripte nicht richtig laufen, dann kann es daran liegen, dass folgendes Skript nur in 2 von 3 Zeilen den korrekten Pfad ausgibt. Der abweichende ist darin begründet, dass Strato in der Serverkonfiguration einen Pfad angibt, der über einen (weiteren, zusätzlichen) Link läuft.
(Das Skript im DOCUMENT_ROOT eines Webauftritts speichern als "shtrt.php" [Strato Has To Repair This] speichern und im Browser abrufen...)
<?php
header('Content-type: text/plain');
echo '__DIR__ : ', __DIR__ , "\n";
echo '$_SERVER["DOCUMENT_ROOT"] : ', $_SERVER["DOCUMENT_ROOT"] , "\n";
echo 'realpath($_SERVER["DOCUMENT_ROOT"]): ', realpath($_SERVER["DOCUMENT_ROOT"]), "\n";
?>
Hier ein Auszug meines Schriftwechsel mit dem Support, der dann belegt, warum ich Strato derzeit nicht als Hoster empfehlen kann:
Sehr geehrte Damen und Herren,
Sie haben sich etwas verfrüht für das Verständnis bedankt. Ich bringe das nämlich NICHT auf.
1.) Sie argumentieren, dass Ihre Systeme seit zwölf Jahren so konfiguriert sind.
Antwort 1: Sie machen es seit 12 Jahren falsch. Und wollen das - ohne Not - ernsthaft fortsetzen?
Antwort 2: Gemäß Ihrem Rezept würde sich für diejenigen, welche ihre Skripte Ihrer Fehlkonfiguration angepasst haben, gerade kein Änderungsbedarf ergeben.
2.) Sie schreiben mir, es handele sich bei der Fehlkonfiguration um einen "Wunsch des Unternehmens".
Antwort: Ich glaube auch nicht, dass sie die Geschäftsleitung überhaupt damit befasst hat. Die haben doch wohl eher BWL studiert. Ich denke, es handelt sich um einen automatisiert fortgesetzten Fehler bei der Konfiguration und jetzt wird befürchtet, dass es Seiteneffekte gibt, wenn dieser repariert wird.
3.) Sie schreiben: "Probleme oder Einschränkungen sind durch die Konfigurtion keine aufgetreten."
Antwort: Das ist falsch. Ich wollte ganz korrekt die ressourcensparende magic constant DIR benutzen und ich (und viele andere) sollen nunmehr ein ressourcenfressendes Vehikel errichten? Was, bitte, verstehen Sie unter "keine Probleme oder Einschränkungen"?
4.) Sie schreiben: "Wir empfeheln daher die Verwendung des realpath($_SERVER['DOCUMENT_ROOT']), so wie dies auch von jeder Webanwendung gehandled wird."
Antwort: Das ist schlicht und einfach unwahr. Tatsache mag sein, dass auf Grund der unbegründeten Sturheit und Marktmacht Ihres Unternehmens Webentwickler die Anwendungen an Ihre Fehler anpassen müssen.
Supporteskalation:
Ich muss Sie bitten, die Angelegenheit jemandem vorzulegen, der in Ihren Unternehmen die Macht hat zu ändern was zu ändern zu ist und mich nicht mit so leicht erkennbaren Scheinargumenten abcancelt.
Mit freundlichen Grüßen
Jörg Reinholz
Am 19.05.2015 um 14:42 schrieb STRATO AG:
Sehr geehrter Herr Reinholz,
ich möchte Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.
Sie hatten sich mit einer Anfrage bezüglich der Konfiguration der virtuellen Hosts an uns gewandt.
Gerne habe ich Ihre Anfrage zur Prüfung in die Fachbateilung gegeben, die bestätigt, dass Sie mit Ihrer Feststellung vöölig Recht haben. Hierbei ist die Konfigurtion der virtuellen Hosts aber genauso vom Unternehmen gewünscht und eine allgemeine Änderung der seit 12 Jahren so konfigurierten Plattform nicht angedacht. Auch eine individuelle Änderung ist im Einzelfall nicht zu realisieren. Hierfür bitte ich um Ihr Verständnis.
Probleme oder Einschränkungen sind durch die Konfigurtion keine aufgetreten.
Wir empfeheln daher die Verwendung des realpath($_SERVER['DOCUMENT_ROOT']), so wie dies auch von jeder Webanwendung gehandled wird.
Ich bitte um Ihr Verständnis und sende Ihnen viele Grüße aus Berlin.
Mit freundlichen Grüßen
T................ Customer Care
E-Mail: http://www.strato.de/kontakt Website: http://www.strato.de
Jörg Reinholz
-
Hallo,
Wenn auf Strato-Servern (shared hosting) Skripte nicht richtig laufen, dann kann es daran liegen, ...
... dass Strato anscheinend sowieso nicht an Profi-Kunden interessiert ist.
Hier ein Auszug meines Schriftwechsel mit dem Support, der dann belegt, warum ich Strato derzeit nicht als Hoster empfehlen kann:
Sehr geehrte Damen und Herren,
[schnipp]
Mit freundlichen GrüßenJörg Reinholz
Am 19.05.2015 um 14:42 schrieb STRATO AG:
Sehr geehrter Herr Reinholz,
[schnipp]
Mit freundlichen GrüßenT................ Customer Care
E-Mail: http://www.strato.de/kontakt Website: http://www.strato.de
Die vielen Schreibfehler waren tatsächlich so drin? Also beschäftigt Strato für die Korrespondenz Mitarbeiter, die diesen Job nicht wirklich beherrschen. Was liegt näher, als zu vermuten, dass sie für die technische Administration ebenfalls Leute beschäftigen, die diesen Job nicht beherrschen?
Und die Fernsehwerbung, die seit einigen Monaten läuft, sagt ja wohl ganz klar: Wir machen uns über uns selbst lustig und wollen vor allem Kunden mit einem IQ unter 10 ansprechen.
Marktmacht des Unternehmens? Das hätten sie vielleicht gern. In meiner Wahrnehmung ist Strato eher ein unbedeutender Faktor im Webhosting-Business, eine Randerscheinung.
So long,
Martin-
Moin!
Die vielen Schreibfehler waren tatsächlich so drin? Also beschäftigt Strato für die Korrespondenz Mitarbeiter, die diesen Job nicht wirklich beherrschen.
Naja. Die Schreibfehler interessieren mich nicht wirklich. Kann ja ein Techniker sein. (Immerhin wurde die Aussage untergebracht: "Ja, das ist falsch". Und einem gut belasteten Technikus sehe ich Typos gerne nach, mach ja selbst genug davon.
Das erste, orthographisch korrekte, Schreiben lief übrigens darauf hinaus, dass ohne Kundennummer gar nichts bearbeitet wird ... worauf hin ich ein wenig polemisch wurde.
Jörg Reinholz
-
Die vielen Schreibfehler waren tatsächlich so drin? Also beschäftigt Strato für die Korrespondenz Mitarbeiter, die diesen Job nicht wirklich beherrschen. Was liegt näher, als zu vermuten, dass sie für die technische Administration ebenfalls Leute beschäftigen, die diesen Job nicht beherrschen?
Näher läge zum Beispiel, erst einmal zu klären, worin genau sich das Problem äußert. Dass zwei unterschiedliche Pfade auf dieselbe Datei zeigen, ist jedenfalls per se weder ein Problem und erst recht kein Fehler.
-
Moin!
Näher läge zum Beispiel, erst einmal zu klären, worin genau sich das Problem äußert. Dass zwei unterschiedliche Pfade auf dieselbe Datei zeigen, ist jedenfalls per se weder ein Problem und erst recht kein Fehler.
Ok. Nehmen wir als Beispiel:
__DIR__ : /var/www/local/test $_SERVER["DOCUMENT_ROOT"] : /foo/bar/local/test realpath($_SERVER["DOCUMENT_ROOT"]): /var/www/local/testund dann:
<?php ## file 'include_me.php' # Exit, wenn in document_root, weil dann Sicherheitsproblem auftreten kann: if (-1 < strpos(__DIR__, $_SERVER["DOCUMENT_ROOT"]) { trigger_errror('Fatal: '. __FILE__ . ' darf nicht in oder unterhalb von DOCUMENT_ROOT (' . $_SERVER["DOCUMENT_ROOT"] . ') liegen!', E_USER_ERROR); exit; }würde auf Strato-Hosts versagen weil die partout den Umweg über die Links in der Serverkonfiguration "verbauen" - und das muss man erst mal wissen!
Bei mir geht es indes nur darum, den relativen Pfad für einen Redirect zu berechnen...
Jörg Reinholz
-
Moin!
<?php header('Content-type: text/plain'); echo '__DIR__ : ', __DIR__ , "\n"; echo '$_SERVER["DOCUMENT_ROOT"] : ', $_SERVER["DOCUMENT_ROOT"] , "\n"; echo 'realpath($_SERVER["DOCUMENT_ROOT"]): ', realpath($_SERVER["DOCUMENT_ROOT"]), "\n"; ## file 'include_me.php' # Exit, wenn in document_root, weil dann Sicherheitsproblem auftreten kann: if (-1 < strpos(__DIR__, $_SERVER["DOCUMENT_ROOT"]) ) { trigger_error('Fatal: '. __FILE__ . ' darf nicht in oder unterhalb von DOCUMENT_ROOT (' . $_SERVER["DOCUMENT_ROOT"] . ') liegen!', E_USER_ERROR); exit; } ?>$_SERVER["DOCUMENT_ROOT"] zeigt den Pfad, der konfiguriert ist, bei Strato also über den oder die Links, DIR über die tatsächlichen Verzeichnisse im Filesystem. Damit liegt DIR auf Strato-Servern scheinbar stets außerhalb von $_SERVER["DOCUMENT_ROOT"]!
Dieses Skript wird demnach bei Strato niemals die Fehlermeldung ausgeben. Ich hab es jetzt als Sicherheitswarnung an Strato geschickt und hoffe damit die richtige Service-Eskalation zu erreichen, weil der Fehler in vielen Anwendungen unbemerkt bleiben wird.
Jörg Reinholz
-
Näher läge zum Beispiel, erst einmal zu klären, worin genau sich das Problem äußert. Dass zwei unterschiedliche Pfade auf dieselbe Datei zeigen, ist jedenfalls per se weder ein Problem und erst recht kein Fehler.
Exit, wenn in document_root, weil dann Sicherheitsproblem auftreten kann:
if (-1 < strpos(DIR, $_SERVER["DOCUMENT_ROOT"]) {
Ich sehe zwar die Stolperfalle, kann mir aber immer noch keine Situation vorstellen, bei der das Problem in der Serverkonfiguration und nicht im Aufbau der PHP-Dateien oder falscher Installation derselben liegen soll. Oder andersrum: Wenn man denn schon eine Sicherung gegen Leute einrichtet, die die Dateien wider Anleitung falsch ablegen, kann man auch so umsichtig sein und die Existenz von Dateisystemverweisen bedenken.
Was mir allerdings auffällt, ist die häufige Nennung von realpath() in der Anleitungsseite zu [link:http://php.net/manual/en/language.constants.predefined.php@title=DIR]. Das Teil scheint von Seiten PHPs auch nicht immer das zu liefern, was der PHP-Bastler erwartet. Und auch die Strato-Technik hat ja darauf hingewiesen, dass realpath() gängige Praxis wäre.
Du kennst das Sprüchlein, "Wenn alle auf dem Kopf zu stehen scheinen, sollte man seine eigene Lage überprüfen"?
Bei mir geht es indes nur darum, den relativen Pfad für einen Redirect zu berechnen...
Warum du bei der Auswahl einer URL auf absolute Dateisystempfade zurückgreifen musst, und nicht nur dies, sondern dann auch noch auf eine Variable, die eher dem Debugging zuzuordnen sein dürfte, ist mir vollkommen schleierhaft.
-
Moin!
Du kennst das Sprüchlein, "Wenn alle auf dem Kopf zu stehen scheinen, sollte man seine eigene Lage überprüfen"?
Womöglich sollte ich klarstellen, dass es sich nicht um eine von mir verwendete Methode handelt, um sicherzustellen, dass der Aufrufer des Skriptes authentifiziert ist. Da frage ich, weil es schlicht noch einfacher ist, nach einem Authentifizierungsmerkmal. z.B. aus $_SESSION.
Bei mir geht es indes nur darum, den relativen Pfad für einen Redirect zu berechnen...
Warum du bei der Auswahl einer URL auf absolute Dateisystempfade zurückgreifen musst, und nicht nur dies, sondern dann auch noch auf eine Variable, die eher dem Debugging zuzuordnen sein dürfte, ist mir vollkommen schleierhaft.
Ich muss es gar nicht. Aber seit Matt's Skriptarchive ... weiss ich, was für Code in der Wildbahn ist und wärmestens empfohlen wird. Und weil mir nichts greifbares und 2 Minuten Nachdenken überlebendes einfällt, wozu die Verlinkerei bzw. über die Links führende Konfiguration bei Strato gut sein soll krittel ich denen das an.
Jörg Reinholz
-
Tach,
Ich muss es gar nicht. Aber seit Matt's Skriptarchive ... weiss ich, was für Code in der Wildbahn ist und wärmestens empfohlen wird.
also bei meinen Recherchen für diesen Thread, bin ich nur auf Ablehnung dieser Methode gestoßen und sie wird auch in keinem der PHP-Tools, die ich am Laufen habe, verwendet. Vielleicht ist das „Problem“ einfach deutlich kleiner als du glaubst.
Und weil mir nichts greifbares und 2 Minuten Nachdenken überlebendes einfällt, wozu die Verlinkerei bzw. über die Links führende Konfiguration bei Strato gut sein soll krittel ich denen das an.
Vielleicht reichen zwei Minuten nachdenken aber auch einfach nicht aus, um die Server-/Verzeichnisstruktur eines der größten Hoster Europas zu verstehen. Schon in der von mir betreuten, relativ kleinen Infrastruktur ist die übliche Pfadangabe zu Dateien häufiger kein absoluter Pfad, weil z.B. Dinge von anderen Servern gemountet und an den nötigen Ort verlinkt werden.
mfg
Woodfighter-
Moin!
Schon in der von mir betreuten, relativ kleinen Infrastruktur ist die übliche Pfadangabe zu Dateien häufiger kein absoluter Pfad, weil z.B. Dinge von anderen Servern gemountet und an den nötigen Ort verlinkt werden.
Stellt sich die Frage, warum man server://foo erst nach /mounts/server/foo mounted um es dann nach /var/www zu linken ... damit die Konfigurationsdatei des Apache den Link enthält und das System (und der Admin) mehr Stress hat?
Jörg Reinholz
-
Tach,
Stellt sich die Frage, warum man server://foo erst nach /mounts/server/foo mounted um es dann nach /var/www zu linken ... damit die Konfigurationsdatei des Apache den Link enthält und das System (und der Admin) mehr Stress hat?
der Admion hat weniger Streß, weil auf allen Servern Mounts immer am gleichen Ort liegen, egal was der aktuelle Nutzungszweck des Servers ist, weil die Konfiguration zentral für alle Server gemacht werden kann, weil die Inhalte des Mountpints auf einem Server an unterschiedlichen Orten auftauchen können ohne mehrfach mounten zu müssen, … Der „Streß“ für das System ist vernachläsigbar.
mfg
Woodfighter-
Moin!
der Admion hat weniger Streß, weil auf allen Servern Mounts immer am gleichen Ort liegen, egal was der aktuelle Nutzungszweck des Servers ist, weil die Konfiguration zentral für alle Server gemacht werden kann, weil die Inhalte des Mountpints auf einem Server an unterschiedlichen Orten auftauchen können ohne mehrfach mounten zu müssen, … Der „Streß“ für das System ist vernachläsigbar.
Und was sollte dann den Amin daran hindern, in der Apache-Konfig den Weg über den mountpoint .z.B. /mounts/www einzutragen und den Link auf /var/www denen zu überlassen, welche mit Ihrem WinSCP die Webs partout unter /var/www suchen? Den SuSE-Admins hat man ja auch mit einem Link von /var/www nach /srv/www helfen können ohne dem Apache das zuzumuten...
Jörg Reinholz
-
Tach,
Und was sollte dann den Amin daran hindern, in der Apache-Konfig den Weg über den mountpoint .z.B. /mounts/www einzutragen
z.B. Standards wie Filesystem Hierarchy Standard, dann muss man nämlich nicht jeden neuen Admin neu anlernen.
mfg
Woodfighter-
Moin!
Und was sollte dann den Amin daran hindern, in der Apache-Konfig den Weg über den mountpoint .z.B. /mounts/www einzutragen
z.B. Standards wie Filesystem Hierarchy Standard, dann muss man nämlich nicht jeden neuen Admin neu anlernen.
Ehem. Wo, bitte, steht da was davon, wo sich die Verzeichnisse virtueller Hosts eines Apache-Webservers befinden? Zumal die Links von Strato soweit ich das jetzt noch weiss weder nach /var noch nach /srv (oder einen Ordner dahinter) zeigten.
Jörg Reinholz
-
Tach,
Ehem. Wo, bitte, steht da was davon, wo sich die Verzeichnisse virtueller Hosts eines Apache-Webservers befinden? Zumal die Links von Strato soweit ich das jetzt noch weiss weder nach /var noch nach /srv (oder einen Ordner dahinter) zeigten.
da steht, dass Dateien dieser Art i.A. in /var/lib/ zu finden sein sollten (oder in /srv/). /var/www widerspricht dem prinzipiell schon, ist aber in der Debian-Policy so festgeschrieben (was ich bei einem Debian-Admin als Wissen voraussetzen würde).
Zumal die Links von Strato soweit ich das jetzt noch weiss weder nach /var noch nach /srv (oder einen Ordner dahinter) zeigten.
Ich vermute mal, dass sie ihre eigenen Standards einsetzen und das vermutlich schon ziemlich lange.
mfg
Woodfighter-
Moin!
Ich vermute mal, dass sie ihre eigenen Standards einsetzen und das vermutlich schon ziemlich lange.
Zur Erinnerung. Es ging um:
Und was sollte dann den Amin daran hindern, in der Apache-Konfig den Weg über den mountpoint .z.B. /mounts/www einzutragen?
z.B. Standards wie Filesystem Hierarchy Standard, dann muss man nämlich nicht jeden neuen Admin neu anlernen.
Ehem. Wo, bitte, steht da was davon, wo sich die Verzeichnisse virtueller Hosts eines Apache-Webservers befinden? Zumal die Links von Strato soweit ich das jetzt noch weiss weder nach /var noch nach /srv (oder einen Ordner dahinter) zeigten.
Ich vermute mal, dass sie ihre eigenen Standards einsetzen und das vermutlich schon ziemlich lange.
Tja. Dann müssten die Admins, die man ja nicht neu anlernen will, ja doch die Strato-eigenen Standards lernen. Folgt man der Vermutung ist das Argument hinfällig.
Übrigens: Wieso denn in /var/www? Es sind ja gleichzeitig auch die Homes der FTP-Benutzer?
Jörg Reinholz
-
Tach,
Tja. Dann müssten die Admins, die man ja nicht neu anlernen will, ja doch die Strato-eigenen Standards lernen. Folgt man der Vermutung ist das Argument hinfällig.
ja, ich habe auch nicht strikt am Strato-Beispiel argumentiert, da ich genau wie du nur spekulieren kann, was zu deren Konfiguration geführt hat; ich gehe allerdings davon aus, dass das einen Sinn hat(te).
Übrigens: Wieso denn in /var/www? Es sind ja gleichzeitig auch die Homes der FTP-Benutzer?
In meiner Konfiguration wäre mindestens eines davon ein Link (und es wäre kein FTP-Server).
Aus zweierlei Gründen noch ein Zitat aus der Debian Policy: „If access to the web document root is unavoidable then use /var/www/html as the Document Root. This might be just a symbolic link to the location where the system administrator has put the real document root.“
- Weil mir die Neuerung mit /var/www/html offensichtlich noch nicht geläufig genug ist.
- Wegen des zum Thema passenden zweiten Satzes.
mfg
Woodfighter
-
-
-
-
-
-
-
-
-
-
-
-
Moin!
Näher läge zum Beispiel, erst einmal zu klären, worin genau sich das Problem äußert. Dass zwei unterschiedliche Pfade auf dieselbe Datei zeigen, ist jedenfalls per se weder ein Problem und erst recht kein Fehler
Hm. Zweiter Versuch. Zeigt das hier verständlicher, worin das Sicherheitsproblem bei der Fehlkonfiguration liegt?
Jörg Reinholz
-
Tach,
Hm. Zweiter Versuch. Zeigt das hier verständlicher, worin das Sicherheitsproblem bei der Fehlkonfiguration liegt?
Strato hat meiner Meinung nach zumindest so weit recht, dass das Sicherheitsproblem im Weglassen von realpath liegt (also nicht wirklich ein Sicherheitsproblem, weil auf diese weise eh nicht festgestellt werden kann, ob das Script inkludiert wurde oder nicht) und nicht in der Config von Strato.
Zudem muss hier auch die Option "Follow Symlinks" für den Server explizit eingeschaltet worden sein. Offenbar halten das die Programmierer des Webservers Apache nicht für eine so gute Idee, dass diese das als Default setzen.
Aus der Apache-Doku: „The default was changed from All to FollowSymlinks in 2.3.11“.
Zudem kostet die Verwendung von realpath() auch Rechenzeit und ist damit im Programmierer-Jargon "teuer".
Das darf kein Grund für schlechtere Sicherheit sein und wäre ernsthaft eine lächerliche Microoptimierung.
mfg
Woodfighter-
Moin!
Aus der Apache-Doku: „The default was changed from All to FollowSymlinks in 2.3.11“.
Mag sein, dass dieses die Voreinstellung ist, wenn man nichts angibt. Nur, wenn ich mir einen Apache installiere, dann steht in den mitgelieferten Konfig-Dateien meiner Erinnerung nach stets
Options noneDas darf kein Grund für schlechtere Sicherheit sein und wäre ernsthaft eine lächerliche Microoptimierung.
So ganz "mikro" wird das wohl nicht sein wenn täglich ein paar Millionen Mal auf einem derart großen Server (da sind zigtausend vhosts drauf) wie von Strato diverse Pfade abgehechelt und auf Links untersucht werden. Im Übrigen sperre ich die lib-Dirs nochmal explizit, damit ich nicht das Opfer von versehentlichen Fehlkonfigurationen werde.
Dennoch befürchte ich, dass Strato durch die unerwartete Konfiguration selbst an der Schaffung von Problemen mitwirkt. Es geht darum, dass es wohl genug PHP-Progger (erst recht einfache Kunden) geben wird, die von dieser Besonderheit der Strato-Konfiguration und von der Auswirkung nichts wissen. Und da sehe ich Strato dann doch in der Verantwortung. Zumal ich keinen trefflichen Grund sehe, den Symlinks in der Konfiguration zu folgen. Das erscheint mir so nötig wie ein Kropf.
Jörg Reinholz
-
Tach,
Aus der Apache-Doku: „The default was changed from All to FollowSymlinks in 2.3.11“.
Mag sein, dass dieses die Voreinstellung ist, wenn man nichts angibt. Nur, wenn ich mir einen Apache installiere, dann steht in den mitgelieferten Konfig-Dateien meiner Erinnerung nach stets
Options nonenö, habe gerade nochmal in die die Sourcen geschaut, Apache selber liefert „Options Indexes FollowSymLinks“ aus; in Debian ist es „Options Indexes FollowSymLinks MultiViews“. Kann also höchstens an der Distri liegen, die du nutzt.
Das darf kein Grund für schlechtere Sicherheit sein und wäre ernsthaft eine lächerliche Microoptimierung.
So ganz "mikro" wird das wohl nicht sein wenn täglich ein paar Millionen Mal auf einem derart großen Server (da sind zigtausend vhosts drauf) wie von Strato diverse Pfade abgehechelt und auf Links untersucht werden.
Das ist und bleibt Micro, ich bin mir sicher, dass man an anderen Stellen deutlich mehr einsparen könnte. Da die Abfrage eh die Sicherheit nicht wesentlich erhöht, könnte man stattdessen auch auf des deutlich ressourcenschonendere Setzen einer Konstante zurückgreifen:
// index.php define('INCLUDES_GO', true); include 'include.php'; // include.php if(!defined('INCLUDES_GO')){ exit; }Dennoch befürchte ich, dass Strato durch die unerwartete Konfiguration selbst an der Schaffung von Problemen mitwirkt. Es geht darum, dass es wohl genug PHP-Progger (erst recht einfache Kunden) geben wird, die von dieser Besonderheit der Strato-Konfiguration und von der Auswirkung nichts wissen. Und da sehe ich Strato dann doch in der Verantwortung.
Ersteinmal sehe ich den Kunden, der Software installiert und sich nicht an die Anleitung zur Installation der Software hält in der Verantwortung oder deren Entwickler, der einen schlechten und fehlerhaften Weg zur Überprüfung der Inkludiertheit gewählt hat.
Zumal ich keinen trefflichen Grund sehe, den Symlinks in der Konfiguration zu folgen. Das erscheint mir so nötig wie ein Kropf.
Das heißt allerdings nicht, dass es keinen gibt. Gerade bei Shared Hosting wäre ich eher verwundert, wenn mein Verzeichnis tatsächlich unterhalb von Document_Root liegt.
mfg
Woodfighter-
Moin!
Das heißt allerdings nicht, dass es keinen gibt. Gerade bei Shared Hosting wäre ich eher verwundert, wenn mein Verzeichnis tatsächlich unterhalb von Document_Root liegt.
Wieso das denn? Jeder virtuelle Host hat doch stets ein eigenes DOCUMENT_ROOT.
Jörg Reinholz
-
Tach,
Das heißt allerdings nicht, dass es keinen gibt. Gerade bei Shared Hosting wäre ich eher verwundert, wenn mein Verzeichnis tatsächlich unterhalb von Document_Root liegt.
Wieso das denn? Jeder virtuelle Host hat doch stets ein eigenes DOCUMENT_ROOT.
weil ich nicht davon ausgehen würde, dass ich einen eigenen VHost habe; aber meine Erfahrungen mit Shared Hosting sind eher alt.
mfg
Woodfighter-
Moin!
Wieso das denn? Jeder virtuelle Host hat doch stets ein eigenes DOCUMENT_ROOT.
weil ich nicht davon ausgehen würde, dass ich einen eigenen VHost habe; aber meine Erfahrungen mit Shared Hosting sind eher alt.
Aber ja doch. Auch beim Shared Hosting gibts für jede Domain einen VHOST (zu unterscheiden von einem "virtuellen Server", der einen (halbwegs) kompletten eigenen Server vormacht). Soweit ich mich an Strato erinnere allerdings mit der Macke, dass man für die erste Domain keinen Pfad bestimmen kann (DOCUMENT_ROOT des VHOST == $HOME) und dass die weiteren dann Unterverzeichnisse von $HOME, also auch von DOCUMENT_ROOT der ersten Domain sein müssen, was sehr unhübsche Seiteneffekte haben kann. (Noch ein Grund, Strato nicht zu empfehlen)
Jörg Reinholz
-
Tach,
Aber ja doch. Auch beim Shared Hosting gibts für jede Domain einen VHOST (zu unterscheiden von einem "virtuellen Server", der einen (halbwegs) kompletten eigenen Server vormacht).
ok, ich wäre davon ausgegangen, dass da durchaus häufiger Konfigurationen mit einem Frontend-Proxy für Domains und getrennten WEbservern fürs Hosting gearbeitet wird.
mfg
Woodfighter-
Moin!
Tach,
Aber ja doch. Auch beim Shared Hosting gibts für jede Domain einen VHOST (zu unterscheiden von einem "virtuellen Server", der einen (halbwegs) kompletten eigenen Server vormacht).
ok, ich wäre davon ausgegangen, dass da durchaus häufiger Konfigurationen mit einem Frontend-Proxy für Domains
So auf die Schnelle kann ich das bei Strato natürlich nicht ausschliessen ... aber
und getrennten WEbservern fürs Hosting gearbeitet wird.
Ich sehe auch dann keinen Grund, die nicht vernünftig und also mit realen Pfaden zu konfigurieren.
Jörg Reinholz
-
Tach,
Ich sehe auch dann keinen Grund, die nicht vernünftig und also mit realen Pfaden zu konfigurieren.
nur weil du es nicht verstehst, ist es nicht unvernünftig.
mfg
Woodfighter-
Moin!
nur weil du es nicht verstehst, ist es nicht unvernünftig.
Mag als eine sehr allgemeine Aussagen in einigen Fällen zutreffen. Aber ein treffliches und Überlegungen stand haltendes Argument dafür, in der Apache-Konfiguration die Verzeichnis-Pfade über Links zu notieren, wurde mir noch immer nicht genannt. Was soll ich also verstehen? Könnte es nicht sein, dass es eher umgekehrt ist, nämlich dass mein Argument _"damit DIR und $SERVER['DOCUMENT_ROOT'] übereinstimmen", einfach ignoriert wird?
Jörg Reinholz
-
Tach,
Aber ein treffliches und Überlegungen stand haltendes Argument dafür, in der Apache-Konfiguration die Verzeichnis-Pfade über Links zu notieren, wurde mir noch immer nicht genannt. Was soll ich also verstehen? Könnte es nicht sein, dass es eher umgekehrt ist, nämlich dass mein Argument _"damit DIR und $SERVER['DOCUMENT_ROOT'] übereinstimmen", einfach ignoriert wird?
Es gibt keinen Grund, warum sie übereinstimmen sollten; realpath und seine Verwendung ist an diversen Stellen nötig (gerade wenn man sich aus Sicherheitsgründen mit Pfaden beschäftigt), weil man sich nie darauf verlassen kann, nicht irgendwo einen Link drin zu haben.
Einigen wir uns darauf, dass dein Argument für mich (und für Strato) genauso wenig stand haltend ist, wie meine für dich.
mfg
Woodfighter
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Moin!
Moin!
Wenn auf Strato-Servern (shared hosting) Skripte nicht richtig laufen, dann kann es daran liegen, dass folgendes Skript nur in 2 von 3 Zeilen den korrekten Pfad ausgibt. Der abweichende ist darin begründet, dass Strato in der Serverkonfiguration einen Pfad angibt, der über einen (weiteren, zusätzlichen) Link läuft.
(Das Skript im DOCUMENT_ROOT eines Webauftritts speichern als "shtrt.php" [Strato Has To Repair This] speichern und im Browser abrufen...)
Spannend wäre ja, zu sehen, was dabei herauskommt - für alle diejenigen, die nicht extra deswegen Strato-Webspace erwerben wollen.
Grüße Sven
-
Moin!
etwas wie:
__DIR__ : /var/www/local/test $_SERVER["DOCUMENT_ROOT"] : /foo/bar/local/test realpath($_SERVER["DOCUMENT_ROOT"]): /var/www/local/testJörg Reinholz
-
-
Ahoi Jörg
eine Domain habe ich bei Strato, weil dort das Mailen wirklich günstig ist. 99 cent im Monat, zig Postfächer mit bis zu GB. BasicWeb. Bietet aber kein PHP. Erst ab 3,99 im Monat. Das aber ist mir zu teuer. Ich kriege ja einen VServer schon für 6,99 im Monat mit zig GB Speicher. Insofern kann ich Dein Problem nicht testen. Ich finde beim Zend-Framework, man solle mit realpath() includen: http://framework.zend.com/manual/1.12/de/performance.classloading.html.
So ganz verstehe ich den "Aufriss" nicht. Wenn sich ein Entwickler nach 12 Jahren über eine Konfiguration beschwert, meinst du wirklich, dass juckt irgendwen? Offenbar konnten ja alle, die bei Strato Webseiten betreiben, die letzten 12 Jahre damit leben. Ich kann auch verstehen, dass Strato das, wenn es schon so lange so (ob "falsch" oder nicht) läuft, nicht ändert. Sollen sie alle Kunden anschreiben, dass das jetzt (wegen Jörg) geändert wurde.
Ich kann zwei Sachen zu Strato sagen: der Support ist unterdurchschnittlich, von mir aus auch unterirdisch, ich weiß nicht genau, ob sich das die letzten Jahre geändert hat. Die Technik aber funktioniert ziemlich perfekt. Keine Ausfälle, weder bei der Webpräsenz noch beim Mailen (anders bei meinem kleinen Lieblingsprovider, der für 3,60 im Jahr Domains anbietet und bei dem man alles schön konfigurieren kann, aber alle halbe Jahre haperts dann mal mit den Mails, was nicht schön ist ...).
Ich glaube zudem, dass deren Techniker Mega-Profis sind. Da können sich vermutlich alle hier noch ein paar Scheiben abschneiden. Irgendwas werden die sich vermutlich dabei gedacht haben, auch wenn der Support (s.o.) das nicht vermitteln kann.
Dank und Gruß,
bob from berlin