Verschiebung der Einstellung alter PHP-Versionen & Info zur neuen Webserverplattform

[Schakal]

Du kannst den HSTS-Header mit nur einer Zeile Code in PHP etc. setzen oder auch mit einer Zeile Code in der .htaccess. Welchen Vorteil bringt da eine Funktion im Konfigmenü? Zumal aktivieren/deaktivieren nicht reicht. Der definierte Zeitraum ist entscheidend.

Die verschiedenen Möglichkeiten sind mir bekannt. Bei uns gibt es Rollenverteilung. Sicherheitsrelevante Einstellungen dürfen weder durch Webmaster noch Werbeagenturen geändert werden. Was über das Kundenmenü durch aus als Apache Konfiguration umgesetzt wird.

Apache + NGINX (teils als Proxy) ist bei modernen Hostingumgebungen doch schon fast Standard (u.a. auch in Plesk). NGINX ist bei statischen Dateien 2-5 mal so effizient wie Apache.

Wir haben eine Webapplikation im Einsatz, welche z.B. auf Frontend/Reverse Proxy empfindlich reagiert. Ob das nun (un)sinnig ist, steht auf einem anderen Blatt. Fakt ist, die Zwangsmigration wird irgendwann kommen. Ich möchte gerne so früh wie möglich ableiten können, wo die Reise für uns hingeht. Da spielen auch die Dinge wie Typo3 und MariaDB ein wichtiger Faktor.

[Schakal]

MariaDB ist schon jetzt sehr verbreitet und es gibt im Regelfall keine Probleme. Es wird die identische InnoDB-Engine benutzt, auf die in der Regel auch Applikationen zurückgreifen. Der SQL-Dialekt entspricht dem „Standard-SQL“, und zwischen MySQL und MariaDB gibt es keine essenziellen Unterschiede. Viele Distributionen und Firmen setzen MariaDB als Standard ein. Industriestandard ist SQL, ich wüsste nicht, dass MySQL selbst jetzt ein solcher wäre. Wir halten den Einsatz von MariaDB für zukunftsträchtiger.

Wenn schon Docker Container für andere Szenarien eingesetzt werden, warum nicht auch für eine weitere MariaDB Instanz?!

[rp_df]

Die verschiedenen Möglichkeiten sind mir bekannt. Bei uns gibt es Rollenverteilung. Sicherheitsrelevante Einstellungen dürfen weder durch Webmaster noch Werbeagenturen geändert werden. Was über das Kundenmenü durch aus als Apache Konfiguration umgesetzt wird.

Ihr habt dann also heute "Webmaster", die weder FTP-, noch Shell-, noch Konfigmenü-Zugang haben, damit sie keine "sicherheitsrelevanten Einstellungen" tätigen können. Was genau macht dann so ein "Webmaster" überhaupt auf dem Server?

[masterframe]

Was genau macht dann so ein "Webmaster" überhaupt auf dem Server?

Content-Redakteur 😉

[Gast]

Auch dazu bitte gerne Informationen, wenn Sie genaueres finden. Ich habe ja bereits einiges dazu gesagt und noch ist das nicht absolut fixiert von der Version her.

Mit freundlichen Grüßen

Nils Dornblut

Nachgefragt bei unserer Shopware-Agentur:
"Die Version von Mysql 5.7 entspricht der MariaDB 10.3, laut unserem Hoster (ausge-XXX...ist ein etablierter Shopware-Hoster). Mit dem Update auf 10.4 würde ich eventuell noch warten, da Shopware aktuell stabil mit 10.3 läuft."

Bei CentOS 8 soll doch MariaDB 10.3 dabei sein: https://mariadb.com/resources/blog/h...rhel8-centos8/.
Also warum Stress machen mit 10.4?

[Engholm]

Hab grad nochmals nachgeschaut, auch die Brandneue TYPO3 Version 10 funktioniert nicht mit MariaDB 10.4

https://get.typo3.org/version/10

Sollte es nicht im Interesse von TYPO3 sein, eine entsprechende Kompatibilität herzustellen, gerade wenn MariaDB immer weiter verbreitet und ist und gerade weil es OpenSource ist?

[wecotec]

Sollte es nicht im Interesse von TYPO3 sein, eine entsprechende Kompatibilität herzustellen, gerade wenn MariaDB immer weiter verbreitet und ist und gerade weil es OpenSource ist?

Natürlich und ich bin mir sicher, dass man dies in kommenden Releases auch erledigt. Nur aktuell ist es nicht der Fall, da kann man drüber diskutieren wie man will. Davon mal abgesehen arbeiten viele auch noch mit älteren Typo3s (wir z.b. mit Version 9/8/7) wo es bekannte Probleme mit neueren MariaDB-Versionen gibt.

Und ich bin mir sicher, dass es bei den DF-Kunden noch massiv viele Installationen gibt, die nicht mit neueren Versionen von MariaDB zusammenarbeiten weil die Kunden nicht updaten/testen konnten (dank des Fehlens von mySQL 5.7).

Wenn ich es richtig verstehe ist im neuen Image recht viel in Containern verpackt, warum kann man da nicht auch mySQL mit anbieten?

[phobos]

Natürlich und ich bin mir sicher, dass man dies in kommenden Releases auch erledigt. Nur aktuell ist es nicht der Fall, da kann man drüber diskutieren wie man will. Davon mal abgesehen arbeiten viele auch noch mit älteren Typo3s (wir z.b. mit Version 9/8/7) wo es bekannte Probleme mit neueren MariaDB-Versionen gibt.

Und ich bin mir sicher, dass es bei den DF-Kunden noch massiv viele Installationen gibt, die nicht mit neueren Versionen von MariaDB zusammenarbeiten weil die Kunden nicht updaten/testen konnten (dank des Fehlens von mySQL 5.7).

Wenn ich es richtig verstehe ist im neuen Image recht viel in Containern verpackt, warum kann man da nicht auch mySQL mit anbieten?

Fakt ist halt nunmal auch, das TYPO3 in Version 10 nunmal nicht mit MariaDB 10.4 funktioniert, und das in nächster Zeit dahingehend auch nix kommt.
In anderthalbjahren vielleicht mit Version 11... wenn überhaupt

[Gast]

Fakt ist halt nunmal auch, das TYPO3 in Version 10 nunmal nicht mit MariaDB 10.4 funktioniert, und das in nächster Zeit dahingehend auch nix kommt.
In anderthalbjahren vielleicht mit Version 11... wenn überhaupt

Dann ist es vemrutlich auch Fakt, dass es für diese Projekte mit einer (veralteten Software?) eine neue Heimat braucht. Zumindest, sofern sie eben auch nicht PHP 7.3 kompatibel ist oder nur in den Grenzen, die dF nach aktuellem Stand weder in den alten noch in den neuen Tarifen anbieten wird.

[phobos]

Dann ist es vemrutlich auch Fakt, dass es für diese Projekte mit einer (veralteten Software?) eine neue Heimat braucht. Zumindest, sofern sie eben auch nicht PHP 7.3 kompatibel ist oder nur in den Grenzen, die dF nach aktuellem Stand weder in den alten noch in den neuen Tarifen anbieten wird.

Ähm naja, veraltet ist da nix, TYPO3 in Version 10 ist grad jetzt in diesen Tagen produktiv raus, also Topaktuell.
TYPPO3 in Version 9 ist auch grad ein gutes halbes Jahr raus.... Also auch Topaktuell.

Ich kann doch auch nix dafür...

[horwie]

TYPPO3 in Version 9 ist auch grad ein gutes halbes Jahr raus.... Also auch Topaktuell.

TYPO3 9.5 wurde 10/2018 veröffentlicht, Du hast ein Jahr unterschlagen

[horwie]

Sollte es nicht im Interesse von TYPO3 sein, eine entsprechende Kompatibilität herzustellen, gerade wenn MariaDB immer weiter verbreitet und ist und gerade weil es OpenSource ist?

Ja, das wird durch den Einsatz von Doctrine DBAL erreicht und wurde in TYPO3 8.1 eingeführt: https://docs.typo3.org/c/typo3/cms-c...nnections.html
Auf https://www.doctrine-project.org/projects/dbal.html findet Ihr die Doku und lt. https://github.com/doctrine/dbal/issues/3278 wird MariaDB 10.3 unterstützt.
MariaDB 10.4 scheint noch zu neu zu sein - da viele andere Projekte ebenfalls Doctrine DBAL verwenden nicht nur ein Problem für TYPO3.

[Gast]

MariaDB 10.4 scheint noch zu neu zu sein - da viele andere Projekte ebenfalls Doctrine DBAL verwenden nicht nur ein Problem für TYPO3.

Zitat aus: https://mariadb.com/kb/en/changes-im...n-mariadb-104/

MariaDB 10.4 is the current major stable version The first stable release was in June 2019, and it will be supported until June 2024.

So neu ist es dann auch wieder nicht. Juni 2019 erschienen. Da sollte doch so ein DBAL wie Doctrine bereits eine Idee haben. Genau dafür, dass die CMS Entwickler das nicht immer alles selbst aktuell halten müssen und schneller auf neue Systeme reagiert werden kann, ist so was doch da.

Ich verstehe ja, dass es nun zu Problemen kommt, begrüße aber sehr, dass dF im neuen Setup aktuelle Systeme einsetzen möchte. Es gibt ja noch keinerlei Terminaussagen. Vielleicht ist ja bis dahin Doctrine MariaDB 10.4 tauglich? Oder es gibt auf einem ManagedServer einen Workaround oder im "alten" Server kann doch noch aufgrund der Typo3 Problematik eine Zeit lang (auf eigene Gefahr?) das Setup so gefahren werden, dass Typo3 dort noch so lange laufen kann, bis Doctrine für Maria DB 10.4 fertig ist?

Und generell werden wir uns wohl leider darauf einstellen müssen, dass nun mindestens eine Zeit lang stetig Updates nötig sind, weil unsere Kernelemente (z.B. PHP, oder die DB) schneller aktualisiert und der Support älterer Versionen früher beendet wird.

[wecotec]

Und generell werden wir uns wohl leider darauf einstellen müssen, dass nun mindestens eine Zeit lang stetig Updates nötig sind, weil unsere Kernelemente (z.B. PHP, oder die DB) schneller aktualisiert und der Support älterer Versionen früher beendet wird.

Richtig, daran gibt es nichts zu beanstanden. Dann muss sich aber auch jeder Reseller die Frage stellen ob DF noch der richtiger Partner ist. Es ist nicht möglich alle Kundenprojekte in einem angemessenen Zeitraum up-to-date zu halten. Die Gründe sind vielfältig, es wird aber definitiv nicht möglich sein, egal mit welchem Aufwand, mehrere dutzend/hundert Projekte ständig zu updaten. Das machen nicht alle Kunden mit. Andere Hoster haben nicht ohne Grund (teilweise mit Aufpreis) noch PHP5 im Programm. DF hat die Abschaltung von bestimmten PHP-Versionen bestimmt auch nicht aus Höflichkeit verschoben.

[Gast]

Richtig, daran gibt es nichts zu beanstanden. Dann muss sich aber auch jeder Reseller die Frage stellen ob DF noch der richtiger Partner ist.

Klar, doch das ist eine normale wirtschaftliche Entscheidung. Die Liefeanten müssen zum eigenen Produkt / Angebot passen. Meiner Meinung nach ist das Reselling an sich ein Auslaufmodell und das halte ich für eine gute Entwicklung.

Es ist nicht möglich alle Kundenprojekte in einem angemessenen Zeitraum up-to-date zu halten. Die Gründe sind vielfältig, es wird aber definitiv nicht möglich sein, egal mit welchem Aufwand, mehrere dutzend/hundert Projekte ständig zu updaten.

Warum eigentlich nicht? Letzlich ist das doch eine Frage des eigenen Geschäftsmodells. Wir z.B. machen Standard Websites mit WordPress (wegen des Preis-Leistungs Verhältnis, das für diese Projekte passt) und nur mit Update/Wartungsvertrag. Dabei haben wir ein klares Setup., dass alle Sites nutzen müssen. Updates laufen pro Monat und brauchen dank entsprechender Tools trotz aktuell um die hundert Sites nur wenige Stunden für alle zusammen. Bei größeren Sites / Individuellen Web Applikationen ist möglichst ein System im Einsatz, das relativ robust gegen PHP / DB Aktualisierungen ist. Das ist je nach Projekt unterschiedlich.
Und: wir würden nie mehr als x Projekte gleichzeitig annehmen / betreuen, weil wir dann keine Qualität mehr sicherstellen können. Vergrößern wollen wir uns nicht.
Also: wenn das Geschäftsmodell sagt: wir betreuen hunderte von Sites, dann ist es letzlich die Verantwortung des Dienstleisters, die Ressourcen und Abläufe zu organiseren, solche Updates regelmäßig wuppen zu können. Und das nicht erst seit der PHP 5 Abschaltung. Alternativ dann zumindest (wie viele andere Reseller im anderen Forum gezeigt haben) ein robusteres Setup finden und nicht mehr nur auf einen Lieferanten setzen. Redundanz hört eben nicht beim Servernetzteil auf.

Das machen nicht alle Kunden mit.

Das wiederum ist ein Problem des Kunden. Wenn diese nicht bereit oder in der Lage sind, Ihre Betriebsmittel (und mindestens dazu zählt die Website, Applikation oder was auch immer) instand zu halten, dann werden sie schlicht irgendwann vor einem Crash dieses Betriebsmittels stehen. So ist das nun mal. Klingt hart, aber die Kunden, die gar nicht aktualisieren wollte, haben wir nicht mehr bzw. lassen sie nach mehreren Jahren der ignorierten Warnungen dann eben in die Situation laufen, dass die Präsenz nicht mehr löuft und wir auch nichts mehr reparieren können. Die Verantworg dafür liegt beim Kunden. Wer die Fahrzeugflotte nicht warten und ausbessern lässt bzw. stetig modernisiert darf sich nicht wundern, wenn irgendwann Engpässe auftreten oder Fahrzeuge bei der HU durchfallen. Eine Zeit lang kann das gehen, aber es ist eben Roulette.
Als Dienstleister sehen wir uns dabei in der Pflicht möglichst wartungsarme Systeme einzusetzen bzw. zu erstellen und durch stetiges Refactoring letzlich auch die Gesamtkosten für den Kunden so gering wie möglich und den Nutzen so hoch wie möglich zu halten. (Natürlich wollen und können wir von unserer Arbeit auch noch leben.)

Andere Hoster haben nicht ohne Grund (teilweise mit Aufpreis) noch PHP5 im Programm.

Das halte ich für einen falschen Weg. Es ist richtig, die alten Systeme abzuschalten und selbst wenn bis 2025 gewartet wird, wird es noch irgendjemand geben, für den das gerade gar nicht geht. Es war seit der Abkündigung seitens der PHP Entwickler (und die gilt es als Dienstleister nun einmal auch zu lesen) wirklich genug Zeit, umzustellen. (Nicht falsch verstehen, auch ich habe den vorherigen Termin für die PHP 5 Abschaltung gerade so geschafft, aber dabei einfach gemerkt, dass ich über Jahre da Versäumnisse hatte.)

DF hat die Abschaltung von bestimmten PHP-Versionen bestimmt auch nicht aus Höflichkeit verschoben.

Mir liegen nur die Informationen von Herrn Dornblut hier aus dem Forum vor. Demnach wurde die neue Plattform einfach nicht rechtzeitig fertig, obwohl das so geplant war. Das passiert und ist zumindest für mich plausibel. Alles andere ist für mich im Moment nur Spekulation und bringt mich nicht weiter.