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

[wecotec]

Meiner Meinung nach ist das Reselling an sich ein Auslaufmodell und das halte ich für eine gute Entwicklung.

Wie sähe denn die Alternative aus?

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.

Es gibt auch Projekte die über den Standard hinaus gehen und etwas anspruchsvoller sind, da ist eine Wartung entsprechend aufwendiger und zum Teil, wegen den eingesetzten Komponenten, wird es mit den Updates etwas kniffliger. Wenn man nur "Standard-Wordpress" anbietet ist es in der Tat einfach alles aktuell zu halten.

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.

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.)

Auf dem Papier hast Du vollkommen Recht. Wir besprechen das, wenn Deine Firma 20 Jahre auf dem Markt ist

Alles andere ist für mich im Moment nur Spekulation und bringt mich nicht weiter.

Korrekt, meine Aussage ist rein spekulativ. Zugrunde liegen hier die Zahlen die bei uns vorliegen (Prozentsatz Kunden die nicht updaten können/wolllen) und die Einschätzung dass einige DF-Kunden von diesem Thema nichts mit bekommen haben (wir betreuen hier einige, keine Ahnung was die mit dem Newsletter machen ).
Im Endeffekt ist mir dieses Thema aber auch egal, da wir unsere Kunden vorbereitet haben und DF meinetwegen den Hebel umlegen darf.

[Gast]

Wie sähe denn die Alternative aus?

Ich suche jeweils den passenden Hoster (oder Kombination) für den Kunden bzw. das Projekt. Diese Recherche- und Beratungsleistung wird transparent vergütet. Dazu dann die Wartungsleistung. Damit werden diese Posten nicht mehr in oft zu hohen oder für die nötigen Wartungen zu niedrigen Hosting Gebühren des Resellers versteckt. Ein echtes Reselling ( also das 1:1 Weiterverkaufen von den Produkten des Hosters) sehe ich da übrigens noch mal anders.

Es gibt auch Projekte die über den Standard hinaus gehen und etwas anspruchsvoller sind, da ist eine Wartung entsprechend aufwendiger und zum Teil, wegen den eingesetzten Komponenten, wird es mit den Updates etwas kniffliger. Wenn man nur "Standard-Wordpress" anbietet ist es in der Tat einfach alles aktuell zu halten.

Sag ich ja, Standard WP ist eine Sparte. Wir betreuen auch selbst entwickelte Schnittstellen, die täglich von tausenden Nutzer*innen per Smartphone etc. abgerufen werden oder vue.js basierte Frontends für komplexe (Strom-)tarifrechner. Aber von solchen Projekten eben nur eine Handvoll gleichzeitig.

Auf dem Papier hast Du vollkommen Recht. Wir besprechen das, wenn Deine Firma 20 Jahre auf dem Markt ist

Du wieder mit Deinen Annahmen... Mein Gewerbeschein hat den September 1997 als Datum, wir dürfen also bereits reden.;-) In den vergangenen Jahren habe ich mich mehrfach bewusst dagegen entschieden, zu wachsen und x Mitarbeitende einzustellen. Wäre alles möglich gewesen bis hin zu einem StartUp, bei dem bereits mehrere Millionen Euro Zusage eines Investors da waren. Aber Geld ist nicht alles und im Gesamtpaket ergaben diese Schritte einfach keinen Sinn. Würde ich heute wieder so machen. (hat auch viele Nachteile, das ist nicht alles rosig, aber dennoch für mich persönlich richtig.) Da muss jede*r selbst entscheiden, welche Richtungen er/sie einschlagen will und dann auch die Verantwortung für diese Entscheidungen annehmen und die nötigen Maßnahmen dafür ergreifen.

Korrekt, meine Aussage ist rein spekulativ. Zugrunde liegen hier die Zahlen die bei uns vorliegen (Prozentsatz Kunden die nicht updaten können/wolllen) und die Einschätzung dass einige DF-Kunden von diesem Thema nichts mit bekommen haben (wir betreuen hier einige, keine Ahnung was die mit dem Newsletter machen ).

Wir werden vermutlich nie erfahren, ob es neben den kommunizierten Gründen noch andere gibt. Die Gehmeimnisse des Lebens... oder eben die mangelnde Transparenz der Wirtschaft im allgemeinen.

Im Endeffekt ist mir dieses Thema aber auch egal, da wir unsere Kunden vorbereitet haben und DF meinetwegen den Hebel umlegen darf.

So sieht es bei mir auch aus. Da wir kein Typo3 einsetzen (Kunden, die das nach Analyse brauchen, empfehlen wir zu anderen Anbietern) habe ich auch kein Problem mit diesem MySQL / PHP 7 Problem, wenn dF den Hebel umlegt.

[phobos]

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

Ja mei sorry,

was ich sagen wollte, TYPO3 9 und 10 sind aktuelle Versionen, von daher bist mit MariaDB 10.4 im Eimer

[rp_df]

Meiner Meinung nach ist das Reselling an sich ein Auslaufmodell und das halte ich für eine gute Entwicklung.

Kommt meines Erachtens auf die Umstände an: Reselling im Sinne von "Kleine Agentur verkauft reine Hostingpakete von großem Anbieter" sehe ich auch als Auslaufmodell. Das halte ich ebenfalls für eine gute Entwicklung. Das technische Knowhow vieler Reseller ist im Vergleich zu den großen Anbietern doch eher dünn. Das Hostinggeschäft ist massiv von Skaleneffekten abhängig und zu einem kleinen Reseller zu gehen, bringt den Kunden in den seltensten Fällen Vorteile. Und auch mit 1000 Kunden im Hostinggeschäft ist man klein.

Aber im Rahmen von Komplettlösungen werden Agenturen/entwickler weiter Hosting gekoppelt mit Websites/Webapplikationen verkaufen können. Viele Unternehmen mit Websites/Webapplikationen wollen eine Lösung aus einer Hand, damit es bei Problemen einen Ansprechpartner und im Fehlerfall einen Schuldigen gibt. Sonst sagt bei Problemen ggf. der Hoster, dass es an der Applikation liegt. Die Agentur hinter der Applikation sagt, dass es am Hoster liegt. Und der Kunde sitzt mit seinem Problem dumm zwischen den Stühlen. Außerdem gibt es zumindest für Applikationen eine Tendenz Richtung SaaS, was ohnehin Komplettlösungen inkl. Hosting bedingt.

Wir besprechen das, wenn Deine Firma 20 Jahre auf dem Markt ist

Das ist kein Argument. Die Zeiten und Rahmenbedingungen haben sich nun mal geändert. Nur einer von vielen Aspektes dazu: BDSG und DSGVO schreiben vor, dass man einen Datenschutz auf Stand der Technik umsetzt "einschließlich der Fähigkeit, die Verfügbarkeit und den Zugang bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen". Das gilt für fast alle Websites/Webapplikationen, denn fast immer werden persönliche Daten verarbeitet (und sei es durch Kontaktformular oder weil es irgendein Login gibt). Wie stellt man ein System auf Basis PHP5 rasch wieder her, wenn darin eine Sicherheitslücke gefunden werden sollte, es aber eben keinen Patch mehr geben wird? Wobei PHP5 hier lediglich ein Beispiel ist. Das gilt für sämtlichen Applikationen und sämtlichen Code. Klar: Die Datenschutzbehörden sind noch mit anderen Problemen beschäftigt. Aber ich möchte an Dinge wie Perfect Forward Secrecy erinnern, in die sich Datenschutzbehörden in der Vergangenheit verbissen haben. Da wurden Tools gebaut, um automatisiert zu detektieren, ob PFS fehlt. Viele sind ja nicht mal in der Lage "X-Powered-By-Header" und andere Indikatoren zu deaktivieren und stellen somit für Angreifer, Behörden und Abmahner regelrecht ins Schaufenster, dass sie völlig veraltetes Zeug benutzen. Mehrere Oberlandesgerichte haben zuletzt auch bestätigt, das DSGVO-Verstöße Wettbewerbsverletzungen sind und entsprechend verfolgt werden können (Abmahnungen etc.).

[Gast]

Kommt meines Erachtens auf die Umstände an: Reselling im Sinne von "Kleine Agentur verkauft reine Hostingpakete von großem Anbieter" sehe ich auch als Auslaufmodell. Das halte ich ebenfalls für eine gute Entwicklung. Das technische Knowhow vieler Reseller ist im Vergleich zu den großen Anbietern doch eher dünn. Das Hostinggeschäft ist massiv von Skaleneffekten abhängig und zu einem kleinen Reseller zu gehen, bringt den Kunden in den seltensten Fällen Vorteile. Und auch mit 1000 Kunden im Hostinggeschäft ist man klein.

Ja, volle Zustimmung!

Aber im Rahmen von Komplettlösungen werden Agenturen/entwickler weiter Hosting gekoppelt mit Websites/Webapplikationen verkaufen können. [..]. Außerdem gibt es zumindest für Applikationen eine Tendenz Richtung SaaS, was ohnehin Komplettlösungen inkl. Hosting bedingt.

Richtig, für das Angebot von Plattformen, SaaS oder "Alles aus einer Hand" Produkte muss eine Agentur oder besser der Produkthersteller / Anbieter (ob die "klassische" Agentur noch lange eine Daseinsberechtigung hat, ist auch mal zu diskutieren) auch noch Hosting können. Doch genau in dem Fall ist es m.E. absolut nötig, selbst eine entsprechende Infrastruktur zu betreiben und KnowHow aufzubauen oder aber ein Setup zu haben, bei dem mit wenig Aufwand umgezogen werden kann, wenn etwas klemmt. Und natürlich den Markt an der Stelle genau beobachten. Auch Apple nutzt die Amazon Cloud, ich behaupte aber (ohne es zu wissen, reine Vermutung!), dass es bei Apple intern einige Erfahrung mit dem Aufbau und auch dem Managen von Cloudspeicher gibt. Und was die "Großen" da machen, müssen die Kleinen auch machen. Da muss eigenes KnowHow aufgebaut und stetig weiterentwicklet werden. Letzlich ist es dann auch zum Wohle des Kunden und diese Kosten können und müssen im Produktpreis abgebildet sein. Sich da auf einen Anbieter wie dF zu verlassen bedeutet m.E. einfach, das nervige und die Verantwortung möglichst günstig auszulagern, die "Gewinne" aber haben zu wollen. Es ist dann eben nicht mehr "aus einer Hand".
Wie wecotec etwas vorher schon schrieb: da ist dF dann vielleicht nicht mehr der richtige Partner. Insbesondere, da es bisher nur sehr spät Ankündigungen von Veränderungen gab. Als Plattformbetreiber der die Serverstruktur nicht selbst vorhält, brauche ich da andere Vorlaufzeiten und halbwegs verbindliche Roadmaps, um reagieren zu können. Vollkommen normal.

Viele Unternehmen mit Websites/Webapplikationen wollen eine Lösung aus einer Hand, damit es bei Problemen einen Ansprechpartner und im Fehlerfall einen Schuldigen gibt. Sonst sagt bei Problemen ggf. der Hoster, dass es an der Applikation liegt. Die Agentur hinter der Applikation sagt, dass es am Hoster liegt. Und der Kunde sitzt mit seinem Problem dumm zwischen den Stühlen. Außerdem gibt es zumindest für Applikationen eine Tendenz Richtung SaaS, was ohnehin Komplettlösungen inkl. Hosting bedingt.

Das Thema der Schuldverschiebung stellt sich m.E. nur bei der falschen Wahl der entsprechenden Akteuere. Und ja, das erlebe ich bei dF in letzter Zeit leider auch immer wieder. Lösungsorientierte Anrufe "da ist ein Problem, ich denke, es liegt auf Serverebenen weil x zu beobachten ist" werden vom Standardsupport erst mal mit "kann nicht sein, wir stellen nichts fest" beantwortet (mehrfach bei dem nervigen Problem nicht erreichbarer neuer Datenbankten erlebt). Beim PVI Support erlebe ich das zum Glück anders, wenn ich da sage: folgendes habe ich schon gestestet, dann suchen wir gemeinsan und bisher immer erfolgreich nach einer Lösung für das Problem des Kunden.

Eine spannende Idee finde ich bei dem Thema übrigens das Hosting als Genossenschaft, sich also als Plattformanbieter zusammenzuschließen und so KnowHow und Ressourcen zu bündeln. Vielleicht sogar in Beteiligung von einem Hoster wie dF. Dann könnten ja z.B. auch JiffyBoxen o.ä. genutzt werden. Da gibt es aber bisher wenig gegründete Initiativen zu und die, die ich ausprobiert habe, waren technisch gut, wirkten aber in anderen Belangen leider nicht sehr professionell und vertrauenserweckend. Doch das ist ein anderes Thema für ein anderes Forum, weil es zwar um eine Idee geht, aber dabei die Nennung von Beispielen hilfreich wäre, was hier nicht geht.

[Nils Dornblut]

Ich habe dann auf "Abbrechen" geklickt und so dürfte das alles keinerlei Einfluss auf die drei bestehenden php.inis gehabt haben. Download habe ich eh keinen gemacht.

Die Funktionalität ist rein für die Erstellung und den Donwload gedacht. Von daher können Sie da nichts falsch machen.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

TYPO3 9.5 funzt NICHT mit MariaDB 10.4

https://get.typo3.org/version/9#system-requirements

Da kommen Probleme auf einen zu🙏

Wir schauen uns die Version von MariaDB noch an bezogen auf verschiedene Skripte. Sobald es da Neuigkeiten gibt, melden wir uns.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ansonsten ist wichtig, das etwaige Änderungen mit ausreichend Vorlauf und einem verlässlichen Zeitplan ausgerollt werden. Ganz schlecht ist, wenn wie aktuell bezüglich Abschaltung von PHP5 10 Monate lang Druck gemacht wird und dann 7 Tage vorher "April. April" gerufen wird. Bei einigen Kunden mit altem PHP5-Zeug (z.B. auf Basis des MVC-Frameworks CakePHP 1.3) war es unmöglich, bis Anfang März ein komplett neues System aufzusetzen. Bei diesen Kunden haben wir dann entweder beim altem Code Kompatibilität zu PHP7.3 hergestellt oder diese Kunden umgezogen. Das war für uns bzw. die Kunden in Summe ein Aufwand im 5stelligen Bereich. Im Nachhinein für nichts raus geschmissenes Geld. Hätten wir bis Oktober Zeit gehabt - also ein halbes Jahr mehr - wären wir bei diesen Kunden gleich die Umstellung auf ein komplett neues System angegangen und hätten uns kostspielige Zwischenschritte gespart.

Uns tut es leid, dass es so gelaufen ist. Von einer Verlängerung der Abschaltung bis Oktober spricht aktuell keiner. Freilich kann ich momentan noch keinen Termin nennen. Es war aber so nicht absehbar und von daher konnten wir leider auch nicht wirklich anders handeln.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

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

Den Zusammenhang, der zur Entscheidung führte, haben wir hier beschrieben:

Bis zur Verfügbarkeit der neuen Webserverplattform werden wir keine Abschaltung der PHP-Versionen 5, 7.0 und 7.1 vornehmen.

Da sollte eigentlich nichts missverständlich sein. Wir wollen durchgängigen Betrieb ermöglichen und daher der Entschluss zur Verschiebung.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

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.

Danke, das passt auch so. Gerade im Forum wurden die Zusammenhänge ja immer wieder diskutiert und das haben wir natürlich auch intern weitergegeben und besprochen.

Mit freundlichen Grüßen

Nils Dornblut

[Martin11]

Nils Dornblut :
Um neuerliche Ankündigungsprobleme zu vermeiden, schlage ich vor, die geplante Abschaltung von 7.2 so bald wie möglich zu kommunizieren.

Der Support für 7.2 endet bereits im November 2020 und wenn 5.6, 7.0., 7.1 in "ein paar Monaten" deaktiviert werden, ist das ja nicht mehr weit weg vom November.
Nicht dass dann z.B. erst im September (nach Erledigung von 5.6-7.1), verlautbart wird, dass 7.2 bereits im November abgeschaltet wird.

[Gast]

Das wird alles sehr eng. Wir haben Shopware 5.5.10 im Einsatz, da Shopware 5.6 oder 6 durch fehlender MySQL 5.7 Unterstützung nicht geht.
Auf Shopware 5.5 läuft maximal PHP 7.2. Das könnt ihr einfach nicht kurzfristig abschalten! Und alles nur, weil MySQL 5.7 (welches seit 2013 gibt) nicht zur Verfügung steht!

@DF: macht es doch ganz einfach: stellt offiziell MySQL 5.7 auf der aktuellen Plattform zur Verfügung und ihr (mit Aufsetzen und Testen der neuen Plattform) und wir Usern (Umstellen auf die neue Plattform) gewinnen nochmal gut Zeit und es wird alles entspannter!

[Schakal]

@DF: macht es doch ganz einfach: stellt offiziell MySQL 5.7 auf der aktuellen Plattform zur Verfügung und ihr (mit Aufsetzen und Testen der neuen Plattform) und wir Usern (Umstellen auf die neue Plattform) gewinnen nochmal gut Zeit und es wird alles entspannter!

Mit Techniken wie Docker sollte das grundsätzlich kein Problem darstellen...

[Lukas M.]

Im aktuellen Setup war ja MySQL 3,4,5 auf unterschiedliche IPs/Interfaces gemapptgemappt. Warum das nicht mit MariaDB 10.3/4 und MySQL 5.7 üuch machen? Über Docker easy.
So kann man MariaDB nutzen wenn man deren extra Features nutzen will oder MySQL 5.7 wenn man halt z.B. JSON braucht.

[Nils Dornblut]

Nils Dornblut :
Um neuerliche Ankündigungsprobleme zu vermeiden, schlage ich vor, die geplante Abschaltung von 7.2 so bald wie möglich zu kommunizieren.

Der Support für 7.2 endet bereits im November 2020 und wenn 5.6, 7.0., 7.1 in "ein paar Monaten" deaktiviert werden, ist das ja nicht mehr weit weg vom November.
Nicht dass dann z.B. erst im September (nach Erledigung von 5.6-7.1), verlautbart wird, dass 7.2 bereits im November abgeschaltet wird.

Sein Sie versichert, wir sprechen mit den zuständigen Projektmanagern darüber und werden schauen, dass wir da eine vernünftige Lösung finden, die allen Seiten gerecht wird. Sie sehen auch am vorgehen hier im Thread, dass wir nach Lösungen jeweils suchen, auch wenn es zeitlich hier nicht ideal verlaufen ist und Sie sich berechtigt diesbezüglich beschweren. In jedem Fall werden wir das in die Diskussion der endgültigen Abschaltung bis PHP 7.1 mit einbeziehen und ich werde den Punkt vorbringen.

Mit freundlichen Grüßen

Nils Dornblut