Moin,
> Man kann dem nginx einfach sagen keinen content-length Header mehr zu senden, dann horcht der Browser oder auch curl so lange, bis der Server die Verbindung (oder im Fall von http2 ‚stream‘) terminiert.
>
> Ich denke mal, der nginx ist nur ein reverse proxy? Ich hatte das Problem mal mit backend=gzip Proxy=kein gzip. Dann verrechnet der sich irgendwo.
>
> So wie ich das sehe ist gzip für die Ressourcen nicht aktiv, daher kann ich mir das vorstellen. Die zweite Sache die ich schon mal hatte war, dass der backend-Server einen falschen contentlength Header gesendet hat und der nginx den einfach übernommen hat.Möglicherweise liegt es auch da dran..
>
Danke für deine Ideen!
Der nginx vom Backend verwendet folgende Config:
https://github.com/discourse/discourse/blob/master/config/nginx.sample.conf
Der Reverse-Proxy davor eigentlich nur:
location / {
proxy_pass http://127.0.0.1:3001;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
Versuchte Lösungsansätze, die leider keine Besserung brachten:
* gzip-Config wie in der vom Docker-Container mit analoger Anpassung für
die Assets-Location
* proxy_protocol auf 1.1 gestellt (ist aber wohl der default
* http2 aus dem Reverse-Proxy rausgenommen
-> demnach verwendet nginx wohl http2 als Default
Viele Grüße
Björn
Moin,
auf vielfachen Wunsch hin habe ich gestern eine neue Discourse-Instanz
aufgesetzt:
https://forum.ffnw.de/
Kategorien gibt es noch nicht so wirklich, Stefan und Jens sind
Mit-Admins, und neue Themen sowie Antworten sind per Mail möglich.
Viel Spass beim Testen!
bjo
Moin,
> Ich würde gerne noch Rocket.Chat (habe ich Erfahrung mit) oder Mattermost (habe ich weniger Erfahrung mit) in die Runde werfen.
>
Mattermost hatten wir schonmal und waren etwas unzufrieden, dann mal zu
Matrix gewechselt, was ja immerhin federated ist - das hat dann aber
einige Probleme mit der Datenbankgröße gehabt und diverse andere
Probleme (User lassen sich z.B. nicht löschen).
Und irgendwelche Walled-Garden-Systeme aufzuziehen finde ich persönlich
auch etwas doof, wenn das Leute auschliesst, die dann lieber mit einem
Konsolenclient connecten.
Eine Lösung wie XMPP-IRC, wo Leute sowohl mit Konsolenclient als auch
mit Smartphone-App connecten können, fände ich da doch am Besten.
Moin,
sowohl im IRC-Channel auf Freenode als auch im Ticketsystem kamen
Anfragen auf, ob wir unseren IRC-Channel nicht von Freenode wegziehen
wollen.
Falls jemand nicht mitgekriegt hat, wieso weshalb warum:
https://www.theregister.com/2021/05/27/ubuntu_freenode/
Tarek hatte vorgeschlagen, auf hackint umzuziehen - hätte den Vorteil,
dass man auch direkt per XMPP joinen kann.
Und falls Patrick Uven das liest: Mach dann mal den Freenode-Channel dicht.
VG
bjo
Hallo!
Nach den ersten Schwierigkeiten mit der L2TP Firmware hat mein eigener FF Knoten mehrere Monate scheinbar problemlos gelaufen. Scheinbar, denn mein Knoten ist eher just-for-fun und hat so gut wie nie Last. Dies hat mich dazu bewegt, das von mir betreute Campingplatz FF Netz eines Kumpels wieder aus der Münsterländer Exildomäne nach Nordwest zurückzuholen. Dazu war viel Überzeugungsarbeit beim Kumpel notwendig, da das FF Netz nach dem Umzug in deren L2TP Ramschdomäne eine Saison einfach super gelaufen hat. Die Camper waren zufrieden. Keine Beschwerden mehr seitens der Camper wegen der FastD Auslastungssituation seinerzeit in der Richtung, ob das Internet kaputt wäre...
Nun ja. Nach jetzt knapp 4 Wochen fällt mein Fazit mit der L2TP Firmware unter Lastbedingungen leider erschreckend negativ aus. Damit hatte ich durch meine eigenen positiven Erfahrungen mit der FFNW L2TP Firmware überhaupt nicht gerechnet. Aber hier bei mir verfängt sich auch höchstes mal ein Smartphone ins FF Netz oder ich mache mal bewusst einen Speedtest.
Es ist halt so, dass der als L2TP Offloader eingesetzte 841nd v10 an Lasttagen mehrmals neu startet. Der Kandidat mit den zweitmeisten reboots ist die Außenantenne, ein 741nd v4. Sie befeuert den Campingplatz, stellt aber wie die anderen Access Points in diesem Netz die Verbindung zum Freifunk über den Offloader her.
Schaut man sich das Netz an, so hat schon jedes der Geräte im Netz einen Reboot hingelegt. Die Reboothäufigkeit verringert sich schlagartig, je weniger das Gerät benutzt wird.
Leider ist es dem Kumpel auch schon aufgefallen, dass das Netz nicht so wirklich stabil nach der Umstellung läuft. Es gab also wohl schon Nutzerbeschwerden.
Was kann man da machen? Interessant ist ja, dass die Geräte genauso betroffen sind, die nicht selber eine Verbindung ins FFNW Netz aufbauen und nicht nur der Offloader.
Schaue ich mir mal die Map an und klicke durch viele Geräte, so sind ja auch auffällig viele Geräte mit geringer Laufzeit, also vermutlich reboots dabei. Das Problem scheint also auch wohl bei den 'normalen' FastD Nutzern zu bestehen.
In der L2TP Münsterland Ramschdomäne haben die betroffenen Geräte zwischen den Firmware Updates monatelang problemlos ohne Reboots gelaufen.
Ich habe mal heute beim Offloader bis zum Absturz mitgeloggt, TOP laufen lassen. Vielleicht kann jemand mit den Daten etwas anfangen? Ansonsten schreibt mir, was ich loggen soll.
Knoten Name: ffnw-Dittrich-Offloader
https://www.file-upload.net/download-13200124/841v10.7z.html
Grüße
Michael
Hi, finde den Text gut und richtig, aber entweder nur direkte Ansprache oder die dritte Person.
Ich kann mich nicht an ein root Passwort bei der Initialisierung erinnern. Also geht es wie immer über Zertifikate bzw. Schlüssel.
Kann mir aber durchaus vorstellen, dass die meisten, auch wenn sie mehrere Router haben, es nicht durchgeführt haben.
Bei den Freunden und Bekannten habe ich keinen, der mit ssh, uci, ppk etc. etwas anfangen kann geschweige denn den unterschied zwischen Lan und Wan kennt. Ist aus deren Sicht alles internet :-)
Grüße
Michael.
P.s. kann kontak(a)eutelli.de in Infrastruktur(a)eutelli.de in dem Verteiler geändert werden?
Am 27. Mai 2021, 17:29, um 17:29, Simon Kurka via Nordwest <nordwest(a)lists.ffnw.de> schrieb:
>Ich habe das mal in einen Blog-Post gegossen und freue mich über
>Reviews:
>
>https://git.ffnw.de/ffnw-website/posts/-/merge_requests/1/diffs
>
>Viele Grüße,
>Simon
>_______________________________________________
>Nordwest mailing list -- nordwest(a)lists.ffnw.de
>To unsubscribe send an email to nordwest-leave(a)lists.ffnw.de
