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

[Uwe Schliephake]

Die alte Webserverplattform ändert sich nicht, die alten Tarife auch nicht.

Dann ändert sich für Bestandskunden ja gar nichts (bis auf die Abschaltung älterer PHP-Versionen). Ich hatte die Ankündigung so verstanden, dass die Webserverplattform umgestellt wird.

[wecotec]

Dann ändert sich für Bestandskunden ja gar nichts (bis auf die Abschaltung älterer PHP-Versionen). Ich hatte die Ankündigung so verstanden, dass die Webserverplattform umgestellt wird.

Wird sie ja auch, allerdings nur für neue Verträge/Aufträge. Du kannst jederzeit durch einen Auftragswechsel auf diese neue Plattform umsteigen. Das war bisher immer so wenn z.B. neue Hardware eingeführt wurde. Der Auftragswechsel wird von DF so durchgeführt dass Dein Web auf die neue Plattform übertragen wird und es i.d.R zu keinem Ausfall kommt.

Das einzig negative dabei ist der Wechsel der IP-Adresse, d.h. du musst aufpassen wenn Du externe Domains nutzt.

Diese Vorgehensweise ist recht sinnvoll, so können wir Kunden den Umstieg selber steuern...

[Martin11]

@Nils Dornblut:
Die in der php.ini manuellen Einstellungen werden also nicht in die neue user.ini übernommen.

Dazu drei Fragen:

1. Nur noch mal zur Klarstellung: Wir sprechen hier von neuen Tarifen auf der neuen Plattform, wo sich dann dieses Problem ergibt.
Bleibt man im alten System, betrifft einem das nicht, muss sich aber auf eine Abschaltung von php 5, 7.0. 7.1 einstellen?

2. Wechselt man auf das neue System, muss man die manuellen php.ini-Einstellungen in der user.ini nochmal neu machen.
Jetzt habe ich in den letzten 16 Jahren nur alle "heilige Zeit", also alle 3, 4 oder 5 Jahre, mal etwas geändert in der php.ini. Woher weiß ich jetzt, was von all dem technischen Kauderwelsch dort irgendwann mal von mir so hinterlegt wurde oder bereits standardmäßig so war?

Im Moment fällt mir dazu nur ein, von der gesamten php.ini einen screenshot zu machen und dann alles komplett in der user.ini Punkt für Punkt durchzugehen.

3. Sie sprechen in dem Zusammenhang auch vom "Kundenmenü". Das ist ja ziemlich groß. Was von all dem dort hinterlegten muss ebenfalls im neuen System neu oder "wieder" angelegt werden bzw. kann nicht mehr manuell-individuell angelegt werden?
Vielleicht kann man das mal komplett durchgehen und dann alle kritischen Punkte hier aufzählen.

Ich wundere mich, dass solche "Übertragungsfragen" bez. Kundenmenü/php.ini von einem alten auf ein neues System bisher offenbar niemanden in der Projektleitung interessiert haben.
Wenn das keiner weiß und dann nach dem Wechsel plötzlich merkt, was alles nicht mehr (oder anders) funktioniert, dann haben DF und die Kunden den nächsten größeren "Salat".

[sigune]

Bislang konnte man ja auch pro Unterverzeichnis (auch ohne Subdomain) eine eigene php.ini haben. Geht das auch mit .user.ini?

Martin11 : Einen Screenshot mußt du nicht machen, man kann die php.ini im Kundenmenü auch als Datei downloaden.

Gruß
Sigune

[wecotec]

Ich wundere mich, dass solche "Übertragungsfragen" bez. Kundenmenü/php.ini von einem alten auf ein neues System bisher offenbar niemanden in der Projektleitung interessiert haben.
Wenn das keiner weiß und dann nach dem Wechsel plötzlich merkt, was alles nicht mehr (oder anders) funktioniert, dann haben DF und die Kunden den nächsten größeren "Salat".

Der Punkt liegt mir auch sehr im Magen. Reseller haben ggf mehrere Dutzend Kunden auf einem Server. Dort muss vor einem Wechsel alles händisch nachgearbeitet werden.

[RM_Agentur]

Welche Datenbank-Versionen wird es denn nun auf dem neuen Server-Image geben - neben MariaDB auch noch mySQL-Varianten? So klar wird mir das aus dem Anfangspost nicht. Die Sache ist nicht irrelevant, da z.B. auch bei Contao 4.4LTS bestimmte Datenbankversionen Probleme machen können.
Bis wann ist denn mit einer genauen Übersicht aller technischen Eckdaten des neuen Images zu rechnen? Ich denke, dass viele auf die neue Plattform warten und aufgrund der prognostizierten Verbesserungen schnellstens wechseln wollen, dafür aber wohl auch einiges an den laufenden Anwendungen angepasst werden muss. Daher wäre eine schnelle Bekanntgabe sinnvoll, um die Vorbereitung zur Umstellung möglichst genau und frühzeitig angehen zu können.
Hier geht es nicht um Auskunft neuer Termine o.ä., die nur ungern fix genannt werden, aber eine gepflegte Liste mit den bereits fixen Eckdaten wäre sicher für viele wünschenswert - die Auflistung im Anfangspost zeigt ja lediglich die Richtung an, lässt jedoch viele Fragen offen, wie man an der Länge des Threads erkennt.

[Gast]

Kann mich da nur anschließen. Wir lassen derzeit prüfen, ob MariaDB 10.4 auch kompatibel ist mit Shopware 5.5 (bisher lese ich nur was von MariaDB 10.3 bei Shopware). MySQL 5.7 und PostgreSQL (in der Version >= 9.5 wird beispielsweise von OpenProject gefordert) wären noch gut.

[Nils Dornblut]

Hallo Herr Dornblut, danke für das Feedback, aber finden Sie es wirklich gelungen, die Kunden über Monate auf die Abschaltung der alten PHP-Versionen mehrfach hinzuweisen und dann 5 Tage vorher abzusagen? Kann man solche Entscheidungen nicht mal mindestens 4 Wochen vorher treffen, zumal sich an den Gegebenheiten kurzfristig nichts geändert hat?

Es wäre wohl unglaubwürdig zu sagen, dass das ideal ist! Natürlich wäre eine frühere Information besser gewesen oder gleich ein Termin der eingehalten wird. Leider war es aber nur so möglich und wir konnten die Information nicht früher veröffentlichen. Tut uns sehr leid!

Zu Ihrer etwas ironischen Bemerkung, ob ich mir alle Passwörter und Kundendomains merken kann: Sicher ist Ihnen nicht entgangen, dass es sogenannte Autofill-Funktionen in modernen Browsern gibt und die Speichern zu dem sogar das Passwort. Wenn also der Kunde XYZ ein Problem hat, haben wir bisher xyz.de als User eingegeben und dann wurde automatisch das Passwort geladen. Nach Ihrer Umstellung, müssen wir nun immer erst im CRM die Kundennummer heraussuchen, da die ja nicht im unmittelbaren Zusammenhang mit der Domain steht. Das Grinssmilie spare ich mir.

Keinesfalls wollt eich mich darüber lustig machen! Bitte entschuldigen Sie, wenn das so rüber gekommen ist. Sie mussten dann doch früher auch die Domain wissen, jetzt halt die Kundennummer. Die Domain mussten Sie vermutlich doch früher auch nachsehen? Also macht das doch arbeitsablauftechnisch keinen großen Unterschied und wie gesagt, wenn Sie einen Passwortmanager einsetzen, der noch dazu für mehrere Mitarbeiter eingerichtet werden kann, dann können Sie sogar noch nach Kundenname oder ein sonstiges Attribut was "immer" direkt bekannt ist den Datensatz bezeichnen und Sie haben eine übersichtliche und sichere Lösung die beliebig skaliert?

Dass ich beim Anklicken dieser Chataufforderung im CP mehrere Minuten Wartezeit haben, war nicht einmal, sondern bisher immer der Fall.

Ok, das ist nicht gut. Ich werde das noch einmal so weitergeben, damit man hier mit der Ressourcenzuteilung schauen kann.

Es wäre sicher eine gute Idee, in Zukunft Ihr großes Maß an Selbstgefälligkeit gegen ein gewisses Maß an Selbstkritik zu tauschen.

Wir sind da durchaus selbstkritisch. Wir wollen Ihnen hier versuchen Lösungen zu bieten. Dass die Eingabe einer Kundennummer wenig sprechend ist, ist uns auch bewusst. Wir im anderen Thread direkt zum Thema gesagt, soll das die Basis für weitere Änderungen in dem Bereich sein.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ok, danke, bis dato musste man ja das selbst reinschreiben, zb. bei 7.2 auch den Pfad für IonCube 7.2

Das wird nicht mehr so sein, da Module nicht mehr dynamisch hinzu geladen werden können bei PHP-FPM. Hier werden wir ein umfangreiches Setup bereitstellen was direkt eingebunden ist. Das ist technisch bedingt nur so zu machen.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Also liest sich an und für sich ja alles ganz gut, nur kenne ich derzeit keine TYPO3 Version, die mit MARIADB 10.4. funktioniert.
D.h. ich habe dann jetzt ein massives Problem.

Ich gebe den Punkt gerne zur Prüfung. Haben Sie Details zu der Kompatibilität von Typo3 und MariaDB?

Ich finde direkt das hier mit MariaDB <=10.3

https://docs.typo3.org/m/typo3/guide...nts/Index.html

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Daher steht das ja da: "Um Ihnen den bestmöglichen Service zu bieten, werden Ihnen neuere Versionen von MySQL auf der neuen Webserverplattform zur Verfügung stellen."

Damit ist MariaDB gemeint. Es wird nur eine Version von MariaDB dort geben und kein MySQL mehr. Aktuell ist 10.4 von MariaDB geplant. Das ist aber noch nicht in Stein gemeißelt. Daher bitte gerne weitere Infos wenn Probleme gesehen werden.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Dann ändert sich für Bestandskunden ja gar nichts (bis auf die Abschaltung älterer PHP-Versionen). Ich hatte die Ankündigung so verstanden, dass die Webserverplattform umgestellt wird.

Die Webserverplattform wird umgestellt, aber mit der Umstellung ist ein Tarifwechsel verbunden. Wenn Sie nicht wechseln, dann wird zu einem noch festzusetzenden Termin PHP 5, 7.0 und 7.1 abgeschaltet. Auf der neuen Plattform existieren die PHP-Versionen direkt nicht.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

@Nils Dornblut:
Die in der php.ini manuellen Einstellungen werden also nicht in die neue user.ini übernommen.

Richtig, das geht leider nicht.

1. Nur noch mal zur Klarstellung: Wir sprechen hier von neuen Tarifen auf der neuen Plattform, wo sich dann dieses Problem ergibt.
Bleibt man im alten System, betrifft einem das nicht, muss sich aber auf eine Abschaltung von php 5, 7.0. 7.1 einstellen?

Richtig, hier ändert sich erst einmal nichts und es ist auch diesbezüglich erst einmal nichts geplant.

2. Wechselt man auf das neue System, muss man die manuellen php.ini-Einstellungen in der user.ini nochmal neu machen.
Jetzt habe ich in den letzten 16 Jahren nur alle "heilige Zeit", also alle 3, 4 oder 5 Jahre, mal etwas geändert in der php.ini. Woher weiß ich jetzt, was von all dem technischen Kauderwelsch dort irgendwann mal von mir so hinterlegt wurde oder bereits standardmäßig so war?

Das ist eben auch durchaus das Migrationsproblem. Wir wissen auch nicht, was geändert wurde und was nicht. Sie können natürlich einfach die php.ini-Datein vorher kopieren und dann sozusagen als .user.ini wieder einsetzen. Sauberer wäre es aber vermutlich jeweils logisch zu schauen was man will und was nicht. Ohne persönliche Dokumentation sicher nicht ganz einfach, das ist leider richtig, nur würde es dann weiter so undurchsichtig bleiben. Es sein also empfohlen entsprechend zu dokumentieren.

3. Sie sprechen in dem Zusammenhang auch vom "Kundenmenü". Das ist ja ziemlich groß. Was von all dem dort hinterlegten muss ebenfalls im neuen System neu oder "wieder" angelegt werden bzw. kann nicht mehr manuell-individuell angelegt werden?
Vielleicht kann man das mal komplett durchgehen und dann alle kritischen Punkte hier aufzählen.

Es wird ein paar wenige Einstellungen geben, die Sie direkt im Kundenmenü un der .user.ini machen können. Welche das sind, werden wir noch erklären.

Ich wundere mich, dass solche "Übertragungsfragen" bez. Kundenmenü/php.ini von einem alten auf ein neues System bisher offenbar niemanden in der Projektleitung interessiert haben.
Wenn das keiner weiß und dann nach dem Wechsel plötzlich merkt, was alles nicht mehr (oder anders) funktioniert, dann haben DF und die Kunden den nächsten größeren "Salat".

Wir werden deutlich darauf hinweisen, dass hier entsprechende Anpassungen erforderlich sind. Das interessiert uns schon, nur ist es leider technisch nicht sinnvoll machbar da eine Migration anzubieten, wenn hinterher was sinnvolles herauskommen soll. Wie gesagt, im Regelfall wird dort nicht so viel umkonfiguriert und es war und ist angeraten Änderungen zu dokumentieren. Gerade bei großen Versionssprüngen in der PHP-Version durchaus auch wichtig zu wissen.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Bislang konnte man ja auch pro Unterverzeichnis (auch ohne Subdomain) eine eigene php.ini haben. Geht das auch mit .user.ini?

Ich frage da noch einmal nach, aber mit der .user.ini ist es normal so, dass die sich in Unterverzeichnisse im Gegensatz zur php.ini (wenn sie im Verzeichnis liegt und nicht im KM konfiguriert wurde für eine Domain im aktuellen Image) vererbt wird. Möchte man das nicht, kann man in Unterverzeichnissen neue Einstellungen über eine weitere .user.ini setzen usw. Es ist zu beachten, dass in .user.ini-Dateien nicht alle php.ini-Direktiven genutzt werden können. Es können die hier aufgelisteten Direktiven, die mit PHP_INI_ALL, PHP_INI_PERDIR und PHP_INI_USER gekennzeichnet sind, benutzen werden. Wie schon erwähnt können beispielsweise keine zusätzlichen PHP-Module wie ionCube geladen werden, die sind direkt mit eingebunden durch uns.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Welche Datenbank-Versionen wird es denn nun auf dem neuen Server-Image geben - neben MariaDB auch noch mySQL-Varianten? So klar wird mir das aus dem Anfangspost nicht. Die Sache ist nicht irrelevant, da z.B. auch bei Contao 4.4LTS bestimmte Datenbankversionen Probleme machen können.

Es wird "nur" MariaDB geben, ich habe das oben auch noch präzisiert. Aktuell in Version 10.4 geplant, wenn Sie da Probleme sehen bitte wie gesagt melden. Das könnte noch angepasst werden.

Bis wann ist denn mit einer genauen Übersicht aller technischen Eckdaten des neuen Images zu rechnen? Ich denke, dass viele auf die neue Plattform warten und aufgrund der prognostizierten Verbesserungen schnellstens wechseln wollen, dafür aber wohl auch einiges an den laufenden Anwendungen angepasst werden muss. Daher wäre eine schnelle Bekanntgabe sinnvoll, um die Vorbereitung zur Umstellung möglichst genau und frühzeitig angehen zu können.

Die Eckdaten haben wir oben veröffentlicht. Wenn Sie mehr Infos benötigen, fragen Sie bitte. Ob wir das jetzt direkt sagen können, prüfen wir dann.

Hier geht es nicht um Auskunft neuer Termine o.ä., die nur ungern fix genannt werden, aber eine gepflegte Liste mit den bereits fixen Eckdaten wäre sicher für viele wünschenswert - die Auflistung im Anfangspost zeigt ja lediglich die Richtung an, lässt jedoch viele Fragen offen, wie man an der Länge des Threads erkennt.

Wie gesagt, offene Fragen bitte gerne stellen. Das Projektteam wird direkt diesbezüglich gefragt und wir können auch noch reagieren dann.

Mit freundlichen Grüßen

Nils Dornblut