Beiträge von herrmann

Hab die Änderungen zunächst nicht vorgenommen, sondern erst mal nur ein diff auf die gepatchte und die ungepatchte Version gemacht - hat schon gereicht, den Fehler zu finden:

In der /administrator/components/com_joomlaupdate/models/default.php, in der /libraries/joomla/updater/updateadapter.php und in der /libraries/joomla/updater/update.php fehlt jeweils eine schließende Klammer in der Zeile

>               if ($response === null || !in_array($response->code, $allowedResponseCodes)

Dann habe ich nur die /administrator/components/com_joomlaupdate/models/default.php entspr. deinem Vorschlag korrigiert, die fehlende Klammer ergänzt und (keine Ahnung, ob das von Bedeutung ist) das überflüssige Komma hinter der 303 in der Arraydefinition entfernt. Jetzt läuft der Update durch - Ahaaaber: Im Moment läuft der Update sogar auch dann durch, wenn ich die gute alte kaputte Version mit dem Vergleich auf die 310 einsetze. Offenbar lande ich im Moment nur auf Update-Servern, die einen RC von 200 schicken.

Hallo Zero24, Sorry, hab länger nicht mehr reingeschaut. Zwecks Beschleunigung der Kommunikation könnten wir evtl. per Mail kommunizieren. Ich heisse schorsch, und mein Mail-Server heisst schorsch.de

Ich habe den Patch angewandt und getestet. Und dann habe ich im Patchtester keine Möglichkeit gefunden, eine Rückmeldung zum Testergebnis zu erstellen und zu versenden. Daher hier:

Wenn ich den Patch anwende, und dann auf der Hauptseite auf Maintenance-> Checking Joomla (bzw. imMenu Components-> Joomla! Update) klicke, öffnet ein leeres Fenster. Ziehe ich den Patch wieder zurück, öffnet wieder das gewohnte Fenster mit dem 'Check for Updates'-Button.

deGobbis: /etc/php5/apache2/php.ini:allow_url_fopen = On

zero24: Ich würd's ja testen - aber entweder ist das Test-Repository gerade kaputt, oder ich mach irgendwas falsch. Wenn ich, der Dokumentation folgend, joomla-cms-staging.zip in einen Ordner 'bugtesting' entpacke und die entspr. Adresse aufrufe, bekomme ich nur eine leere Seite angezeigt.

Gehe ich dagegen hin und entpacke stattdessen testweise die Joomla_3.6.4-Stable-Full_Package.zip in diesen Ordner, bekome ich - erwartungsgemäß - die 'Joomla Webinstallation' angezeigt.

Re:Later: Ok, jetzt hab ich verstanden, worauf du hinaus willst.

Aber heute nicht mehr, ab sofort ist Wochenende!

mizapf: Ubuntu ist hier nicht verantwortlich zu machen. Ubuntu ist nur verantwortlich für die Packages, die Ubuntu selbst anbietet, und da gehört Joomla nicht zu.

Es ist ja auch nicht so, dass curl zwingende Installationsvoraussetzung wäre. Der Fehler ist tatsächlich in der Update-Funktion zu suchen und ich vermute, dass der von zero-24 vorgeschlagene Patch allerspätestens irgendwann auch seinen Eingang in den Joomla-Quellcode finden wird.

Die 310 wird schlicht ein Zahlendreher sein. 301 ist 'Moved Permanently', und dieser Code zeigt genauso einen Erfolg an, wie die Codes 200 'OK', 302 'Found' und 303 'See other'.

Und genau dem entsprechend hat zero-24 seinen Patch-Vorschlag auch formuliert https://github.com/joomla/joomla-cms/pull/11845</a>

Wir gackern hier also über längst gelegte Eier... Die nur dummerweise ihren Eingang ins Stable Release irgendwie bislang verpasst haben.

Re:Later: Dass hier vom ausliefernden Server ein "eigener" Code erwartet wird, kann nicht sein. Die Anfrage richtet sich an github, und github richtet die Anfrage per round robin an irgendeinen Server in der amazon-cloud weiter - und da die Joomla-Entwickler auf keinen dieser Server Einfluss haben, haben sie auch keinen Einfluß auf deren Statuscodes.

Aber egal; wie mizapf schon schrieb: apt-get install php5-curl; service apache2 restart - und die Sache läuft rund!

Der Wert 303 in $result->code scheint tatsächlich nicht zum Ergebnis zu passen, da $result->body ja den erfolgreichen Download enthält. Ich denke aber, dass diese Rückgabe völlig rfc-konform und daher gleichwertig wie 200 zu behandeln ist. Die if-Anweisung prüft aber auf 310 - und dieser Wert ist als http-Statuscode nicht rfc-konform.

Andererseits enthält $result->code genaugenommen keinen http-Statuscode, sondern den Returncode des Aufrufs eines Objekts vom Typ JHttpFactory::getHttp - und da mag die 310 sehr wohl einen legitimen Wert darstellen. Ich hab versucht, in der Joomla-Dokumentation weitere Informationen dazu zu finden, bin aber bislang nicht fündig geworden. Ist eigentlich auch nicht mein Job, sondern der der Joomla Entwickler...

SilOrs67: Wenn du diesen Thread etwas aufmerksamer gelesen hättest, hättest du gemerkt, dass ich hier schon lange keine Hilfe mehr suche, dass mein Problem vielmehr längst behoben ist und dass ich durchaus in der Lage bin, 'ein Update aufzubügeln'.

Mir geht es hier vielmehr darum mitzuhelfen, die Ursache für das Versagen des Joomla-Updates zu ermitteln. Einmal um anderen zu helfen, die das gleiche Problem für sich noch nicht gelöst haben, zum anderen, um eine allgemeine zukunftsfähige Lösung für dieses Problem zu finden.

Wenn du in meinen wohlbegründeten Beiträgen hier einen 'unqualifizierten Kommentar' findest, der auch nur näherungsweise an die sehr bescheidene Qualität deines letzten Anwurfs heranreicht - dann darfst du mich noch mal an die Forenregeln erinnern. Bis dahin beherzigst du diese aber bitte selbst!

Hallo mizapf, es wäre interessant zu wissen, welche php-Version auf deiner openSUSE-Kiste läuft. Wenn das eine 5er Version < 5.6.26 ist, wäre das ein Hinweis darauf, dass tatsächlich (wie von mir oben schon vermutet) eines der letzten php-Updates zu einem geänderten Verhalten geführt hat.

Wow SilOrs67, du bist ja ein ganz Flotter. Da haben die Infos zackzack zu fliessen, und wenn wir nicht gleich liefern, bist du ruckzuck raus. Schneidiger Geist!

Hallo mizapf: Deine Idee, im Quellcode der ./administrator/components/com_joomlaupdate/models/default.php herum zu pfuschen, habe ich gerne aufgenommen. Zunächst habe ich es mir ganz einfach gemacht, und Zeile 319 schlicht auskommentiert:

317               if (!$result || ($result->code != 200 && $result->code != 310)) 318               { 319        /*               return false;          */320               }

Und was soll ich sagen - der Download läuft! Das Update wird herunter geladen und einwandfrei installiert!

Dann habe ich mir die Zeile 317 mal genauer angeschaut. Da wird auf zwei http-Codes verglichen, auf 200 (OK) und auf 310 (???). Ein http-Code 310 ist m. W. nirgends definiert. Ändere ich den Quellcode entsprechend zu

317               if (!$result || ($result->code != 200 && $result->code != 303)) 
318               { 
319                       return false;
320               }

funktionieren das Herunterladen und die Installation ebenfalls völlig störungsfrei!

Dumm nur: Nach erfolgreichem Update meine Änderung natürlich wieder überschrieben!

Da die php-Prozesse durch Apache aufgerufen werden, laufen sie unter der gleichen Benutzer-ID wie der Apache selbst, und dieser Benutzer ist der Eigentümer des Webs. Im übrigen haben alle Updates während der letzten anderthalb Jahre ohne weiteres, insbesondere ohne zusätzliche manuelle Eingriffe, auf Anhieb funktioniert. Erstmalig der Upgrade von 3.6.2 ist gescheitert.

Das konnte ich auch anhand eines alten Spiegels des Webservers eindeutig nachvollziehen:

• - Update von Joomla 3.4.7 auf 3.6.4 - keine Probleme
• - Neuinstallation der Joomla Kerndateien - keine Probleme
• - apt-get update; apt-get upgrade
• - Neuinstallation der Joomla Kerndateien - Crash!

Ähnliche Probleme hatte ich auch, auch bei mir ist der automatische Download des Installationspakets gescheitert. Ich habe dieses daher manuell herunter geladen und in den Ordner gelegt, in dem php temporäre Dateien erwartet. Das ist üblicherweise der temp-Pfad des Betriebssystems, unter Linux /tmp.

Stößt man das Update dann erneut an, wird das bereits herunter geladene Paket verwendet. Bei mir kam dann zwar die Fehlermeldung, dass die temporäre Datei nicht gelöscht werden konnte - aber das war völlig egal, Joomla erfolgreich aktualisiert. Wichtig ist halt, dass man das Paket in den Pfad legt, in den Joomla es auch legen würde.

Ich bin absolut kein Joomla-Experte, daher ist mein folgender Rat mit Vorsicht zu genießen: Ich vermute, dass als letzter Ausweg auch ein einfaches Herunterladen des Pakets von github und ein anschließendes schlichtes Entpacken in den Joomla-Ordner völlig ausreicht. Dabei muss man darauf achten, dass alle bereits bestehenden Dateien überschrieben werden. Du kannst auch irgendwo hin entpacken und dann den Inhalt über die alte Installation drüber kopieren. Können bestimmte Dateien nicht überschrieben werden, weil auf sie zugegriffen wird, müssen die Web-Dienste kurz beendet werden.

HTH

Ein Provider greift bei mir nicht in die Seite ein bzw. auf den Server zu. Aufs Betriebssystem habe nur ich Zugriff (meine Kollegen ebenfalls, aber die haben hier nicht eingegriffen). Insofern kann ich ausschließen, dass es Änderungen an den Dateizugriffsrechten gegeben hat. Hab ich aber auch noch mal geprüft, die passen...

Da die Joomla- und Apache-Logs hier wenig aussagekräftig sind, habe ich den Update-Vorgang mal gedumpt. Aus dem Dump lässt sich herauslesen, dass die Adresse des Update-Pakets sauber aufgelöst wird und der Download von irgendeinem Rechner aus der Amazon-Cloud gestartet wird. Der Download wird auch vollständig durchgeführt - aber auf der Platte landet nichts!

Wenn ich mich aber mittels su als User www-data anmelde, habe ich überhaupt kein Problem, das Update-Paket per wget ins Temp-Verzeichnis zu schreiben.

Ich betreibe den Server unter Debian und ich vermute, dass das php-Sicherheitsupdate DSA-3689-1 vom 8. Okt. (Auf php 5, Version 5.6.26) hier eine unrühmliche Rolle spielt. Es gab am Montag ein weiteres php-Update auf 5.6.27, aber das hatte ich gestern früh noch nicht eingespielt.

Ich habe versucht, das Problem zu reproduzieren. Dafür habe ich in der version.php die Versionskonstanten überschrieben. Danach meldet die Startseite zwar immer noch "Joomla ist aktuell". Wenn ich dann aber gezielt auf Aktualisierungen prüfen lasse, wird "eine neue Joomla!_Aktualisierung gefunden", und ich kann den Installationsvorgang starten.

Und jetzt bekomme ich konsequent den gleichen Fehler wie heute morgen, diesmal aber völlig unabhängig davon, ob der alte Super User gesperrt ist, oder nicht.

Schließlich habe ich die Bedingungen für ein erfolgreiches Update doch gezielt reproduzieren können. Wenn ich nämlich manuell, z. B. per wget oder per scp, das Update-Package direkt in den tmp-Pfad (php.ini) lege, kann ich anschließend die Aktualisierung erfolgreich durchführen. Es sieht also so aus, als sei bei mir, völlig unabhängig von Joomla, der OS-Benutzer www-data aus irgendeinem Grund nicht zum Download berechtigt.

Dass es heute früh so aussah, als hinge das Problem mit dem gesperrten Joomla-Nutzer zusammen, beruhte also offenbar nur auf Zufall.

Heute morgen habe ich versucht, von 3.6.2 auf 3.6.4 zu aktualisieren. Das resultierte in der Meldung "Download des Aktualisierungspakets fehlgeschlagen". Der Versuch, die Datei von meinem Rechner aus hochzuladen hat zu keiner Fehlermeldung geführt. Stattdessen bin ich auf die Startseite zurückgeworfen worden und nach ein paar Sekunden wurde wieder die Meldung eingeblendet, dass Aktualisierungen verfügbar seien.

Da ich dieses Problem noch nie hatte, habe ich überlegt, welche Änderungen ich seit der letzten Aktualisierung vorgenommen habe. Es gab eine Änderung: Ich hatte einen Super User gesperrt. Nachdem ich diese Sperre temporär aufgehoben habe, konnte ich ohne weitere Probleme die Aktualisierung durchführen. Um diesen Punkt deutlich klar zu stellen: Aktualisiert habe ich unter meinem eigenen Super User-Konto, nicht unter dem Konto des gesperrten SU.

Bei dem gesperrten SU handelt es sich um den, der unsere Joomla-Installation ursprünglich konfiguriert hat. Offenbar hat dieses Konto irgendeine besondere Bedeutung für die Installation von Updates.

Wie kann ich sicherstellen (und testen), dass zukünftige Updates auch dann funktionieren, wenn dieses Konto gesperrt ist? Insbesondere wäre es natürlich ganz übel, wenn ich dieses Konto löschte, und dann überhaupt keine Updates mehr einspielen könnte.