Richtige Apache-Einstellung bei "500 Internal Server Error"?

Server Auth-Extern
1

Hallo.
Wir setzen auf einem Webserver .htaccess-Files ein, damit sich Lehrer auth. müssen. Das funktioniert mit unserer Produktivumgebung (weiterhin lmn v6) auch, jedoch taucht regelmäßig ein Fehler beim Zugriff auf die die Seite auf:

Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Im apache-Log finde ich dann nur:

[Mon Apr 20 10:25:46.988346 2020] [reqtimeout:info] [pid 4953] [client 94.3x.xxx.xxx:58682] AH01382: Request header read timeout
[Mon Apr 20 10:26:46.878078 2020] [reqtimeout:info] [pid 7601] [client 94.31.xxx.xxx:58687] AH01382: Request header read timeout
[Mon Apr 20 10:27:39.690044 2020] [reqtimeout:info] [pid 7825] [client 94.31.xx.x:55364] AH01382: Request header read timeout
usw.

Ich habe natürlich schon gesucht, was das sein kann und bin auf das Modul mod_reqtimeout gestoßen. Da habe ich auch bereits die Werte hochgedreht, doch der Fehler tauch weiterhin auf. Es ist überhaupt nicht vorhersagbar, wann es auftritt – jetzt war tagelang Ruhe, so dass ich schon dachte, dass die Ursache gefunden sei. Aber heute Morgen war’s dann wieder soweit …
Wenn man den „Reload-Button (oder F5)“ klickt, erscheint die Seite dann ganz normal. Es muss also damit zusammenhängen, dass der LDAP-Server zur Auth. nicht schnell genug gefunden wird … wie kann ich da was drehen?

Kennt jemand das Problem und noch besser: Die Lösung, wie man’s abstellt?
Schöne Grüße,
Michael

2

Das fragliche Modul betrifft die Kommunikation aus Richtung des Clients (also des Browsers). Es verhindert DOS Attacken.

Wenn du solche Timeouts ( " [reqtimeout:info] [p…") siehst, hat das Modul zugeschlagen, weil der Client nicht schnell genug die Anfrage geschickt hat.

Du suchst also vermutlich in die falsche Richtung, das LDAP ist noch garnicht dran.

Ich will nicht wieder unken, aber ich finde, das stinkt nach einem Netzwerkproblem :wink:

Ich würde das Modul einmal herausnehmen (a2dismod reqtimeout) und schauen, was passiert. Wenn meine Vermutung stimmt, sind dann ein paar Requests eben extrem langsam (Antwortzeiten im access-log anschauen).

3

Hallo.
Ich bin jetzt zumindest einen Schritt weiter – und zwar:

Unser Webserver (apache 2.4.29-1ubuntu4.13 mit NC 18.0.2 auf Ubuntu 18.04 VM) macht große Probleme mit dem Upload großer Dateien. Ich habe mittlerweile herausgefunden, dass es ganz offensichtlich an dem Modul mod_reqtimeout liegt.
Wenn ich unter /etc/apache2/mods-enabled/reqtimeout.conf einen Eintrag wie diesen vornehme:
RequestReadTimeout header=20-40,minrate=250 body=10-30,minrate=250
kann ich mit Nextcloud keine größeren Files mehr hochladen. In der nextcloud.log Datei erscheint dann sowas wie:

"message":{"Exception":"Sabre\\DAV\\Exception\\BadRequest",
"Message":"Expected filesize of 40799522 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 36667392 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side."

Deaktiviere ich hingegegen das Modul mit den Einträgen
RequestReadTimeout header=0 body=0 funktioniert der Upload der Dateien wieder. Dann aber gibt es ein anderes Problem: Auf dem gleichen Server gibt es ein paar Verzeichnisse, die gegen einen LDAP-Server mit einer .htaccess Datei auth.
Wenn nun der Eintrag auf 0 (disabled) steht, erscheint auf dieser Seite regelmäßig:
500 -- internal server error.
In den apache2-error.logs finde ich dann:

[Wed Apr 22 21:35:09.381101 2020] [reqtimeout:info] [pid 22381] [client 94.xx.xx.xx:65168] AH01382: Request header read timeout

Mit anderen Worten: Für das .htaccess muss das modul aktiviert sein – für Nextcloud darf es aber nicht aktiviert werden. Das kann doch nicht sein, dass man nicht beides auf einem Server laufen lassen kann? Wie kann man das lösen? Es nervt wirklich extrem…

4

Das disabled das Modul nicht, es setzt nur andere Timeouts (nämlich keine)…

Wie verhält es sich, wenn du es tatsächlich disablst?

5

Hm – die Idee stammte von hier:
https://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html
→ Disable module for a vhost :
handshake=0 header=0 body=0
This disables mod_reqtimeout completely (note that handshake=0 is the default already and could be omitted).

6

Reden wir über einen Apachen mit mehreren VHosts oder über mehrere Apachen?

Mein Tipp ist, das Modul wirklich zu disablen (wie oben geschrieben) auf allen Apache-Instanzen.

Das ist nur ein Test, die Ursache liegt sicherlich woanders, denn das Modul zeigt lediglich ein Symptom.

7

Dieser Apache steht in der DMZ und dort läuft für uns die nextcloud – aber da ist auch collabora office mit drauf. also ein vhost mehr. Alles wird auf https umgebogen und ein gültiges ssl-Zert gibt es auch…

Die zusätzlichen Verzeichnisse, für die man sich mit .htaccess authentifizieren muss, liegen auch auf diesem einen Apachen.

8

wenn ich das tue, erhalte ich seltsamerweise IMMER die 500 -- internal server error. Im Apache-error.log steht dann:

[Thu Apr 23 12:12:58.663608 2020] [authnz_ldap:info] [pid 19669] [client 89.xxx.xxx.xxx:46830] AH01695: auth_ldap authenticate: user <mein-login> authentication failed; URI /videos/ [LDAP: ldap_simple_bind() failed][Can't contact LDAP server]

Also läuft es scheinbar doch drauf hinaus, dass der ldap-server nicht schnell genug antwortet?? Wenn ich es mit `ldapsearch’ versuche, kommt die Antwort logischerweise sofort…
Der Weg der Anfrage ist: VM in DMZ → Anfrage über IPFire → LMN-Server (und zurück)

– sorry, war zu schnell beurteilt: Die Seite lag scheinbar noch im Cache. Jetzt kommt sie … ich teste mal kurz den Upload

Beides hat im Moment funktioniert. Ich lasse das Modul vorerst mal ausgeschaltet und beobachte das. Klar – besser ist mit und ich finde das Szenario „Slowloris Attacke“ echt abgefahren …

9

tja … und da ist er wieder:
500 – internal server error

Das Problem besteht leider weiterin. :roll_eyes:

10

Nein, das LDAP ist nach hinten. der Timeout nach vorn. Das kann nichts miteinander zu tun haben. Der Timeout kann, wenn du das Modul wirklich abgeschaltet hast so nicht mehr kommen. Es könnte natürlich sein, dass der 500er nichts mit der Logzeile zu tun hat…

Nun ist die Frage: was steht im Log? Die alte Logzeile war ja von dem Modul. Wenn du das Modul nun abgeschaltet hast, kann die Logzeile nicht mehr kommen. Was aber kommt dann?

Und: Was steht im Access-Log, besonders die Zugriffszeit.

11 
[Thu Apr 23 12:12:58.663608 2020] [authnz_ldap:info] [pid 19669] [client 89.xxx.xxx.xxx:46830] AH01695: auth_ldap authenticate: user <mein-login> authentication failed; URI /videos/ [LDAP: ldap_simple_bind() failed][Can't contact LDAP server]

kommt aber nicht vom timeout-modul, oder? Es stand vorhin drin aber kommt eben nicht oft und schon gar nicht voraussagbar.
Beim Reload (F5) kommt die Seite dann manchmal sofort aber manchmal auch erst im 3. oder 4. Anlauf …

In der access.log sehe ich nichts verdächtiges. … um 12 Uhr 12 haben 5 Personen gerade irgendwas gemacht … sonst steht da nichts wildes…
Ich lasse es nun erstmal so und schaue, wie es läuft.

Die Kollegen wissen, dass sie die Seite notfalls mit „Reload“ neu laden müssen. Elegant ist es aber nicht …

12

Also sehen wir 2 Probleme: Der Client stellt seine Anfragen nicht schnell genug (aus Sicht des Servers) und der LDAP antwortet dem Apache nicht schnell genug (auch aus Sicht des Servers).

Beides könnte passieren, wenn auf der Leitung Pakete verloren gehen. Das zu verfolgen ist … hm. Schwierig. Du könntest damit beginnen einen Flood-ping zu machen (ping -f 192.10.0.0.1) und zu schauen ob das Fehler zeigt (es sollte maximal ein Punkt ausgegeben werden). Die große Investigativ-Kanone ist dann Smokeping, der genau sowas zeigt.

Ursache sind meist billige Switches, kaputte Kabel, elektromagnetische Anomalien auf der WLAN-Strecke, Nebel im Glasfaser :wink: Du siehst, wir kommen in esoterische Bereiche.

13

Ja, ich sehe schon … wenn es zu exotisch wird, lasse ich es lieber so und verweise auf: „F5 drücken!“

der dürfte nichts bringen, da die Anfragen ja zunächst zur Firewall gehen und von da aus weitergeleitet werden an den Server. Es sind aber alle drei VMs auf ein und demselben Hypervisor. Untereiander emuliert Proxmox meines Wissens mindestens 10GBit NICs – so dass der Austausch des pings untereinder vermutlich nicht das Problem ist?

14

Hallo Michael,

Ja, ich sehe schon … wenn es zu exotisch wird, lasse ich es lieber so
und verweise auf: „F5 drücken!“

… bis es einem richtig in den Hintern kneift.

Ich hab das jetzt nicht alles komplett verfolgt lese aber: nextcloud und
gleichzeitig LDAP per htaccess.

Das hab ich auch seit langem am Start (colabora auf gleichem server in
docker).
Ich hab noch nciht einmal einen timeout gehabt und die NC wurde vor 4
Wochen massivst benutzt.

NC ist ein vhost auf dem gleichen kvm host auf dem auch OPNsense und
lmn7 laufen (LDAP Ziel).

LG

Holger

15

Hier auch… Daran liegt es wie gesagt nicht.
Nur, dass es noch der IPFire ist…

16

Wie sieht es mit der Speicherauslastung aus? Wie ist swap konfiguriert? Fährt da was am Limit?

Beim Fischen im Dunkeln hängt für’s Netzwerk auch immer MTU am Haken aber dann hättet ihr wohl mehr Probleme - das führt zu sporadischen full-stops.

17

das ist überreichlich dimensioniert. und die NC ist derzeit auch nur für Kollegen freigegeben, so dass sich da ca 100 Leute tummeln könnten; aber nie gleichzeitig.
ich denke weiterhin, dass es eine doofe einstellung auf dem apache ist … und kein grundsätzliches problem. das taucht wirklich NUR beim zugriff auf diese seiten mit .htaccess auf …

18

Das komische ist ja, dass da zwei Probleme zu sein scheinen, eins von vorn (der Client stellt seine Anfrage nicht schnell genug), eins vor hinten (der LDAP beantwortet die Anfrage nicht). Beide scheinen mit dem Netzwerk zu tun zu haben.

Du hast noch nicht gesagt, wieviel Speicher da ist und ob geswapped wird.

19

VM hat 16 GB RAM und 4 Cores.
ich denke nicht, dass die swappen muss.
Unter Nextcloud -> Einstellungen -> System ist alles im grünen Bereich.

20

tut sie es denn? Das kannst du ja mal schauen. 16GB scheint mit recht knapp bemessen.