Liste der Anhänge anzeigen (Anzahl: 1)
Contao 2 1und1 Problem
Hallo zusammen,
also normal klappt es relativ gut mit 1und1 und contao2, aber diesmal hab ich ein Problem, die Seite wird zwar angezeigt "http://s476701380.online.de/" aber die Backend Anmeldung geht nicht... Die Backend Anmeldemaske wird angezeigt.. Aber nach der Anmeldung passiert nichts... Sehr nur ein weissen Bildschirm... Andere Browser hab ich probiert.
Hab den Check drüber laufen lassen. Siehe Screen.
Da ich dachte das vielleicht ein Problem besteht mit einer Datei oder SQL, habe ich die Seite 2 mal hoch geladen... bei mir auf den Server geht die Einwandfrei.
Chmod hab ich auf 755 laufen lassen
Php 5.4
MySQL5
Contao 2.11.11
Jemand eine Idee?
Viele Grüße
Marco
Änderung der Dateirechte bei 1&1
Hallo,
ich möchte mich hier mal einklinken. Wir haben als Firma einen Managed Server bei 1&1 mit zahlreichen Contao-Installationen. Bisher keine Probleme, alle liefen ohne Safe-Mode-Hack.
Neuerdings erhalte ich aber beim Contao-Check auch den Hinweis wie von Maggo gepostet, dass der Safe-Mode-Hack benötigt wird. Die Dateirechte, egal ob bei Upload oder auf dem Server erzeugten Files, haben sich geändert und sind jetzt 604 bzw. 705!
Ich bin seit ein paar Tagen per Mail in Kontakt mit dem 1&1-Support und bekomme nur Sätze zu hören wie:
"Es gibt keine serverseitigen Umstellung von Dateirechten." oder "Wir nehmen außer bei von uns gesetzten Dateien (logs-Ordner, Control-Center Funktionen) keine Rechteeinstellungen vor. Falsch gesetzte Werte werden in der Regel durch Optionen/Vorgaben der eigenen verwendeten Software hervorgerufen." und zur Krönung: "Wir bedauern sehr, dass wir Ihnen dieses Mal keine Lösung anbieten können."
Kann jemand verraten, wie ich selbst diese Werte ändern kann? Ich habe ja vollen SSH-Zugriff und kann z.B. auch eigene php.ini-Dateien anlegen.
Noch funktionieren die alten Contao-Installationen, aber ich befürchte, dass künftig mit Problemen zu rechnen ist.
Gruß,
Ignatz
1und1 andere Rechte und SMH - Probleme seit Server Umstellung?
Zitat:
Zitat von
Ignatz
Hallo,
ich möchte mich hier mal einklinken. Wir haben als Firma einen Managed Server bei 1&1 mit zahlreichen Contao-Installationen. Bisher keine Probleme, alle liefen ohne Safe-Mode-Hack.
Neuerdings erhalte ich aber beim Contao-Check auch den Hinweis wie von Maggo gepostet, dass der Safe-Mode-Hack benötigt wird. Die Dateirechte, egal ob bei Upload oder auf dem Server erzeugten Files, haben sich geändert und sind jetzt 604 bzw. 705!
Ich bin seit ein paar Tagen per Mail in Kontakt mit dem 1&1-Support und bekomme nur Sätze zu hören wie:
"Es gibt keine serverseitigen Umstellung von Dateirechten." oder "Wir nehmen außer bei von uns gesetzten Dateien (logs-Ordner, Control-Center Funktionen) keine Rechteeinstellungen vor. Falsch gesetzte Werte werden in der Regel durch Optionen/Vorgaben der eigenen verwendeten Software hervorgerufen." und zur Krönung: "Wir bedauern sehr, dass wir Ihnen dieses Mal keine Lösung anbieten können."
Kann jemand verraten, wie ich selbst diese Werte ändern kann? Ich habe ja vollen SSH-Zugriff und kann z.B. auch eigene php.ini-Dateien anlegen.
Noch funktionieren die alten Contao-Installationen, aber ich befürchte, dass künftig mit Problemen zu rechnen ist.
Gruß,
Ignatz
Hallo Ignatz,
Bei mir liegt der Fall ähnlich: Habe mindestens 10 Kunden, die bei 1u1 seit vielen Jahren ihre Website in shared hosting Paketen haben.
Nach und nach hab ich alle auf Contao bzw. Typolight umgestellt, angefangen bei TL 2.6 bis aktuell 3.0.6
Bisher kaum Probleme, früher musste man ja noch in die .htaccess den switch auf php5 reinschreiben, alles kein Problem.
Aber neuerdings werden alle Kunden genötigt, auf 5.4 umzustellen (5.3 steht nicht zur Verfügung).
Dies hab ich gemacht für einen anstehenden Relaunch, dann check tool und - schock: Meldung, Contao läuft nur noch mit SMH!
Dazu verweist mich der Support-MA auf diesen Hilfe Link, der mich auch nicht weiterbringt.
Umziehen auf WHO o.ä. will der Kunde nicht, auch wg. den vielen Email-Accounts usw.
Was tun???
Falls Ihr hierzu eine Lösung habt, wäre super, sonst könnten auch bei weiteren Installationen Probleme drohen - sobald nämlich 1u1 alle Server auf 5.4 umgestellt hat...
Gruß,
compadre
Liste der Anhänge anzeigen (Anzahl: 1)
chmod und SMH bei 1und1 für Contao 3 und PHP 5.4
Heute habe ich Antwort bekommen von 1u1:
Zitat:
vielen Dank für Ihre E-Mail, die wir Ihnen gerne beantworten. Sie haben uns mitgeteilt, dass es nach der Umstellung auf PHP 5.4 zu technischen Problemen mit Contao kommt.
Durch die Umstellung auf PHP 5.4 werden von uns keine Dateirechte geändert. Sind einige Dateirechte für Contao unter PHP 5.4 nicht korrekt, können Sie diese selbst ändern.
Wir wünschen Ihnen gutes Gelingen.
Wo müsste ich denn hier selbst die Berechtigungen setzen?
Jemand ne Ahnung? Hier nochmal die Meldung des checkt-tools:
Anhang 11310
Was mich irritiert ist, dass bisher alles glatt ging bei 1u1....
Danke an alle,
Grüße,
compadre
Also gar keine Probleme bei 1und1?
Bin kein Programmierer, aber wenn ich das recht verstehe, dann kann ich Contao 3.x auf 1und1 shared hosting server mit PHP 5.4 trotz (falscher) check-Warnung problemlos installieren, ohne SMH?
Bitte korrigiere mich jemand, falls ich falsch liege...
Habe die script Ergänzung in die index.php reingepastet und siehe da alles wird grün...
Die Frage ist, muss ich irgendwas in der localconfig anpassen / ändern in der Contao Installation? Oder ist das einfach ein bug im Check Tool?
Danke + Grüße,
compadre
1und1 Dual Basic, umask 0072
Moin,
ich habe gerade bei 1&1 das Webhosting "Dual Basic" (6,99€/Monat) gekauft und erprobe es gerade. Im Großen und Ganzen nicht schlecht für den Preis.
Aber ich hatte mit dem Contao 3.1.1 check das gleiche Problem, wie Maggo1982 (siehe Maggos Screenshot in #1):
- Ordner werden mit 0705 (drwx---r-x) erzeugt (via PHP und SSH)
- Dateien werden mit 0604 (-rw----r--) erzeugt(via PHP und SSH)
Der BESITZER hat also Lese/Schreibrechte, die GRUPPE keine Rechte, aber ANDERE dürfen lesen.
Das ist schon merkwürdig: die Gruppen-Mitglieder des Besitzers sindt ja auch ein ANDERE und dürfen dann ebenfalls lesen. Oder?
Es stellte sich heraus, dass die umask in SSH und PHP bei diesem Paket (zur Zeit) auf 0072 steht, Standard auf Linux Systemen ist 0022.
ABER Dateien, die ich per FTP hochlade, haben eindeutig eine umask 0022. Daraus schließe ich, dass Datei/Verzeichnis-Rechte 0644/0755 offenbar bei 1&1 durchaus erlaubt und erwünscht sind. Die default umask 0072 für SSH und PHP halte ich für einen Fehler seitens 1und1.
Das Problem mit der 1&1 Fehl-Konfiguration läßt sich leicht nachvollziehen: per SSH einloggen, dann "umask". Oder "touch test.txt" bzw. "mkdir test.dir". Auch ein "tar xzf contao-3.1.1.tar.gz" ist betroffen. Auf der SSH Kommandozeile läßt sich das mit "umask 022" direkt nach dem Login natürlich korrigieren. Eventuell auch über .profile etc, bisher nicht erprobt. Aber Apache/PHP haben immer noch umask 0072.
Eine umask 0072 bedeutet, dass Dateien/Verzeichnisse, die "einfach so" (ohne anschließendes, ausdrückliches "chmod") erzeugt werden, der Besitzer-Gruppe keinerlei Rechte gewähren. 0022 dagegen erlaubt auch der GRUPPE die gleichen Rechte, wie ANDEREN.
Der telefonische Service von 1&1 ist heute total überlastet, deshalb kann ich keine Stellungnahme des 1&1 Supports dazu weitergeben.
Mein Workaround bisher ist das Patchen von Contao an 2 Stellen:
- im Contao check (...../check/index.php) ziemlich am Anfang:
Code:
--- index.php 2013-06-25 11:11:50.000000000 +0200
+++ index.php.NEW 2013-07-17 03:05:12.993000000 +0200
@@ -10,6 +10,8 @@
* @license http://www.gnu.org/licenses/lgpl-3.0.html LGPL
*/
+umask(022);
+
require 'controller/bootstrap.php';
Danach ist alles grün. - in (...../system/initialize.php) auch ziemlich am Anfang:
Code:
--- initialize.php 2013-06-25 17:38:25.000000000 +0200
+++ initialize.php.NEW 2013-07-17 03:05:55.727375000 +0200
@@ -16,6 +16,8 @@
*/
define('TL_START', microtime(true));
+umask(022);
+
/**
* Define the root path to the Contao installation
Ich habe diese Datei gewählt, weil sie sicher sowohl vom Frontend, wie auch vom Backend, wie auch vom Install-Tool als erstes includiert wird. Das umask(022) in ...../system/config/localconfig.php, wie von @xtra vorgeschlagen, könnte auch funktionieren. Habe ich aber nicht probiert, weil bei Aufruf des Install-Tools diese Datei ja noch nicht existiert.
HTH, Georg
PS: Danke an alle, die mich auf die (hoffentlich) richtige Spur "umask" gebracht haben!
