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. ;-)
Richtig, das kann man so in den bestehenden Tarifen machen. Es ging eher detailliert aber um die Anpassungen die man jeweils gemacht hat. Da gibt es jetzt keine direkte Vergleichsmöglichkeit, gerade wenn man eine php.ini im Verzeichnis einsetzt oder Reihenfolgen anders sind.
Wird es mit der neuen Serverplattform auch einen „Superuser“ geben, mit dem man auf der Konsole über Quotagrenzen hinweg arbeiten kann?
Nein, das wird weiterhin nicht möglich sein. Es wird einen einfachen Datei-Assistenten geben, mit dem man Dateien und Verzeichnisse auch über Quota-Grenzen hinweg kopieren.
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.
Wir managen den Server für Sie und diesbezüglich muss ein Vertrauen vorhanden sein, das ist klar. Wenn es ein Problem gab können Sie natürlich bei uns nachfragen.
Kann der NGINX (optional) (de)aktiviert werden? Kann der NGNIX auch als Reverse Proxy eingesetzt werden? Wie erfolgt die Konfiguration von NGINX?
Deaktivierung ist nicht möglich, das ist fest in die Architektur integriert. Zu weiteren Details schauen wir mal, was wir später noch erklären können. Konfiguration ist meine ich nicht möglich/nötig.
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.
Danke, das hat funktioniert. Nicht weil ich die Datei bräuchte (für mich nur ein unformatierter "Endloswurm" an technischem Kauderwelsch ), aber man sieht dann im Kundenmenü eine solche jungfräuliche php.ini und die ich habe ich in einigen screenshots jetzt festgehalten. Das kann ich jetzt mit den Änderungen dokumentieren.
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.
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.
Fast alle Linux-Distributionen (u.a. Ubuntu, RHEL, CentOS, Fedora, BSD, Debian, ..) und somit die Basis-Betriebssysteme für Webserver haben längst standardmäßig MariaDB an Bord. Auf der Mehrheit der VPS-, Root- und Cloudserver ist heutzutage vermutlich Plesk (auf Linuxbasis) vorinstalliert und da kommt dann standardmäßig auch längst MariaDB statt MySQL zum Einsatz. Viele Institutionen wie Google, die EU, Alibaba unterstützen MariaDB, während die Entwicklung bei MySQl einzig und allein von Oracle abhängt. Die Zukunft kann niemand mit Sicherheit vorher sagen, aber das MySQL eines Tages von MariaDB überholt wird, ist zumindest kein völlig unrealistisches Szenario. Mit zunehmender Verbreitung von MariaDB werden Typo3 und Co. Support dafür bieten (müssen).
Ich fände es gut, wenn HSTS bei ManagedServer/Reseller via Kundenmenü (de)aktiviert pro Domain werden kann.
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.
Kann der NGINX (optional) (de)aktiviert werden? Kann der NGNIX auch als Reverse Proxy eingesetzt werden? Wie erfolgt die Konfiguration von NGINX?
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.
Soll heißen: Auch wenn mich das kaum noch betrifft, weil fast alles schon umgezogen ist: Ich stimme ausnahmsweise mit den Designüberlegungen von DF überein.
Die Zukunft kann niemand mit Sicherheit vorher sagen, aber das MySQL eines Tages von MariaDB überholt wird, ist zumindest kein völlig unrealistisches Szenario. Mit zunehmender Verbreitung von MariaDB werden Typo3 und Co. Support dafür bieten (müssen).
Was bringt uns das bei bestehenden Installationen? Wenn es Update des Images gibt muss da 110%ige Sicherheit sein dass alles so wie vorher läuft. Das mag für DF-Kunden mit 2-3 Webs überschaubar sein, als Reseller muss man aber die Sicherheit haben dass DF (mal wieder) keinen Mist baut, da sind leicht mehrere hundert Webs betroffen
Was bringt uns das bei bestehenden Installationen? Wenn es Update des Images gibt muss da 110%ige Sicherheit sein dass alles so wie vorher läuft. Das mag für DF-Kunden mit 2-3 Webs überschaubar sein, als Reseller muss man aber die Sicherheit haben dass DF (mal wieder) keinen Mist baut, da sind leicht mehrere hundert Webs betroffen
Die Architektur bei DF inkl. dem RP ist rund 10 Jahre alt. DF wird völlig zurecht dafür kritisiert, da in den letzten Jahren zu wenig investiert zu haben Die Welt ist aber in der Zeit nicht stehen geblieben, sondern hat sich weiter gedreht. Nun geht DF das an und will Verbesserungen bringen. Nun soll alles so bleiben, wie es ist? Auf die meisten dürfte eine Umstellung von MySQL auf MariaDB auch keine Auswirkungen haben - insbesondere wenn DF die Datenbanken migriert und die kleinen Unterschiede dabei berücksichtigt.
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.
Es gibt Anleitungen, wie man auf CentOS 8 MySQL 5.7 installiert (standardmäßig im repository ist nur MySQL 8, welches von einigen Programmen nicht unterstützt wird). Sollte ja DF hinbekommen zusätzlich zu installieren.
Kommentar