Wenn PHP nicht mehr ausgeführt wird

Wenn man einen Linux Webserver betreibt, der normalerweise UTF-8 benutzt, und ein Windowsfan speichert in seinem Lieblingstexteditor die PHP Datei ab, dann kann das voll in die Hose gehen.

Windows UTF-16LE in PHP Skripten

So geschehen bei einem Projekt das ich für Freunde betreue. Eine klitzekleine Anpassung an einem Textblock führte dazu, daß der Windostexteditor der Wahl, statt dem vorgefundenen UTF-8, den Text als Windows Hausformat UTF-16LE abspeicherte.

Merken tut man das daran, daß man ums verrecken alles richtig im Webserver eingestellt hat, aber das PHP als HTML ausgegeben wird. Da wird sogar der PHP Interpreter korrekt aufgerufen, aber nicht mal der kann das Script korrekt als PHP erkennen und gibt es dann einfach als Text aus. Weil es keinen PHP Fehler gibt, ohne PHP auch kein Wunder, gibt es auch keine Fehlermeldung im Apachelogfile dazu.

Ihr könnt die mit vi , Gedit, Fokuswriter oder einem beliebigen anderen Editor aufmachen, keiner von denen wird Euch sagen, daß der Zeichensatz UTF-16LE ist und es klammheimlich genauso wieder abspeichern. Das PHP Script funktioniert dann einfach trotzdem nicht.

Des Rätsels Lösung

Wenn Ihr also mal vor einem Rätsel steht, wieso alle anderen PHP Scripte laufen, nur das eine nicht, könnte Euch das helfen:
1. mit „file filename.php“ den Typ bestimmen:

So müßte es aussehen:

camel.php: PHP script, UTF-8 Unicode (with BOM) text, with CRLF line terminators

So könnte es aussehen:

camel.php: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators

2. So behebt Ihr es:

iconv -c -f UTF16LE -t UTF-8 < camel.php >camel2.php

Danach funktioniert das Script wieder und Ihr könnt dem Schuldigen die Ohren langziehen gehen 😉

Apache httpd 2.4.41 mit defektem PIPE support

Die Apache Webserver Version 2.4.41 hat einen defekten PIPE Support, was die Ausführung von CGI Scripten wie PHP Prozessen behindert. Abhilfe schafft nur ein Downgrade auf die vorherige Version.

Voraussetzungen für den Fehler

Als Voraussetzungen für den Fehler braucht man lange Ausgaben und die Ausführung von PHP als CGI, aber das ist natürlich nicht auf PHP begrenzt, es darf auf ein eigenes C Exe oder Perl sein. Bei uns war es ein PDF erzeugendes Script.

  1. httpd 2.4.41
  2. Das Script wird per CGI ausgeführt
  3. Das Script erzeugt lange Ausgaben von ~500kb

Die Symptome

Die Symptome an denen Ihr erkennen könnt, daß Ihr betroffen seid:

  1. Der Aufruf eines PHP Scripts per Browser timed aus.
  2. es stappeln sich die PHP Prozesse auf dem Server
  3. ein „strace -f -p ..hier_php_pid_angeben..“  zeigt nur eine Zeile an:
    … write( ………………….. ) = xXxXxx   , wobei die Xxx eine 6-x stellige Anzahl haben wird
  4. kurze Ausgaben, wie bei WordPresswebseiten üblich, werden normal abgearbeitet

Die Lösung

Für Fedora 29 lautet die Lösung einfach Downgraden:

dnf -y downgrade https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/httpd-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/mod_ssl-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/httpd-tools-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/noarch/httpd-filesystem-2.4.39-3.fc29.noarch.rpm

systemctl restart httpd

Das war es dann auch schon. GGf. müßt Ihr noch liegen gebliebene Prozesse killen, aber die sollten beim httpd restart eigentlich von alleine terminieren, weil die PIPE endlich beendet wird.

Bugreport an Fedora ist raus, hat aber unverständlicherweise noch keine Reaktion hervorgerufen.

PHP 5.6/7.x Remote Execution Schwachstelle

Zeit zum Updaten: PHP eine Remote Code Execution Schwachstelle hat!

Risikostufe 4 – Remote Code Execution

Das BSI schreibt im Advisory:

„Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in PHP ausnutzen, um Informationen offenzulegen, einen Denial of Service herbeizuführen oder Code mit den Privilegien des angegriffenen Dienstes zur Ausführung zu bringen.“

betrifft:

Open Source PHP < 5.6.40
Ooen Source PHP < 7.1.26
Open Source PHP < 7.2.14
Open Source PHP < 7.3.1

Fedora – PHP 7 – ZipArchive

Wer mit Fedora 25+ die Meldung „PHP Fatal error: Uncaught Error: Class ‚ZipArchive‘ not found in /www/pages/….“ sieht, wenn er eine Webanwendung installiert, der braucht folgenden Fix:

libzip-1.1.3-1.fc25.x86_64
php-pecl-zip-1.13.5-1.fc25.x86_64

Dafür das in die Konsole eingeben:

dnf install php-pecl-zip

und dann ggf. noch einen Neustart seines Webservers, wenn man PHP als Modul einsetzt, was man nicht machen sollte.

PHP-CGI verbraucht zuviel Speicher

Dieser Beitrag ist aus der Kategorie:

„Was kann da schon schief gehen“

Speicher ist billig, aber doch endlich und nicht beliebig nachrüstbar.  Es kann also Situationen geben, wo man Speicher einsparen muß, weil andere der irrigen Meinung, waren, das mit dem Speicherverbrauch  wäre kein Problem.

Aber der Reihe nach:  Was ist überhaupt das Problem ?

PHP als CGI ausgeführt, verbraucht pro Start > 400 MB Speicher fürs Nichtstun.

Beispiel:  „php-cgi -a“ startet PHP ohne irgend was zu machen.

In einer zweiten Konsole läßt man sich mit pmap anzeigen, wer in dem Prozess was an Speicher belegt:

pmap {pid of process}

Beispielausgabe ( gekürzt : Warum kommt später )

[root@xxx]# pmap 5408
5408:   php-cgi -a
0000560d00b44000   3724K r-x– php-cgi
0000560d010e6000    536K r—- php-cgi
0000560d0116c000     16K rw— php-cgi

00007fce773f8000     28K r-x– libcrypt-2.23.so
00007fce773ff000   2044K —– libcrypt-2.23.so
00007fce775fe000      4K r—- libcrypt-2.23.so
00007fce775ff000      4K rw— libcrypt-2.23.so

total           420372K

Genau, 410 MB und nicht eine Anweisung ausgeführt. 3.7 MB gehen für den PHP-Interpretercode selbst drauf, ok. 2 MB gehen alleine für die libcrypt drauf.

Und jetzt der Grund wieso die Ausgabe gekürzt ist: PHP benutzt 75 Libs => ~ 160 MB Speicherverbrauch … bei jedem Script!

Bei der Analyse ist aber aufgefallen, daß auch eine Locale eingebunden wird:

-rw-r–r– 1 root root 110562112 22. Dez 12:01 /usr/lib/locale/locale-archive
-rw-r–r– 1 root root         0 22. Dez 12:01 /usr/lib/locale/locale-archive.tmpl

Auch bekannt als 107 MB und diese Datei wird in jeden PHP Prozess geladen,  der läuft. Keine Gnade.

Locale  – was sind das ?

„Locals“ sind keine Eingeborenen, sondern nur die Informationen über jene, also Zahlensysteme, Schreibrichtung, Datumsformat, Gewichte, Längen usw. . Wer mal sehen will, welche auf seinem Linux installiert sind, gibt das ein : locale -a

Da kommen Sachen von Sprachen, wo man nicht mal sagen kann, wo die passenden Länder sind 😉

Irgendwann hat Red Hat mal entschieden, daß die einfach alle Sprachen des Planeten ausliefern, weil dann der User nicht mehr machen muß. Stimmt.

Auf einem Desktopsystem ok. Aber auf einem Server ist das nicht ok und deswegen muß das auf ein gesundes Maß gedrückt werden. Das macht man mit  : /usr/sbin/build-locale-archive -v -l „de:en:ru:jp“

„Oh… geht ja gar nicht“ ????

Doch geht, aber nur mit Trick Siebzehn aus der „Erschiesst den Trottel Ecke“.

Die obige Locale-Archiv-Datei kommt mit dem Paket „glibc-all-langpacks“ auf den Server. Damit kommt aber auch ein TEMPLATE File mit, aus dem man sich genau das Archiv selbst bauen kann, wenn man eben nicht alles haben will.

Ihr habt’s erfaßt, das wäre zu einfach gewesen 🙁

Die Templatedatei ist nämlich LEER und damit nicht zu gebrauchen. Ihr Fragt Euch jetzt : „Wie bekommt man so ein Template?“ hmm.. Tja.. aus dem Repo jedenfalls nicht und doch, bekommt man. Jetzt wird es lustig, wir kopieren das vorhandene Archiv als Template für sich selbst ! Ja, richtig, mit der Faust durchs Auge: In your Face Red Hat!

Also eingegeben:

cp locale-archive locale-archive.tmpl
/usr/sbin/build-locale-archive -v -l „de:en:ru:jp“
locale -a

und schon ist das File keine 107 MB  mehr sondern nur noch 7 MB und auch das halte ich für extrem viel Schrott für 4 Sprachen. Aber jetzt lädt das php nur noch 7 MB rein. Das macht in der Endabrechnung dann 25% weniger RAM Verbrauch.

Als nächstes muß man rausfinden, wieso die Libs jeweils 2 MB verbrennen, wenn die nur 70k groß sind. Aber das ist eine andere Geschichte aus dem |-: La-La-La-Land 😐 .