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

[Nils Dornblut]

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.

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

[RM_Agentur]

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.

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.

Konkret gab es wohl in der Entwicklung der Contao LTS-Versionen 4.4 und auch 4.9 grundsätzlich Probleme mit MariaBD ab Version 10.2, was auch mit PHP und doctrine usw. zusammenhing - siehe z.B. https://github.com/contao/core-bundle/issues/918

Ich konnte das Ganze noch nicht direkt testen, aber grundsätzlich sollten gerade auf den Reseller-Servern die typischen Anwendungen in deren LTS-Versionen (Typo3, Contao, Shopware 5 usw.) laufen. Zurzeit gibt es einige konkrete Vorgaben der Datenbanken (z.B. für Contao siehe hier: https://docs.contao.org/manual/de/in...raussetzungen/).
Ich gehe schon davon aus, dass bei der Serverimage-Entwicklung nicht "auf Teufel komm raus" auf die allerneuesten Versionen gesetzt wird, sondern eher auf die 100%ige Lauffähigkeit der praxisnahen Anwendungen und deren am häufigsten eingesetzten Versionen getestet wird. Nicht, dass zuletzt wieder um die Servereigenschaften drumherum programmiert werden muss, anstatt dass sich der Hoster an der eingesetzten Software orientiert.

[phobos]

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

TYPO3 mit MariaDB 10.4 läuft nicht, noch nicht mal mit gefrickel....

Hier steht das ganze zum nachlesen:

https://typo3worx.eu/2019/08/typo3-and-mariadb-10-2-7/

[Rainer.D]

Ich rege an bei MySQL zu bleiben, das ist "Industriestandard" und mit allem erdenklichem kompatibel. Niemand möchte das große MariaDB gefrickel beginnen. Verbessert Dinge die zu verbessern sind und schafft nicht ohne Not neue Baustellen.

[ShortSnow]

TYPO3 mit MariaDB 10.4 läuft nicht, noch nicht mal mit gefrickel....

Hier steht das ganze zum nachlesen:

https://typo3worx.eu/2019/08/typo3-and-mariadb-10-2-7/

Hi, das sagt nichts über MariaDB 10.4 bei TYPO3 9.5 oder der 10. Lediglich über TYPO3 8.7.

Hier liegt das Problem an der Kompatibilität zu php7.0. Es gibt eine dbal Version die problemlos mit TYPO3 8.7 und MariaDB (getestet bis MariaDB 10.3), funktioniert. Mache ich schon eine ganze Weile so. Nur ist diese dbal Version erst ab php7.1, weswegen diese nicht offiziell eingepatcht wird.

Aber die ELTS Version von TYPO3 8.7 aussenvorgelassen, ist TYPO3 8.7 eh EOL zum April.


Gruß Arne

Nachtrag: In Slack kurz nachgesehen. Es scheint so, als ob TYPO3 9.5 mit MariaDB 10.4 läuft. Habe ich nur nicht selbst getestet.

[Rainer.D]

Wie geht man denn mit dem Problem um dass von den Entwicklern zukünftig nicht geplant ist MariaDB kompatibel mit MySQL zu halten? Dass müsste man auch bedenken. Das MariaDB (mehr oder weniger) kompatibel mit MySQL ist, ist nur eine Momentaufnahme, das wird sich ändern ...

[ShortSnow]

Wie geht man denn mit dem Problem um dass von den Entwicklern zukünftig nicht geplant ist MariaDB kompatibel mit MySQL zu halten? Dass müsste man auch bedenken. Das MariaDB (mehr oder weniger) kompatibel mit MySQL ist, ist nur eine Momentaufnahme, das wird sich ändern ...

Da ist die Frage: "Was machen die CMS/Shops/Clouds usw.?" Wenn die dann lieber die neuen Funktionen von MariaDB mögen, wird man mit MySQL 8 nicht glücklich... Aber die meisten Systeme unterstützen doch auch jetzt schon oft verschiedene DB-Systeme.

Gruß Arne

[afiss]

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 aus 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, nur würde es dann weiter so undurchsichtig bleiben. Es sein also empfohlen entsprechend zu dokumentieren.

Hallo Martin & Nils,

vllt. habe ich das Problem missverstanden – aber falls nicht:
Im KM kannst du (auch als Reseller) unter Webspace -> PHP-Einstellungen filtern, welche Domains eine eigene php.ini Datei haben (also abweichende Einstellungen deiner vorgegebenen Standard-Konfiguration).
Dazu filterst du einfach über Vorhandene php.ini – z.B. "alle mit php.ini für PHP 7".

Damit hast du zumindest eine Liste der Domains, welche eine abweichende Konfig haben die du sichern musst. Das ist besser als nichts. ;-)

Viele Grüße
Alex

[Martin11]

Hallo Martin & Nils,

vllt. habe ich das Problem missverstanden – aber falls nicht:
Im KM kannst du (auch als Reseller) unter Webspace -> PHP-Einstellungen filtern, welche Domains eine eigene php.ini Datei haben (also abweichende Einstellungen deiner vorgegebenen Standard-Konfiguration).
Dazu filterst du einfach über Vorhandene php.ini – z.B. "alle mit php.ini für PHP 7".

Damit hast du zumindest eine Liste der Domains, welche eine abweichende Konfig haben die du sichern musst. Das ist besser als nichts. ;-)

Viele Grüße
Alex

Hallo Alex,
ich bin "nur" Webmaster, der sich von Zeit zu Zeit mit technischen Dingen rumschlägt, kein Reseller.
Ich habe drei Domains hier bei DF und bei allen dreien habe ich von Zeit zu Zeit die gleichen Sachen in einer eigenen php.ini manuell eingetragen/geändert. Das weiß ich auf jeden Fall sicher. Es dürften drei oder vier Sachen sein.
Hätte ich eine vierte Website ohne php.ini-Änderungen, dann müsste ich diese unberührte php.ini nur vergleichen mit einer der drei anderen. Dann wär's einfach.

Eine frische, unberührte php.ini für meinem Basictarif im shared hosting, kann ich die irgendwo sehen? Dann kann ich ganz einfach vergleichen und sehe sofort die Unterschiede. Im Grunde würde mir ein screenshot genügen. Vielleicht kann mir das Herr Dornblut oder ein anderer User hier posten?

Nils Dornblut

Das ist eben auch durchaus das Migrationsproblem. Wir wissen auch nicht, was aus ? 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 ? , nur würde es dann weiter so undurchsichtig bleiben. Es ? sein also empfohlen entsprechend zu dokumentieren.

An den drei durch ein rotes Fragezeichen markierten Stellen ist offenbar Text verschwunden, falls etwas Wichtigeres dabei war, bitte nochmal ergänzen.
Das Kopieren der Datei (passt das 1:1?) wurde bereits vorgeschlagen, aber dem vertraue ich ehrlich gesagt nicht. Ich würde das lieber "oldschool" manuell machen, soo viele Einstellungen sind es ja auch nicht. Der Zeitaufwand ist nicht das Ding.

Andere Sachen aus dem Kundenmenü, die ggf. neu eingestellt werden müssen, werden also noch kommuniziert. Das ist gut.

[zzet]

Wird es mit der neuen Serverplattform auch einen „Superuser“ geben, mit dem man auf der Konsole über Quotagrenzen hinweg arbeiten kann?

[Schakal]

- Cronjobs: hier wäre es sehr praktisch, wenn es möglich wäre, Befehle auch mit Parametern aufrufen zu können. Bislang muss ich dafür immer ein Wrapper Skript bauen.

Befürworte ich ebenfalls. +1

kommt HSTS per Default für alle Webseiten?

Wir haben das diskutiert. Es ist eher unwahrscheinlich, dass das per Default kommt. Wir würden eher vermuten, dass das für Verwirrung sorgt, wenn bestimmte Dinge z. B. nach Zertifikatstausch nicht gehen.

Ich fände es gut, wenn HSTS bei ManagedServer/Reseller via Kundenmenü (de)aktiviert pro Domain werden kann.

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.

Kann der technische Support auf Anfrage Module bereitstellen, wenn diese bisher nicht verfügbar sind?

Änderung am Monitoring: Traffic Monitoring, sowie Monitoring-Grafiken über die aktuelle Auslastung auf einem eigenen Server sind nicht mehr einzusehen.

Wie erfolgt zukünftig das Monitoring für Kunden? Vor knapp zwei Wochen einen Fall gehabt, wo ich froh die Auslastung (rückwirkend) einsehen zu können. Denn der Serverguard hat mehr oder weniger falsch reagiert. D.h. zukünftig bin ich im Blindflug unterwegs und muss dem Support zu 100% vertrauen... hmm.

NGINX wird zukünftig in Kombination mit Apache als Webserver eingesetzt: NGINX kommt hierbei als Frontend Proxy zum Einsatz und Apache kümmert sich um die eigentliche Auslieferung der Webseiten. Diese Kombination bietet zukünftig weitere Möglichkeiten.

Kann der NGINX (optional) (de)aktiviert werden? Kann der NGNIX auch als Reverse Proxy eingesetzt werden? Wie erfolgt die Konfiguration von NGINX?

Statt Webalizer wird zur Auswertung Ihrer Logfiles zukünftig GoAccess eingesetzt: Ein Beispiel wie es auch bei uns in etwa aussehen wird, finden Sie hier. Wir aktualisieren einmal am Tag die entsprechenden Daten.

Ist es angedacht, dass die Auswertung auf ManagedServer öfters bzw. alle x Stunden aufgerufen wird?

Fragen:
Ist zukünftig ein externet Zugriff auf MariaDB bzw. einzelnen Datenbanken möglich?
Gibt es auch Änderungen bezüglich des Backups, Aufbewahrungszeit und Wiederherstellmöglichkeiten?

[Nils Dornblut]

Eine frische, unberührte php.ini für meinem Basictarif im shared hosting, kann ich die irgendwo sehen? Dann kann ich ganz einfach vergleichen und sehe sofort die Unterschiede. Im Grunde würde mir ein screenshot genügen. Vielleicht kann mir das Herr Dornblut oder ein anderer User hier posten?

Einfach in das Kundenmenü gehen auf Webspace --> PHP-Einstellungen --> Reiter "PHP.INI-Generator". Dort einfach eine erzeugen und keine Änderungen vornehmen. Abschließend downloaden. Ich hänge auch eine an hier von PHP 7.

An den drei durch ein rotes Fragezeichen markierten Stellen ist offenbar Text verschwunden, falls etwas Wichtigeres dabei war, bitte nochmal ergänzen.

So:
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 sei also empfohlen entsprechend zu dokumentieren.

1. -aus
2. +richtig
3. -s

Sorry!

Das Kopieren der Datei (passt das 1:1?) wurde bereits vorgeschlagen, aber dem vertraue ich ehrlich gesagt nicht. Ich würde das lieber "oldschool" manuell machen, soo viele Einstellungen sind es ja auch nicht. Der Zeitaufwand ist nicht das Ding.

Einige Dinge kann man in der .user.ini nicht (mehr) ändern wie z. B. zusätzliche Extensions. Das wird dann aber einfach ignoriert. Oft ist es so, dass php.ini-Dateien über Jahre mitgeschleppt wurden und diverse PHP-Versionen durchlaufen haben. Von daher wäre ein Aufräumen sicher anzuraten.

Andere Sachen aus dem Kundenmenü, die ggf. neu eingestellt werden müssen, werden also noch kommuniziert. Das ist gut.

Die meisten Dinge stehen hier schon, im Kundenmenü gibt es einige Änderungen, die an die Funktionalitäten angepasst sind. Wenn Sie den Tarifwechsel beauftragen, gibt es eine Übersicht und eine Verlinkung auf eine Detailseite.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Konkret gab es wohl in der Entwicklung der Contao LTS-Versionen 4.4 und auch 4.9 grundsätzlich Probleme mit MariaBD ab Version 10.2, was auch mit PHP und doctrine usw. zusammenhing - siehe z.B. https://github.com/contao/core-bundle/issues/918

Ich konnte das Ganze noch nicht direkt testen, aber grundsätzlich sollten gerade auf den Reseller-Servern die typischen Anwendungen in deren LTS-Versionen (Typo3, Contao, Shopware 5 usw.) laufen. Zurzeit gibt es einige konkrete Vorgaben der Datenbanken (z.B. für Contao siehe hier: https://docs.contao.org/manual/de/in...raussetzungen/).
Ich gehe schon davon aus, dass bei der Serverimage-Entwicklung nicht "auf Teufel komm raus" auf die allerneuesten Versionen gesetzt wird, sondern eher auf die 100%ige Lauffähigkeit der praxisnahen Anwendungen und deren am häufigsten eingesetzten Versionen getestet wird. Nicht, dass zuletzt wieder um die Servereigenschaften drumherum programmiert werden muss, anstatt dass sich der Hoster an der eingesetzten Software orientiert.

Danke für die Infos. Ich gebe diese so weiter.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

TYPO3 mit MariaDB 10.4 läuft nicht, noch nicht mal mit gefrickel....

Hier steht das ganze zum nachlesen:

https://typo3worx.eu/2019/08/typo3-and-mariadb-10-2-7/

Okay, die ältere Version von Typo3 wurde hier ja schon diskutiert bzw. das angemerkt:

https://forum.df.eu/forum/allgemein/aktuelle-informationen/4658-verschiebung-der-einstellung-alter-php-versionen-info-zur-neuen-webserverplattform?p=4714#post4714

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Ich rege an bei MySQL zu bleiben, das ist "Industriestandard" und mit allem erdenklichem kompatibel. Niemand möchte das große MariaDB gefrickel beginnen. Verbessert Dinge die zu verbessern sind und schafft nicht ohne Not neue Baustellen.

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.

Mit freundlichen Grüßen

Nils Dornblut