Druckbare Version
Mich würde mal interessieren, welche Funktionen das sein sollen, die den Zugriff auf das /tmp-Verzeichnis benötigen. Ich habe mir eben die FTP-Klasse und auch die anderen Files-Bibliotheken des Core angesehen, und keine davon nutzt das /tmp-Verzeichnis des Servers. Es wird immer in system/tmp geschrieben. Wofür ist der putenv('TMPDIR')-Hack denn überhaupt notwendig?Zitat:
Zitat von acenes
Es handelt sich nicht um die TYPOlight Klassen, sondern um einzelne Funktionen der FTP Library von PHP selber (z.B. ftp_nlist). Ob auch andere PHP Libraries das System-TMP Verzeichnis verwenden weiss ich nicht, würde es aber nicht ausschliessen.
Danke für die Erläuterung. Ich werde es testen sobald ich meinen HE-Account habe und dann hier berichten.
Hm, vielleicht ein klassischer Vorführeffekt, jedenfalls habe ich TYPOlight gerade bei HE installiert und alles läuft problemlos auch ohne den putenv()-Hack. Was genau muss ich tun, um den Fehler auszulösen? Ich habe schon sämtliche Dateioperationen (Upload, Rename, Move, Delete etc.) erfolgreich getestet.
Normalerweise werden doch auch Dateien, die via HTTP auf den Server geladen werden erstmal im Tmp Verzeichnis gesichert. Das kann man aber auch umstellen.
PHP Doku:Zitat:
Standardmäßig werden Dateien in dem vorgegebenen temporären Verzeichnis des Servers gespeichert, außer es wurde mittels upload_tmp_dir in der php.ini ein anderer Ort konfiguriert. Das Standardverzeichnis des Servers kann durch das Setzen der Umgebungsvariablen TMPDIR in der Umgebung, in der PHP ausgeführt wird, geändert werden. Das Setzen mittels der Funktion putenv() innerhalb eines Skriptes ist nicht möglich. Mittels dieser Umgebungsvariable kann auch sichergestellt werden, dass auch andere Operationen an hochgeladenen Dateien arbeiten können.
Kann es sein, dass HE dazu gelernt hat und das tmp-Verzeichnis jetzt richtig setzt? Der Screenshot stammt von der Übersichtsseite im KIS.
Lt. Changelogs hat es in diesem Punkt seit 2007 keine Änderungen durch HE gegeben. So gesehen habe ich den 'TMPDIR'-Hack da auch noch nie benötigt. Hatte das mal im vergangenen Jahr getestet und konnte keinen Effekt feststellen.Zitat:
Zitat von leo
Carolina.
Ob dieser neuen Erkenntnisse schlage ich folgende Änderungen vor:
1. Einführung einer system/initconfig.php
Die Datei kann dann dazu verwendet werden, beliebigen Code am Anfang des Initialisierungsprozesses update-sicher einzufügen. Das kann beispielsweise der putenv()-Hack sein oder auch ein PHPIDS-Skript usw. Die Einführung ist aber erst mit dem nächsten Minor-Release möglich.
2. Kleines "Convenience-Feature" in der libraries/FTP.php
Auf diese Weise werden die drei Ordner automatisch auf CHMOD 777 gesetzt. Diese Änderung könnten wir theoretisch in das nächste Maintenance-Release aufnehmen. Ein paar unabhängige Tests wären trotzdem nicht verkehrt.PHP-Code:protected function __construct($resConnection)
{
if (!is_resource($resConnection))
{
throw new Exception('Class FTP requires a valid FTP connection resource');
}
$this->resConnection = $resConnection;
// Make folders writable
if (!is_writable(TL_ROOT . '/system/tmp'))
{
$this->chmod('system/tmp', 0777);
}
if (!is_writable(TL_ROOT . '/system/html'))
{
$this->chmod('system/html', 0777);
}
if (!is_writable(TL_ROOT . '/system/logs'))
{
$this->chmod('system/logs', 0777);
}
}
Kurze anmerkung zu der /tmp Geschichte und dem Kommentar das einige Hoster es nicht begreifen das man dort Zugriff braucht.
Ich denke viel mehr das die Hoster mit Absicht kein Zugriff auf das globale /tmp Verzeichniss erlauben. Wenn alle Kunden auf einem Server dort ihre temporären Daten speichern würden, könnte es z.B. bei Sessiondaten zu Sicherheitsproblemen führen. Andere Kunden könnten die Sessiondaten auslesen und sich somit Zugriff auf eine Seite verschaffen.
Von daher finde ich es absolut berechtigt wenn den Kunden der Zugriff auf das /tmp Verzeichniss verwehrt bleibt.
Gruß Holger
Dagegen sagt ja niemand was, nur muss man diesen Schritt als Provider auch zu Ende denken und eine Alternative zum globalen /tmp-Verzeichnis anbieten, denn PHP benötigt definitiv Zugriff auf ein temporäres Verzeichnis. Scheinbar hat HE das jetzt ja auch gemacht, also ist das putenv()-Problem endlich gelöst.
Halleluja.Zitat:
Zitat von leo
Ich scheine hier bei hosting-agency.de ein ähnliches Problem zu haben.
(Providerwahl sollte laut Liste problemlos sein, soll/kann auch nicht diskutiert werden. :-( )
Phänomen ist, dass das install-Tool zwar behauptet, localconfig.php sei schreibbar, aber schon die Eingabe eines neuen Passwortes nicht gelingt.
Das Tool bleibt in dem Zustand und fragt immer wieder neu, aber nicht aufgrund eines Fehlers beim Passwort, wie z.B. zu wenige Buchstaben, oder Password missmatch.
Diese Poblem habe ich schon woanders im Forum gesehen, aber (bisher) ungelöst.
Das Tool smhcheck.php steigt auch mit unterschiedlichsten Fehlern aus.
Ich habe hier auch verschiedensten Variationen für
upload_tmp_dir
und putenv('TMPDIR')
etc.
ausprobiert. Einige Fehler deuten tatsächlich darauf hin, dass die Routinen in/ auf unterschiedlichen tmp-Verzeichnissen arbeiten.
So gibt nach Erstellung des tmpfiles eine Auflistung des ftp-Verzeichnisses
$list = ftp_nlist($conn, $GLOBALS['TL_CONFIG']['ftpPath'] . 'system/tmp/');
nicht den Inhalt von system/tmp aus!
Faktisch wächst /tmp mit jedem Aufruf von smhcheck, während system/tmp immer wieder geleert wird.
Andererseits scheint auch das smhcheck-Tool nicht frei von Fehlern/Problemen, so liefert ftp_rmdir(smhckeck.dir) anscheinend immer false, was evtl. einfach mit der Warning zu tun hat, die die Funktion immer ausgibt.
phpinfo gibt aus, dass upload_tmp_dir nicht gesetzt ist
aber /tmp ist auch open_basedir und zumindest smhcheck.php setzt dann als default /tmp an!?
Das smhcheck-Tool liefert auch
System temporary dir: /tmp
unabhängig davon, wie TMP, TEMP, TMPDIR per putenv gesetzt werden.
Der Pfad zum FTP-Root ist
/home/<accountname>
und darunter liegt das Web-root in
/home/<accountname>/public_html
Die Typolight-Installation liegt direkt in public_html.
Das Problem hatte auch zumindest ein anderer User, aber dort wurde keine Antwort gefunden.
Ich selber weiß jetzt auch nicht weiter und bin für jede Hilfe dankbar.
das sollte der Titel der vorigen Anfrage sein aber da habe ich wohl zu schnell auf Enter gedrückt? ;)
Als Ergänzung des vorigen Beitrages noch, dass das install-Tool in system/tmp wohl drei temporäre Dateien anlegt, mit Einträgen
$GLOBALS['TL_CONFIG']['websitePath'] = '';
und auch
$GLOBALS['TL_CONFIG']['installPassword'] = '2b512af91007bcdf8d2b4addd7fecc8b7a10bdd4:9fb2bea3 886babb75af1cb6';
aber dann geht es irgendwie nicht weiter?
Wieso denkst du dass du mit TMPDIR hantieren musst?
Was gibt denn smhcheck genau aus wenn du das mal weglässt?
Und wo können wir den Output des TL system check tools sehen?
Hi,
darf ich in diesem Zusammenhang auch noch auf das Ticket #754 verweisen. Auch dort geht es um das TMP-Verzeichnis im Zusammenhang mit Soap. Die oben geschilderte Rechteproblematik dürfte sich dann auch an dieser Stelle auswirken, was ein hinreichender Grund wäre, dieses TMP-Verzeichnis doch auch mal verlegen zu wollen. Vielleicht kann man da in diesem Zug auch gleich noch mit berücksichtigen bzw. prüfen.
Jan
Wenn ich mehr zu dem Verfahren wüsste, wie der SMH funktioniert, könnte ich velileicht gezielter vorgehen.Zitat:
Zitat von acenes
Beobachtung ist, dass das install-Tool in system/tmp oder /tmp anscheinend einen neuen localconfig.php-File vorbereitet, der aber "irgendwie" nicht an den richtigen Ort gelangt?
Hier zunächst Links zu den Ausgaben:
http://www.montessorischule-reumonts...ight-check.php
http://www.montessorischule-reumonts...check-orig.php
http://www.montessorischule-reumonts...de/phpinfo.php
Ich bin mir recht sicher, dass die Ausgabe von smhcheck-orig.php abbricht. weil er in der if-Abfrage nach
!in_array($GLOBALS['TL_CONFIG']['ftpPath'] . $tmpName, $list))
mit $tmpName = 'system/tmp/' . md5(uniqid('', true));
sucht, $list aber den Verzeichnisinhalt ohne den Pfad ausgibt system/tmp ausgibt!
Das ist in
http://www.montessorischule-reumonts...e/smhcheck.php
mal geändert, sowie ein weiteres Problem mit ftp_rmdir. Dieses Komando löscht nachweislich das angelegte smhcheck.dir (sehe ich ja per ftp) liefert aber dennoch "FALSE".
Die temporären Files werden im übrigen am Ende des Skriptes nicht gelöscht, was aber keine Fehlermeldung generiert. Nun weiß ich nicht, was genau der verwendete unlink-Befehl tut.
Da upload_tmp_dir nicht gesetzt ist, wie der Ausgabe von phpinfo zu entnehmen ist, habe ich in initialize.php aktuell keinen putenv-Hack angewendet.
smhcheck gibt klar und deutlich aus dass der FTP TL-path (momentan public_html/) falsch eingestellt ist.
Bring das in Ordnung und alles funktioniert wie es soll.
Hier habe ich schon jede denkbare Einstellung probiert, sonst hätte ich mir nicht die ganze Arbeit gemacht.Zitat:
Zitat von acenes
Die Anleitung besagt, dass ftpPath der Pfad zum Root-Verzeischnis von tl ist ausgehend vom ftp-Home.
Im ftp-Home finden sich bei hosting-agency.de die Verzeichnisse
cronjobs
databases
public_html
In public_html befinden sich die tl-files, demnach gibt es aus meiner Sicht nur die Möglichkeiten
public_html/
/public_html/
/public_html
wobei letztere ausdrücklich als falsch angemerkt wird.
Weiterhin sagt das Install-Tool, dass es localconfig.php findet und schreiben könne?
/home/u0094349827/public_html/
Auch schon versucht?
Dann kommt der Abbruch noch früher, nämlich schon beiZitat:
Zitat von acenes
Check for correct directory ..
weil sich dieser Pfad nicht im ftp-root findet.
Kann man irgendwo nachlesen (ohne durch den Code zu gehen), wie typolight im SMH Dateien kopiert/editiert?
Alle ftp-Befehle in smhcheck.php scheinen zu funktionieren und ich sehe die erzeugten Dateien und Verzeichnisse ja auch, wenn ich das Löschen unterbinde.
Was also hält das install-Tool davon ab, seine Datei nach system/conf zu schreiben?
Rätsel über Rätsel.
Was ich "herausgefunden" habe ist, dass bei der Verwendung von ftp_put in /tmp Dateien erzeugt werden, die root gehören, was zu dem Output von typolight-check.php unter
"File permissions" passen könnte? Andererseits ist das ja wohl genau der Part, der prüft, ob es ohne SMH geht?
Juchu, ich kann’s bestätigen!Zitat:
Zitat von leo
Meine TYPOlight Installationen bei HE funktionieren nun ohne den putenv('TMPDIR')-Hack. :)
Grüße
Stephan