Das Update von Debian jessie auf Debian stretch hat im Umfeld meines Blogs die Migration von MariaDB 10.0 auf MariaDB 10.1 und von PHP 5.6 auf PHP 7.0 gebracht. Dazu musste ich natürlich in der Apache-Konfiguration das php5-Modul durch das php7-Modul ersetzen und noch einige andere kleine Änderungen durchführen.
Danach waren im Blog durchgängig die Umlaute kaputt; das sah so ähnlich aus, als würde man ein UTF-8 codiertes Dokument auf einem ASCII-Terminal betrachten. Insider nennen das auch Double-WTF8.
While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI.
Die Artikelreihe zum Thema "Trennung von Webanwendungen untereinander", die mit fastcgi,suphp und zwei Artikeln über das klassischesuexec begann, findet heute ihren vorläufigen Abschluss mit dem Setup, für das ich mich letztendlich entschieden habe.
Da auf dem von mir angepeilten Zielsystem nur eine Handvoll Präsenzen mit ähnlich wenigen verschiedenen Webanwendungen ins Hosting kommen wird, könnte ich mich für eine Lösung entscheiden, deren Skalierungsverhalten sie für "richtiges" Hosting uninteressant macht. Jede Webapplikation bekommt einen eigenen apache, der gleich unter einer nicht priviligierten uid gestartet wird und auf einem hohen Port von 127.0.0.1 Verbindungen annimmt. Das Mapping auf die "offizielle" IP und Port 80 übernimmt ein zentraler "normaler" apache als reverse proxy.
Dieser Artikel entstand ursprünglich im Jahr 2006. Fünf Jahre später hat auch Debian es geschafft, mehrere apache-Instanzen "ordentlich" zu unterstützen, und ganz ohne gepatchte Scripts. Diese überarbeitete Version dieses Artikels beschreibt die Vorgehensweise unter dem in 2011 aktuellen Debian squeeze.
In Fortsetzung der Artikelreihe zur Entfernung von PHP-Scripts aus dem Accountkontext des Webservers ist heute FastCGI an der Reihe.
Kurzzusammenfassung aus der Theorie: Es ist vermutlich performanter als suexec und suphp, bringt aber weder Erleichterung in der Handhabung noch in der Sicherheit.
In diesem Artikel bekommt auch das debianhowto.de apache2-php-fcgi-HOWTO sein Fett weg.
In Fortsetzung von suexec my php, baby^wapachehabe ich gestern suexec auf dem ersten Produktivsystem verfügbar gemacht, und einige Unzulänglichkeiten im Debian-Setup gefunden.
