Hinweise zum Contao Manager

[planepix]

Anhang 20910
das gleiche auch ohne cgi

Ok.
Du könntest jetzt noch PHP 7.1 und 7.2 versuchen; vermute aber das das auch nicht hilft…

Ggf. dem Hoster den Link auf den Manager schicken, Zugangsdaten und dann gibt es hoffentlich Hilfe…

[webhebamme]

Ich bin mein eigener Hoster, weiß also nicht ob sich das lohnt weil ich nicht untervermiete
Wenn ihr das wollt aber gerne.

Meine Serverjungs die ich angeschrieben habe verweisen auf die Contaocommunity da die mir mit Sofwarespezifischen Anforderungen nicht weiterhelfen können.
Alles andere machen die aber wenn ich selbst mal nicht weiterkomme.

Nachtrag: Wir haben geschaut was ich an PHP updaten kann. Da ich allerdings erstellte Websiten von 2014 in Contao auf dem Server laufen habe ist bei PHP7.0 bei mir erstmal Schluss. Meine Kunden ziehen bei Updates nicht so mit... Wie ich das in naher Zukunft regeln möchte schau ich mir gerade an.

[BugBuster]

Falls du ein Argument brauchst

In der DSGVO wird der "Stand der Technik" grundsätzlich bei allen Maßnahmen gefordert, die der Sicherheit der Verarbeitung dienen sollen (Artikel 32 DSGVO).

Könnte man so interpretieren, man muss eine PHP Version einsetzen zu der es noch mindestens Security Updates gibt. Das wäre bei der 7.0 nur bis zum 3.12.2018.
https://secure.php.net/supported-versions.php

[webhebamme]

Hallo BugBuster,

ja ich weiß das ich so oder so was tun muss. Letzte Woche wollte ich noch alles in die Tonne treten aber bevor das mache wollte ich mir erstmal anschauen ob ich nicht evt. doch gewuppt bekommen könnte.
Egal den Manager würde ich mir trotzdem gerne mit dem Contao 4 ansehen. Je nachdem wie es mir von der Hand geht wird dann entschieden.
Habt ihr noch ne Idee dazu? Muss ich evt. noch was in der PHP Ini ändern?

[BugBuster]

Aus einem Ticket:

Wenn der PHP Binärpfad nicht akzeptiert wird, bedeutet dies, dass der PHP-Prozess, auf dem der Contao-Manager läuft, die Binärdatei nicht ausführen kann oder keine erwartete Ausgabe erhält. Stellen Sie sicher, dass die Datei ausführbar und für den Webserver-Benutzer zugänglich ist. Sie können die Ausgabe auch mit debuggen:

/opt/php-7.0/bin/php /path/to/contao-manager.phar.php test

[webhebamme]

Hmmmm,

die Dateien im angegeben Pfad besitzen die Berechtigungen 755, die darüberliegenden Ordner auch. Oder bin ich nun auf dem Holzweg... grübel, grübel, grübel

Oh Mann ich habe mich schon ganz lange nicht mehr damit auseinandergesetzt....

Konsolenausgabe: Could not open input file: /path/to/contao-manager.phar.php
Schwitz....

So Euch war das schon vorher klar... wie erzähl ich dem jetzt das er doch darf?

[tab]

Also grundsätzlich ist mir mal aufgefallen, dass dein angegebenes PHP eine cgi-Version ist, also eigentlich nicht für die Konsole gedacht.

[Fachinger]

Du hast aber schon das "/path/to/contao-manager.phar.php" mit Deinem eigenen Pfad ersetzt?

Gesendet von meinem LG-H815 mit Tapatalk

[webhebamme]

Nabend,

CGI hab so im Kopf das dies als Schnittstelle dient, weiß also nicht was du mit der konsole meinst.
Ich arbeite nicht gerne mit der Konsole aber wenn es sich nicht vermeiden lässt...

Ja er sagt mir das immer das gleiche. Ich denke ja das es vielleicht doch noch an der PHP ini liegt, aber ich habe echt kein Plan davon. Ich poste mal den Teil

open_basedir = "{OPEN_BASEDIR}"
disable_functions = exec,passthru,system,proc_get_status,proc_nice,proc_terminate 

Muss ich hier vielleicht noch was rausnehmen?

[rwaelty1944]

Hallo Zusammen.
Nachdem ich gestern Abend mit dem Manager Contao 4.4.18 'updates' durchlaufen liess sind das 'Backend' und das 'Frontend' nicht mehr ansprechbar. Im 'Backend' kann ich einloggen, aber sobald etwas ausgewählt wird springt das System zum Login. Das update lief normal durch. Hat das wiederum mit einem Symfony Fehler zu tun. Niemand kann mehr einloggen.
Was kann ich da tun? Vielen Dank für eine Antwort.

[Spooky]

Ja, ist leider wieder ein Symfony Fehler (mehr oder weniger). Siehe https://github.com/contao/core-bundle/issues/1534

Das Problem im Frontend ist aber evt. ein anderes

[rwaelty1944]

Spooky vielen Dank.
Die Frage bleibt was soll ich machen? Vielleicht bemühe ich morgen unseren Hoster damit er die ganzen 'files' auf gestern 18:00 Uhr zurückstellt.
Gruss Rolf

[rwaelty1944]

Hoffentlich kennt jemand morgen eine Antwort wie der composer.json file geändert werden kann. Nachdem dieses Problem seit 7 Tagen bekannt ist sollte dies möglich sein.
Gruss Rolf

[BugBuster]

Hilft das nicht was im Ticket steht?
https://github.com/contao/core-bundl...ment-394336748

[rwaelty1944]

Hello BugBuster

Meinst Du die Line:

For now a quick "fix" is adding to your composer.json:

"conflict": {
…
"symfony/symfony": "3.4.11|3.3.17"
},
And remove the line

"roave/security-advisories": "dev-master",
From require.
Be sure to revert these changes once Contao got an update.

Edit: If you don't have the line "roave/security-advisories": "dev-master", don't re-add it.

Weiter unten steht dann; man soll die nicht ausschalten.
Mit dieser Linie werden x Warnungen ausgespuckt.
Gruss Rolf

[rwaelty1944]

Ebenfalls lässt sich der Wartungsmodus nicht mehr aktivieren. Ein Chaos .

Gruss Rolf

[rwaelty1944]

Hallo Spooky, hallo BugBuster
Nochmals vielen Dank.

Nachdem ich die Linie:

"roave/security-advisories": "dev-master",

gelöscht habe lief der Composer durch und die Webseiten sind wieder erreichbar.
Ab sofort lasse ich meine Finger für längere Zeit von den 'updates'.
Gehe jetzt schlafen
Gruss Rolf

[Spooky]

Es ging um den conflict Eintrag. Den solltest du machen.

[rwaelty1944]

Spooky ohne den conflict Eintrag wäre der 'update' (downgrade) nicht durchgelaufen. Es ging um um das Streichen von:

"roave/security-advisories": "dev-master",

Mit dieser Linie funktioniert der 'update' das heisst das 'downloading' nicht.

Das Hauptproblem ist aber, dass Ihr diesen Fehler schon vor 8 Tagen entdeckt habt und keine Warnung im Forum publiziertet. Unzählige Web Seiten wurden dadurch lahmgelegt. Es zeigt aber auch das Contao mit der Version 4 seine Stabilität verliert. Wir haben ein Sprichwort:
Lieber der Spatz in der Hand, als die Taube auf dem Dach.

Gruss Rolf

[Spooky]

Spooky ohne den conflict Eintrag wäre der 'update' (downgrade) nicht durchgelaufen. Es ging um um das Streichen von:

Mit dieser Linie funktioniert der 'update' das heisst das 'downloading' nicht.

Das hat mit deinem ursprünglichen Fehler aber nichts zu tun.

Das Hauptproblem ist aber, dass Ihr diesen Fehler schon vor 8 Tagen entdeckt habt und keine Warnung im Forum publiziertet. Unzählige Web Seiten wurden dadurch lahmgelegt. Es zeigt aber auch das Contao mit der Version 4 seine Stabilität verliert. Wir haben ein Sprichwort:
Lieber der Spatz in der Hand, als die Taube auf dem Dach.

Mir ist dieser Fehler bisher nicht untergekommen. Eine Warnung im Forum macht vielleicht Sinn, ja.

[rwaelty1944]

Der Fehler ist erst nach dem 'update' mit dem Manager und danach mit dem Composer aufgetreten. Obwohl alles ohne Fehler durchlief.

 Titel: Nach Contao Manager Update Frontend und Backend nicht mehr ansprechbar

[Spooky]

Der Fehler tritt nur auf, wenn man eine Contao Version niedriger als 4.4.18 im Einsatz hat, soweit ich das sehe. Man sollte also als conflict zumindest "contao/core-bundle": "<4.4.18" eintragen, damit auf jeden Fall auf Contao 4.4.18 aktualisiert wird.

[Spooky]

Der Fehler ist erst nach dem 'update' mit dem Manager und danach mit dem Composer aufgetreten. Obwohl alles ohne Fehler durchlief.

 Titel: Nach Contao Manager Update Frontend und Backend nicht mehr ansprechbar

Ja, aber du sprichst hier von verschiedenen Fehlern .

[rwaelty1944]

Bei uns läuft Contao 4.4.18
Frontend: Ein 'login' in den geschützten 'frontend' Bereich war nicht mehr möglich. System sprang sofort wieder auf den ungeschützten Bereich. Dort funktionierte alles im 'frontend' (aeropens.ch).

Backend: Login im 'backend' war möglich, aber nach einer Auswahl sprang das System sofort zurück auf die 'login' Seite. Beim nächsten 'login' war die vorherige Auswahl selektiert. Direktwahl (zB. aktivieren des Wartungsmodus) funktionierte nicht mehr.

[tab]

Was mich in dem Zusammenhang Symfony Unverträglichkeiten mal interessieren würde: Ist Contao momentan für Symfony auch so ein exotischer Anwendungsfall wie das reine Update der json- und lock-Dateien ohne Download der Bundles für Composer? Und falls ja, liegt das daran, dass Contao eben noch nicht in allen Bereichen komplett auf Symfony umgestellt ist? Wird sich das also irgendwann mal legen? Damit meine ich, dass mittlerweile gefühlt jedes zweite Symfony-Update irgendwas in Contao schrottet und verhindert werden muss. Ansonsten würde ich vorschlagen, die Symfony-Version bei jeder Contao-Version defaultmäßig festzupinnen. So wie es ja im Prinzip früher(tm) mit Third-Party Modulen auch - notgedrungen - gemacht worden ist.

[Spooky]

Was mich in dem Zusammenhang Symfony Unverträglichkeiten mal interessieren würde: Ist Contao momentan für Symfony auch so ein exotischer Anwendungsfall wie das reine Update der json- und lock-Dateien ohne Download der Bundles für Composer? Und falls ja, liegt das daran, dass Contao eben noch nicht in allen Bereichen komplett auf Symfony umgestellt ist? Wird sich das also irgendwann mal legen? Damit meine ich, dass mittlerweile gefühlt jedes zweite Symfony-Update irgendwas in Contao schrottet und verhindert werden muss. Ansonsten würde ich vorschlagen, die Symfony-Version bei jeder Contao-Version defaultmäßig festzupinnen. So wie es ja im Prinzip früher(tm) mit Third-Party Modulen auch - notgedrungen - gemacht worden ist.

Das Problem mit symfony/finder war kein Contao spezifisches Problem.

Die diversen Probleme mit symfony/security betreffen nur Contao 4.0.x bis 4.4.x, da die Implementation der alten Contao Benutzerauthentifizierung innerhalb von Symfony, sagen wir mal, schwierig war. Diverse Änderungen innerhalb von symfony/security führen in letzter Zeit manchmal zu Probleme, weil Contao diese Komponente teilweise unerwartet benutzt und teilweise werden durch diese Benutzung Fehler bzw. Problematiken in der Komponente aufgezeigt.

Ab Contao 4.5 besteht dieses Problem nicht mehr, weil das System komplett neu geschrieben wurde und sich auf das Symfony Framework stützt.

[Franko]

Das Problem mit symfony/finder war kein Contao spezifisches Problem.

Die diversen Probleme mit symfony/security betreffen nur Contao 4.0.x bis 4.4.x, da die Implementation der alten Contao Benutzerauthentifizierung innerhalb von Symfony, sagen wir mal, schwierig war. Diverse Änderungen innerhalb von symfony/security führen in letzter Zeit manchmal zu Probleme, weil Contao diese Komponente teilweise unerwartet benutzt und teilweise werden durch diese Benutzung Fehler bzw. Problematiken in der Komponente aufgezeigt.

Ab Contao 4.5 besteht dieses Problem nicht mehr, weil das System komplett neu geschrieben wurde und sich auf das Symfony Framework stützt.

Nicht alle verfolgen die diversen Github Threads oder spezifische Lösungen die hier im Forum gegeben werden (Beispiele 1 o. 2 ).
Insofern wäre evtl./zumindest eine prominentere, leicht zu findene Sammelstelle für derartige Infos hier im Forum hilfreich/wünschenswert.

[tab]

Die diversen Probleme mit symfony/security betreffen nur Contao 4.0.x bis 4.4.x, da die Implementation der alten Contao Benutzerauthentifizierung innerhalb von Symfony, sagen wir mal, schwierig war. Diverse Änderungen innerhalb von symfony/security führen in letzter Zeit manchmal zu Probleme, weil Contao diese Komponente teilweise unerwartet benutzt und teilweise werden durch diese Benutzung Fehler bzw. Problematiken in der Komponente aufgezeigt.

Ab Contao 4.5 besteht dieses Problem nicht mehr, weil das System komplett neu geschrieben wurde und sich auf das Symfony Framework stützt.

Also teilweise doch wie vermutet. Da muss ich mir wohl nochmal Gedanken über meine Update-Strategie machen. Aber so wie der Release-Plan aussieht, ist 4.4.x leider relativ alternativlos. Die Ochsentour 4.5->4.6->4.7->4.8->4.9 mag ich mir bestenfalls mit einigen wenigen Installationen antun. Und bei 3.5 zu bleiben bis zum bitteren Ende und zu hoffen, dass danach in 3.5 bis zum Release 4.9 nichts sicherheitskritisches gefunden wird, ist bestenfalls ziemlich riskant. Da wäre ich dann bei einer Sicherheitslücke in 3.5 gezwungen, die ganzen Installationen sehr kurzfristig doch noch auf auf 4.4 oder eventuell 4.8 zu heben, je nachdem wann es passiert. Das wäre dann wohl nicht realistisch leistbar.

[Franko]

Also teilweise doch wie vermutet. Da muss ich mir wohl nochmal Gedanken über meine Update-Strategie machen.

Ich habe festgestellt das mit Aufkommen der 4er Releases seltsamerweise die meisten Kunden mit 2.9 Installationen sich mittlerweile zumindest für ein 3.5er Update bereit erklären ( die sich zuvor aus Kosten Gründen bisher geweigert hatten ) nicht zuletzt auch aufgrund der aktuellen PHP Versionen. In diesem Zusammenhang versuche ich - sofern im Provider Umfeld möglich - dann auch gleich ein 4.4er LTS durchzusetzen. Also zunächst von 2.9.x ->3.5.x und dann auf die LTS. Zumeist ist dies ohne Probleme möglich da ich größtenteils auf Erweiterungen verzichtet o. zumindest nur die gängigen/gut gepflegten Erweiterungen herangezogen hatte. In der Hoffnung das später ein Update von 4.4.x auf 4.5.x ähnlich unproblematisch sein wird.

Und bezüglich

Nicht alle verfolgen die diversen Github Threads oder spezifische Lösungen die hier im Forum gegeben werden

Bitte nicht als Kritik verstehen - wenn ich beispielsweise Toflars Beitrag aus https://github.com/contao/core-bundle/issues/1492 lese:

After 5h of debugging together with @aschempp, I think we found the source of the problem in Symfony. Here we go: symfony/symfony#27309

welcher hierzu führt:
https://github.com/symfony/symfony/pull/27309 ist die Leistung schon beeindruckend (auch wenn ich kein Wort verstehe :-) )

[webhebamme]

Aus einem Ticket:

Wenn der PHP Binärpfad nicht akzeptiert wird, bedeutet dies, dass der PHP-Prozess, auf dem der Contao-Manager läuft, die Binärdatei nicht ausführen kann oder keine erwartete Ausgabe erhält. Stellen Sie sicher, dass die Datei ausführbar und für den Webserver-Benutzer zugänglich ist. Sie können die Ausgabe auch mit debuggen:
Code:

/opt/php-7.0/bin/php /path/to/contao-manager.phar.php test

Nachdem ich es nun endlich geschafft habe hier die Ausgabe der Console:

{"version":"7.0.7","version_id":70007,"sapi":"cli"}root@1a-8767:~#

Könnt ihr mir nun bitte weiterhelfen?

[xchs]

Diese Ausgabe kannst Du jetzt hier im Ticket posten: https://github.com/contao/contao-manager/issues/266

[webhebamme]

Hallo xchs,

hatte ich gestern abend noch gemacht. Heute ist das Ticket geschlossen worden.

Bitte wiedereröffnen falls es sich um einen Bug handelt. Support ansonsten wie von @xchs bereits erwähnt im Forum.

Ich hoffe ich durfte dies hier zitieren. Ich versuche mich an alle Regeln zu halten aber langsam weiß ich nicht wo ihr was haben möchtet/braucht. Mir hat das bisher noch nicht weitergeholfen.

Ich bitte um weitere Anweisungen. Dankeschön

[xchs]

Klar darfst Du das hier ebenfalls zitieren! Kein Problem.

Hast Du schon die aktuelle Version 1.0.0 des Contao Managers probiert?

[webhebamme]

Meine installierte Version ist Contao Manager 1.0.0-beta19

[xchs]

Heute ist die stabile Version 1.0.0 veröffentlicht worden. Du solltest also ein Update auf diese Version durchführen.

[webhebamme]

Ich habe die neue Version installiert habe aber das gleiche Problem.

[xchs]

Es geht um die Domain webhebamme.de oder? Derzeit scheint der DocumentRoot nicht korrekt gesetzt zu sein und auch das Directory Listing sollte deaktiviert werden.

[webhebamme]

Habe es unter http://contao4.4.webhebamme.de.

Werde das Directory Listing ausschalten.
contao_manager_1.0.0.PNG

[zonky]

Hi,

teste meine erste Installtion (4.5) mit dem Cloud-Resolver (V 1.3.1) ... wie lange dauern die Auflösungen? bei mir läuft die Sache schon seit über 12 Minuten...?

Resolving dependencies using Composer Cloud
Job ID 5b1a3782a3b453.93530347 is running for 1435 seconds

... hmmm Button "Abbrechen" ist disabled..?

... uff: Neuladen des Managers bringt mich immer wieder auf die Cloud-Resolver-Anzeige - wie kann ich die Sache abschießen ?

[tab]

Das läuft vermutlich gar nicht mehr wirklich. Ich habe bei den selben Symptomen, nachdem ich ohne Erfolg sogar den Apache gekillt hatte , einfach im Verzeichnis Contao-Manager die ganzen Task/TensideTask json-Dateien gelöscht, bs auf die background-process.get.json und background-process.set.json, dabei muss ich wohl den/die Übeltäter erwischt haben und der Contao-Manager verhielt sich dann wieder normal. Natürlich kann man auch das ganze contao-manager Verzeichnis löschen, dann muss man halt wieder den Zugang neu einrichten und die Einstellungen nötigenfalls neu machen.