FIXED: Apache 2.4.41-4

Für Euch frisch aus der Werkstatt: Apache httpd 2.4.41-4 löst das Problem „Apache httpd 2.4.41 mit defektem PIPE support

Fedora User können schon updaten

und zwar mit folgendem Befehl für FC29:

dnf -y update https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/noarch/httpd-filesystem-2.4.41-4.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/mod_ssl-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-tools-2.4.41-4.fc29.x86_64.rpm

Die Version ist jetzt erst einige Minuten alt und wurde extra für uns gebaut \o/

Die FC30 Version gibt dann hier: https://koji.fedoraproject.org/koji/buildinfo?buildID=1393459

Alle Tests sind positiv, also könnt Ihr die erst einmal bedenkenlos installieren, solange die noch nicht im Fedora Updates Repo ist. Das sollte zwar heute noch der Fall sein, aber wem das CGI-Problem jetzt schon wie ein Furunkel am Hintern klebt, der kann sich jetzt vorzeitig entlasten 😉

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.

Apache – .htaccess: No comments are allowed here

Schock in der Morgenstunde. Apache Produktionswebserver ausgefallen.

„No comments are allowed here“

Was zunächst nach einer Anpassung an die EU Datenschutz Grundverordnung klingt, ist ein harter Apachefehler, der seit 2.4.33-4 auftritt. Zum Glück ist das ein echt seltener Fehler, der durch eine Änderung des Configparsers des Webservers ausgelöst wird.

Von so einen Kommentar in einer .htaccess wird es ausgelöst :

### Hijackenden Proxys sperren ###
order deny,allow
deny from 1.1.2.4 #Webseite klaut Inhalte
### Ende Hijackenden Proxys sperren ###

und so müßte das korrekt aussehen:

### Hijackenden Proxys sperren ### 
order deny,allow 
#Webseite klaut Inhalte
deny from 1.1.2.4  
### Ende Hijackenden Proxys sperren ###

Also wenn Euch seit neustem ein 500er Fehler Eurer Webseite entgegenblickt, dann denkt an diesen Beitrag 😉

Alle Apacheprozesse gleichzeitig stracen

Der Apache Webserver kommt ja mit mehreren Methoden daher, wie er effektiv möglichst viele Anfragen gleichzeitig beantworten kann. Die alte Prefork-Methode, die nicht mit HTTP2 kompatibel ist, startet dazu einen Prozess mit wenigen Kindern und splittet neue Prozesse ab, sobald eine Anfrage reinkommt.

Ein einfaches strace -f -p [pidvonerstemhttpd] reicht völlig aus um alle Zugriffe auf den Apachen zu tracen.

Das Event-Modell

Im Eventmodell , das für HTTP2 nötig ist, klappt das nicht mehr ganz so leicht. Hier müssen tatsächlich alle laufenden Prozesse gleichzeitig getraced werden, was in dem Beispiel hier:

├─httpd─┬─httpd(apache)
│ └─4*[httpd(apache)───63*[{httpd}]]

schon sehr,sehr viel Tipparbeit wäre ( > 240 pids) . Natürlich kann man das vereinfachen, indem man ein paar kleine Shellanweisungen nutzt:

strace -f -p `pidof httpd | sed -e "s/ /,/g"`

pidof als Befehl gibt uns leerzeichensepariert alle Prozessids zurück, die zum Httpd gehören. Leider kann strace die so nicht verarbeiten, also müssen wir die Ausgabe in kommasepariert umwandeln, dies macht der SED – Befehl. Die Backticks führen die Befehlsanweisung vor dem Aufruf von strace aus, so daß das Ergebnis direkt als Argument benutzt werden kann.