HOSTBLOGGER.de

Gerade als Idee in einem Video-Meeting entstanden: Wieso haben die gängigen Konferenzsysteme eigentlich neben Bild-Filtern eigentlich keinen Audio-Husten-Filter?

Gerade in Corona-Zeiten doch eine super Geschäftsidee

Wir wurden nach unserer Umstellung auf FPM für PHP mehrfach gefragt, wie wir es gemacht haben, dass Einstellungen in .htaccess-Dateien wie php_value nicht zu einem 500er Fehler führen.

Ganz einfach: Über ein selbst geschriebenes mod_dummy_php-Apache-Modul, das die Anweisungen für sich reklamiert, aber eben ignoriert:

static const command_rec directives[] =
{
    AP_INIT_TAKE2("php_value", null_action, NULL, OR_OPTIONS, "Dummy for php_value"),
    AP_INIT_TAKE2("php_flag",  null_action, NULL, OR_OPTIONS, "Dummy for php_flag"),
    { NULL }
};

So einfach kann es sein.

In den letzten anderthalb Wochen haben wir bei uns im Webhosting eine große Änderung vorgenommen: Wir haben auf PHP-FPM umgestellt.

Eigentlich hatten wir das für das III. Quartal auf dem Plan. Ein treuer Kunde hatte uns allerdings auf eine Unschönheit des bisherigen Setups hingewiesen, daher hatten wir das vorgezogen.

Wir haben nun über unsere gesamte Hosting-Plattform hinweg PHP-FPM schleichend ausgerollt, für jedes Webhosting-Paket haben wir nun einen eigenen FPM-Pool, der sauber mit den Berechtigungen des jeweiligen Pakets (damit meine ich User, Gruppe, Umask) läuft.

Die Umstellung hat für euch als Kunden einen entscheidenden Vorteil: WordPress'es, Nextclouds etc. sind nun um einiges schneller.

Das alte Apache-Modul (das trotz Modul auch bislang schon unter User+Gruppe des Pakets lief!) haben wir entsorgt.

Wer in seinen alten .htaccess-Dateien noch php_flag/php_values hatte, die nicht in <IfModule>-Blöcken war, haben wir angeschrieben.

Und: Wir (in dem Fall ich) haben uns ein Apache-Modul geschrieben, das php_flag/php_value geflissentlich ignoriert. Sprich bei dem, der das noch (ohne den vorgenannten Modul-Block) in einer .htaccess hat, führt es nicht zu einem 500 Internal Server Error.

Ganz nebenbei habt ihr nun über die Datei /logs/php.err.log auch direkten Zugriff auf das PHP-Error-Log, das auf diese Weise nicht mehr mit dem Apache-Error-Log zusammen in eine Datei sondern fortan getrennt geschrieben wird.

Die Umstellung hat hier einiges an Zeit gekostet, aber sie hat sich gelohnt, vor allem für euch als Kunden. Gerade in solchen Situationen zeigt sich, wieviel Vorteile eine zu 100% selbst entwickelte Hosting-Plattform ist.

Seit ein paar Tagen haben wir übrigens KEIN Cookie-Consent auf www.manitu.de mehr.

Warum? Weil wir uns entschieden haben, keinerlei Daten mehr zu speichern, die nicht technisch nötig sind (z.B. der Warenkorb). Die freiwilligen Analyse-Cookies (auch wenn wir bislang nur ein lokales Matomo eingesetzt hatten) hat eh kaum jemand freiwillig angeklickt.

Da können wir uns und vor allem den Besuchern den Banner auch gleich ersparen

Derzeit befinden wir und damit auch ich uns in einer großen Azubi-Vorstellungsrunde. Deswegen ist es in den letzten Wochen hier auch etwas ruhig geworden.

Um mal aus dem Nähkästchen zu plaudern: Die Lehrstellenbörse der IHK funktioniert für uns, wie auch in den Jahren zuvor, wahnsinnig gut. An zweiter Stelle rankt übrigens das Portal der Arbeitsagentur.

Und bzgl. der kommerziellen Anbieter, die sich auf Ausbildungsplätze spezialisiert habe, kann ich nur resümieren: Denen Geld zu geben, ist (zumindest für uns) rausgeworfenes Geld.