[Gelöst] "Unbekannter Installationsstatus"; Soll contao-manager.phar.php entfernen

Hallo,

nach Jahren wollte ich mal wieder Contao ausprobieren.
Ich habe es gedownloaded, auf meinen Server gepackt, die contao-manager.phar in contao-manager.phar.php umbenannt und wollte nun Contao installieren.

Bei der Systemprüfung kommt allerdings nun folgender Fehler:

Zitat:

---

ERROR 500 Unbekannter Installationsstatus
Auf Ihrem Server wurden Dateien gefunden, die keiner bekannten Contao-Version zugeordnet werden konnten.
Um Contao zu installieren, müssen Sie entweder Ihre Installation manuell reparieren oder folgende Dateien und Ordner entfernen:

- contao-manager.phar.php

---

Nun weiß ich nicht, was ich tun soll, weil es mir paradox erscheint. Wenn ich diese Datei lösche, kann ich Contao nicht installieren.

Mein Server läuft mit PHP 7.2 und MySQL 5.5. Den PHP Binary Pfad habe ich auch überprüft.

Ich hoffe ihr könnt mir Hinweise geben, wir ich hier nun weiter verfahre.

Hast du auf deinen Server:

1. Einen neuen Ordner für deine Contao Installation angelegt,
2. in diesem Ordner einen Ordner namens "web" angelegt,
3. die contao-manager.phar dort runtergeladen und nach contao-manager.phar.php umbenannt,
4. den Document Root der Domain auf diesen Ordner konfiguriert?

Danke für deine Antwort.

Nein, das habe ich nicht. Die Seite https://contao.org/de/download.html hat diese Schritte nicht kommuniziert.
Da steht lediglich, dass ich die Datei in den Ordner /web übertragen soll. Da ich aber /web über den Browser ohne weiteres keinen Zugriff habe, sich aber /vhosts/[domain]/htdocs in /web befindet, habe ich 1 und 1 zusammen gezählt und es für logisch befunden, die Datei in /htdocs hochzuladen. Somit wäre es auch auch in /web. Und der Contao-Manager (bzw. Systemcheck) lies sich darüber sogar auch öffnen. Da kann man nicht auf die Idee kommen, dass es im falschen Ordner liegt.

Schade, dass auf der Downloadseite kein Hinweis oder Link zu einer konkreten, unmissverständlichen(!) Installationsanleitung steht. Deine Infos auf dieser Seite hätten mir eine Stunde Recherche und Rumprobieren erspart.
Ist die Anzahl der Contao-Neulinge, die da so denken würden wie ich und entsprechend auf dem Schlauch stehen würden, tatsächlich so gering?

Habe ich es so nun richtig verstanden:
1. Ich erstelle im /htdocs-Ordner einen /web-Ordner.
2. In diesen /web-Ordner lege ich die contao-manager.phar in contao-manager.phar.php um und führes ie aus.
3. Ich konfiguriere den Server so, dass z.B. "https://domain.de" auf "domain.de/web" zugreift.

Zitat:

---

Zitat von Shade

Danke für deine Antwort.

Nein, das habe ich nicht. Die Seite https://contao.org/de/download.html hat diese Schritte nicht kommuniziert.
Da steht lediglich, dass ich die Datei in den Ordner /web übertragen soll. Da ich aber /web über den Browser ohne weiteres keinen Zugriff habe, sich aber /vhosts/[domain]/htdocs in /web befindet, habe ich 1 und 1 zusammen gezählt und es für logisch befunden, die Datei in /htdocs hochzuladen. Somit wäre es auch auch in /web.

---

Mit web ist der web Unterordner deiner (zukünftigen) Contao Installation gemeint.

Näheres findest du auch in der offiziellen Dokumentation: https://docs.contao.org/manual/de/in...-installieren/

Zitat:

---

Zitat von Spooky

Mit web ist der web Unterordner deiner (zukünftigen) Contao Installation gemeint.

Näheres findest du auch in der offiziellen Dokumentation: https://docs.contao.org/manual/de/in...-installieren/

---

Danke für den Link. Da frage ich mich, wieso exakt dieser Link nicht auf der Download-Seite steht. Die Download-Seite suggeriert, dass die Installation ganz einfach sei und es keine weiteren Informationen benötigt. Daher habe ich tatsächlich nur nach dem Problem und einer möglichen Lösung recherchiert, nicht aber nach einer Installationsanleitung. Da ich die wenigen Informationen, die auf der Downloadseite standen, für die eigentliche Anleitung hielt.

Vielleicht liest dieses Feedback ja einer der zuständigen Personen. Es schadet wirklich nicht, halb-konkrete Informationen, die so alleinstehend nichtsaussagend sind und scheinbar in die falsche Richtung lenken, zu entfernen und stattdessen auf der Download-Seite direkt auf diese Installationsanleitung hinzuweisen.

Danke nochmal!

Feedback für die Webseite kannst du hier geben: https://github.com/contao/website/issues

Problem ist eher, dass die Dokumentation leider noch nicht auf Englisch übersetzt ist. Siehe dazu auch https://github.com/contao/website/issues/100

Am Wochenende habe ich mir vorgenommen zumindest die Systemanforderungen auf Englisch zu übersetzen. Dann ist es auch kein Problem mehr, diese auf der Website zu verlinken.

Verzeihung, aber:
A) Die Dokumentation ist auf allen Seiten von contao.org ständig über den Link im Kopfbereich erreichbar. Ich bin mir nicht sicher, ob es da weitere Links braucht.
B) Sicher mag es Situationen geben, in denen man Installationsdateien einfach mal so ins Webroot wirft. Best Practice ist das allerdings im Jahr 2020 nicht mehr.
C) Gerne kannst Du Feature-Requests unter https://github.com/contao/website/issues stellen. Dort kannst Du auch reporten, was Dir fehlerhaft erscheint.

Beste Grüsse
Carolina

Ich verfasse ein Issue, vielleicht hilft das Feedback und eine entsprechende Optimierung der Angabe von Informationen auf der Downloadseite anderen Contao-Neulingen.

Zitat:

---

Zitat von Spooky

Hast du auf deinen Server:

1. Einen neuen Ordner für deine Contao Installation angelegt,
2. in diesem Ordner einen Ordner namens "web" angelegt,
3. die contao-manager.phar dort runtergeladen und nach contao-manager.phar.php umbenannt,
4. den Document Root der Domain auf diesen Ordner konfiguriert?

---

Also ich hab jetzt den htdocs-Ordner in web umbenannt und dann in der Konsole folgendes eingegeben, damit htdocs direkt auf web verweist:
$ cd /srv/data/web/vhosts/example.com/
$ ln -s web htdocs

Jetzt hab ich leider das Problem, dass auch bei dem nun erstellten symbolischen Link htdocs->web der Contao-Manager mit einem Error 500 meckert, dass der Ordner htdocs existiert. Ist das so gewollt oder quasi ein Bug? Es ist ja lediglich ein symbolischer Link... :/

Ich hab bei meinem Anbieter (Gandi) leider keine Möglichkeit gefunden, den Document Root Path zu ändern. Ich habe mich an den Kundendienst gewandt und der meinte, ich kann das eben mit diesem symbolischen Link lösen. Was mach ich jetzt?

Zitat:

---

Zitat von Shade

Ich hab bei meinem Anbieter (Gandi) leider keine Möglichkeit gefunden, den Document Root Path zu ändern.

---

Das ist eine Grundvoraussetzung für eine Web Applikationen mit Contao und ähnlichen Systemen.

Jein ;). Siehe z.B. uberspace, da gibt es auch einen funktionierenden Workaround. Allerdings gibt es dort wohl in einem übergeordneten Ordner eine entsprechende .htaccess, wie sieht denn das jetzt bei dir aus? Nach deinem ln Befehl sind ja htdocs und web im selben Ordner. Was dann in der Tat nicht klappt.

Zitat:

---

Zitat von Spooky

Das ist eine Grundvoraussetzung für eine Web Applikationen mit Contao und ähnlichen Systemen.

---

Hier mal die Reaktion vom Kundendienst, find ich auch interessant:

Zitat:

---

It doesn't make much sense for a CMS to care what the document root folder name is, and at the very least their software should be compatible with a symlink -- so it seems a bug in their software, as no technical reason is given for this restriction. All other CMS we've come across with a similar requirement work this way (allow a symlink), so the issue you encounter appears particular to Contao CMS.

Unfortunately it's not possible to modify the DocumentRoot on the Simple Hosting platform.

---

Könnte es sich vielleicht tatsächlich um einen Bug handeln, bzw. um einen nicht berücksichtigen Sonderfall?
Die Fehlermeldung lautet ja auch u.A. "You must either manually repair your application or remove the following files and folders to install Contao", d.h. die Software denkt vermutlich, dass htdocs ein vollwertiger Ordner sei, obwohl er das gar nicht ist.
_____________

Zitat:

---

Zitat von tab

Jein ;). Siehe z.B. uberspace, da gibt es auch einen funktionierenden Workaround. Allerdings gibt es dort wohl in einem übergeordneten Ordner eine entsprechende .htaccess, wie sieht denn das jetzt bei dir aus? Nach deinem ln Befehl sind ja htdocs und web im selben Ordner. Was dann in der Tat nicht klappt.

---

Hm, kann ich mal probieren. Aber die Frage ist, wie wird die .htaccess aufgerufen? Denn ohne htdocs Ordner wird ja im Browser quasi gar nichts geladen. Oder verstehe ich was falsch?

Naja, des Einen Bug ist des Anderen Feature. Und man könnte zumindest mit der selben Berechtigung sagen, dass es ein Bug - oder zumindest eine schwere Beschränkung des Hosters - ist, die document root nicht selbst wählen zu können.
Wie uberspace das macht, kann man hier nachlesen: https://wiki.uberspace.de/domain:subdomain. Ich fürchte nur, das lässt sich hier zumindest nicht 1:1 übertragen.
Andererseits, geht vielleicht sowas in der Art wie das hier?

Code:

---

ln -s /srv/data/web/vhosts/example.com/projekt/web /srv/data/web/vhosts/example.com/htdocs

---

Zitat:

---

Zitat von tab

Naja, des Einen Bug ist des Anderen Feature. Und man könnte zumindest mit der selben Berechtigung sagen, dass es ein Bug - oder zumindest eine schwere Beschränkung des Hosters - ist, die document root nicht selbst wählen zu können.
Wie uberspace das macht, kann man hier nachlesen: https://wiki.uberspace.de/domain:subdomain. Ich fürchte nur, das lässt sich hier zumindest nicht 1:1 übertragen.
Andererseits, geht vielleicht sowas in der Art wie das hier?

Code:

---

ln -s /srv/data/web/vhosts/example.com/projekt/web /srv/data/web/vhosts/example.com/htdocs

---

---

Wunderbar, das hat funktioniert! Danke für diesen Workaround. :) Da muss man aber auch erstmal drauf kommen. Diese ganze Thematik wäre sicherlich eine Erwähnung im Contao-Handbuch wert. Ich bin sicherlich nicht der Erste, der damit zu kämpfen hatte.

Zitat:

---

Zitat von Shade

Diese ganze Thematik wäre sicherlich eine Erwähnung im Contao-Handbuch wert. Ich bin sicherlich nicht der Erste, der damit zu kämpfen hatte.

---

Ich denke eher nicht, daß das ins Handbuch sollte, denn meiner Erfahrung nach ist es schon üblich, daß man das Verzeichnis, aus der der Webserver eine Domain ausliefern soll (den Webroot) individuell festlegen kann. Andere User würde die Angabe eines solchen Befehls — der für sie nicht relevant ist — wahrscheinlich nur bei eventuellen anderen Problemem in eine vollkommen falsch Richtung schicken.

My 2ct.

Zitat:

---

Zitat von Shade

Hier mal die Reaktion vom Kundendienst, find ich auch interessant:

Zitat:

---

It doesn't make much sense for a CMS to care what the document root folder name is, and at the very least their software should be compatible with a symlink -- so it seems a bug in their software, as no technical reason is given for this restriction. All other CMS we've come across with a similar requirement work this way (allow a symlink), so the issue you encounter appears particular to Contao CMS.

Unfortunately it's not possible to modify the DocumentRoot on the Simple Hosting platform.

---

---

Du kannst dem Hoster ja folgende Liste schicken (jeweils mit Link zur Dokumentation, wo das beschrieben ist):

• Contao
• Craft CMS
• Drupal *
• Laravel Applikationen
• Magento 2 *
• Neos
• October CMS *
• Pimcore
• Symfony Applikationen
• Typo3
• unite cms

All diese Systeme verlangen oder empfehlen den Document Root auf einen Unterorder der Installation zu setzen. Die mit * gekennzeichneten Applikationen unterstützen auch den Betrieb direkt im Installationsverzeichnis, empfehlen aber jeweils einen Unterordner als Document Root zu verwenden. Denn dieses Verfahren hat ja einen Sinn: die Sicherheit der Installation zu gewährleisten, durch die physische Trennung von öffentlichen und nicht öffentlich einsehbaren Dateien.

Diese Liste an Content Management Systemen oder Frameworks spiegelt auch die Liste an Systemen, die ich persönlich kenne. Nur WordPress würde fehlen (abgesehen von Systemen, die ausschließlich ihren eigenen Web Server mitbringen). Daher frage ich mich welche Systeme dieser Hoster kennt. Aber vielleicht haben sie ja auch tatsächlich nur gemeint, dass man bei allen Systemen, bei diesem billigen Hosting Paket, eben dann einen Symlink machen muss.

Zitat:

---

Zitat von Spooky

All diese Systeme verlangen oder empfehlen den Document Root auf einen Unterorder der Installation zu setzen.

---

Inwieweit wäre bei einem symbolischen Link von /htdocs auf /web die Sicherheit gefährdet? In dem Fall würden ja die Dateien, die physisch vom öffentlich einsehbaren Bereich getrennt sein sollen, auf der gleichen Höhe wie der symbolische Link liegen. Sie sind also physikalisch getrennt.
Davon abgesehen: Was spricht dagegen, die Zugriffsberechtigungen über chmod und/oder .htaccess zu regeln? Oder ist die physische Trennung einfach eine Lösung, die "sauberer" ist?
Ich will dir keinesfalls widersprechen bei dem, was du sagst. Ich will nur den Sinn verstehen und dazulernen. Deinen Text habe ich weitergeleitet an meinen Anbieter, danke!

Zitat:

---

Zitat von Shade

Inwieweit wäre bei einem symbolischen Link von /htdocs auf /web die Sicherheit gefährdet? In dem Fall würden ja die Dateien, die physisch vom öffentlich einsehbaren Bereich getrennt sein sollen, auf der gleichen Höhe wie der symbolische Link liegen. Sie sind also physikalisch getrennt.

---

Solange sich der Inhalt, der geschützt werden soll, außerhalb des Document Root befindet, also nicht öffentlich einsehbar ist, passt es.

Zitat:

---

Zitat von Shade

Davon abgesehen: Was spricht dagegen, die Zugriffsberechtigungen über chmod und/oder .htaccess zu regeln? Oder ist die physische Trennung einfach eine Lösung, die "sauberer" ist?!

---

chmod bringt dir in diesem Fall nichts, denn die Dateien müssen ja sowieso vom Web Server gelesen werden können. Nur über .htaccess zu regeln birgt die Gefahr, dass man sich auf die Server Konfiguration verlassen muss - und dass keine .htaccess falsch konfiguriert ist und kein Ordner übersehen wird.

Und nur um noch einen weiteren Grund zu nennen, warum das Setzen des Document Roots auf einen Unterordner der Applikation ein Standard Verfahren ist oder sein sollte: man läuft automatisch nicht in diese peinliche Sicherheitslücke, ohne jemals darüber nachgedacht haben zu müssen.

Insofern finde ich es auch fahrlässig, wenn ein Hoster dies nicht erlaubt.