Erstellt vor 6 Jahren

Geschlossen vor 6 Jahren

Zuletzt geändert vor 6 Jahren

#128 closed defect (fixed)

Keine Syslog-Anzeige bei großem Logfile

Erstellt von: buehmann Verantwortlicher:
Priorität: normal Meilenstein: freetz-1.0
Komponente: webinterface Version: devel
Beobachter: Product Id:
Firmware Version:

Beschreibung

http://www.ip-phone-forum.de/showthread.php?t=164701

Mein Syslog-Logfile liegt auf einem USB-Stick und kann deswegen relativ groß werden. Die maximale Logfilegröße ist bei mir auf 1 MB gesetzt. Seit einiger Zeit funktioniert die Anzeige der Logdatei über die Oberfläche nicht mehr, es wird immer eine leere Textarea angezeigt.

hab das gleiche Problem mit einer 7170; und auch schon bei einer syslog Größe von 512kb, abgelegt auf einem usb stick.

Das Problem ist, dass zur Ausgabe des Logfiles etwas ähnliches wie httpd -e "$(cat $LOGFILE)" benutzt wird und so zunächst das ganze Logfile gelesen und in ein Argument gepackt werden muss, bevor es mit der Ausgabe weitergeht. Das funktioniert nur bis zu einer gewissen Größe.

httpd -e scheint mir nur für kleinere Argumente (ein Wert eines Formulars, eine Zeile) entworfen worden zu sein. Um bei größeren Texten eine HTML-Kodierung vorzunehmen, sollten wir einen Filter benutzen (der auf einem Eingabestrom arbeitet).

Das ganze betrifft nicht nur die Syslog-Ausgabe, sondern auch alle anderen Log-Ausgaben im Webinterface.

Der beiliegende Patch führt eine Funktion html ein, die sowohl für kleine Argumente als auch für beliebig große Eingabeströme verwendet werden kann:

  echo "<input name='foo' value='$(html "$VALUE")'>"
  html < /var/log/messages
  ls -R / | html

Eine ähnliche Funktion benutze ich seit längerer Zeit im Callmonitor; dort hat sie sich bewährt.

Anhänge (2)

htmlescape.patch (72.3 KB) - hinzugefügt von buehmann vor 6 Jahren.
apos.patch (348 Byte) - hinzugefügt von buehmann vor 6 Jahren.
&#39; statt &apos;

Alle Anhänge herunterladen als: .zip

Änderungshistorie (14)

Geändert vor 6 Jahren durch buehmann

comment:1 Antwort: Geändert vor 6 Jahren durch McNetic

Das Problem ist klar; der Lösungsansatz ist auch nicht unbedingt schlecht, aber auch nicht besonders gut: Du encodest nur die Sachen, die unencoded wirklich in jedem Fall zu Problemen führen. Allerdings müssten korrekterweise auch zahllose weitere Entities encoded werden (Umlaute z.b.), was httpd -e macht, Deine Lösung jedoch nicht.

Ich habe mal einen kurzen Blick in den Busybox-Httpd geworfen, und das Problem dort ist klar: Der zu encodende String wird komplett eingelesen und in einer Variable gespeichert. Das führt wohl zwangsläufig bei einem größeren String zu einem malloc-Fehler. Wie Du schon richtig sagtest, ist diese Funktion nur für kurze Argumente gedacht; offenbar primär für URLs.

Meines Erachtens wäre eine bessere Lösung, entweder den httpd so zu patchen, daß er auch längere Argumente erlaubt (dies würde wahrscheinlich auch Eingang in zukünftige Busybox-Versionen finden, wenn man es dort einreicht), ist aber wohl auch recht aufwändig, oder man müsste ein kleines Programm schreiben, was das ganze kann und es auch speichereffizient ausführt. Letzteres ist wahrscheinlich die einfachere Lösung. Das eigentliche Encoden ist in C nämlich ein 5-Zeiler (siehe BB-Source: networking/httpd.c, Funktion encodeString).

comment:2 Geändert vor 6 Jahren durch cinereous

Ich denke, das PAtchen des BB-httpd ist wohl eher die falsche Wahl, zumindest das PAtchen eben genau dieser Option. Allerdings wäre eine weitere Option für das bearbeiten von grossen Datenmengen wol ok, die dann eben den Kram als Stream betrachtet.

Allerdings finde ich die Sache mit dem "sed" eigentlich für unsere Fälle ausreichend, allerdings sollte man dort

  1. Optimieren
    2. Erweitern der Entities

oder aber - mein eigentlich Favorit - einen kleinen c-Mehrzeiler schreiben, der ebne genau das macht, und zwar schnell und effektiv.

c.

comment:3 Geändert vor 6 Jahren durch McNetic

Ja, Du hast recht, genau diese Option zu patchen wäre wohl nicht so sinnvoll. Ein C-Programm ist aber meines Erachtens schon die beste Möglichkeit, da dort einfach der character code als encoding verwendet werden kann, und so keine lange Liste mit Entities o.ä. erstellt werden muss. Wenn sich bis Donnerstag niemand findet, der das gerne machen möchte, kann ich mich darum kümmern (bis dahin hab ich wahrscheinlich leider keine Zeit).

comment:4 als Antwort auf: ↑ 1 ; Antwort: Geändert vor 6 Jahren durch buehmann

Replying to McNetic:

Du encodest nur die Sachen, die unencoded wirklich in jedem Fall zu Problemen führen. Allerdings müssten korrekterweise auch zahllose weitere Entities encoded werden (Umlaute z.b.), was httpd -e macht, Deine Lösung jedoch nicht.

httpd wählt der einfachen Implementierung (in C) wegen einen recht rigorosen Ansatz (siehe auch die Kommentare dort) und kodiert fast alles mit numerischen Zeichenreferenzen. Wirklich nötig ist das aber IIRC nicht; dein Beispiel mit den Umlauten stimmt so zum Beispiel nicht: Natürlich dürfen Umlaute auch als "äöü" im Quelltext vorkommen (vorausgesetzt, das Charset der Seite ist am Anfang der Seite richtig eingestellt).

Aber natürlich können wir gerne eine C-Implementierung von html() (oder des Streamingteils daraus) machen, die sicherheitshalber noch mehr Zeichen umkodiert.

@cinerous: Was meinst in Bezug auf die sed-Lösung mit "Optimieren"? Viel Raum für Optimierung ist in dem kleinen Skript nicht mehr, oder?

comment:5 Antwort: Geändert vor 6 Jahren durch buehmann

Noch eine Bemerkung am Rande: Beim Nachlesen zu HTML-Entities ist mir aufgefallen, dass &apos; in HTML nicht definiert ist, erst in XML und damit in XHTML. In meinem sed-Ansatz müsste man also &#39; stattdessen nehmen.

comment:6 als Antwort auf: ↑ 4 ; Antwort: Geändert vor 6 Jahren durch McNetic

Replying to buehmann:

Umlauten stimmt so zum Beispiel nicht: Natürlich dürfen Umlaute auch als "äöü" im Quelltext vorkommen (vorausgesetzt, das Charset der Seite ist am Anfang der Seite richtig eingestellt).

Da hast Du natürlich wieder Recht; eigentlich ist das also eine grundsätzlichere Frage. Wir sollten entscheiden, ob wir

a) dafür sorgen, daß alle Sonderzeichen, die nicht im 7-Bit-Ascii enthalten sind, korrekt encoded werden (da ist beim automatischen Codieren die numerische Codierung wohl die sinnvollste weil einfachste), oder

b) dafür sorgen, daß jede HTML-Seite korrekt den Zeichensatz angibt und können dann ISO-8859-1 benutzen. In dem Fall reicht es aus, die Handvoll von Zeichen, die in HTML eine Sonderrolle spielen, zu encoden.

comment:7 als Antwort auf: ↑ 6 ; Antwort: Geändert vor 6 Jahren durch buehmann

Im Fall a) müssten wir bei Wahl der numerischen Kodierung immer noch ISO-8859-1 (oder etwas anderes) in der HTML-Seite angeben, oder nicht? Und für nicht-numerische Kodierung müsste man wissen, dass jede Eingabe für die Kodierungsfunktion in ISO-8859-1 kodiert ist.

Ich fände Ansatz b) deswegen am besten umzusetzen.

comment:8 als Antwort auf: ↑ 7 ; Antwort: Geändert vor 6 Jahren durch McNetic

Replying to buehmann:

Im Fall a) müssten wir bei Wahl der numerischen Kodierung immer noch ISO-8859-1 (oder etwas anderes) in der HTML-Seite angeben, oder nicht? Und für nicht-numerische Kodierung müsste man wissen, dass jede Eingabe für die Kodierungsfunktion in ISO-8859-1 kodiert ist.

Jein :-). Die numerische Codierung erfolgt gemäß ISO10646. Das ist also bei jedem Zeichensatz gleich. Trotzdem wäre es natürlich in jedem Fall besser, den korrekten Zeichensatz anzugeben. Ich bin also auf jeden Fall auch für Variante b).

comment:9 als Antwort auf: ↑ 8 Geändert vor 6 Jahren durch buehmann

Ja, das habe ich auch gerade noch einmal nachgelesen. Danke! Interessanterweise bedeutet das, dass busybox's 'httpd -e' annimmt, dass jede zu kodierende Eingabe in Latin-1 vorliegt (nur bei Latin-1 stimmen ja die Byte-Werte mit den Zeichencodes der entsprechenden (ersten 256) Unicode-Zeichen überein).

Also Variante b), und falls wir 'httpd -e' weiterverwenden wollen (zumindest für kurze Zeichenfolgen), dann zwingend ISO-8859-1 als Standardkodierung in Freetz (für Webseiten, aber auch Werte in Config-Dateien, Skripten, etc.).

comment:10 Geändert vor 6 Jahren durch cinereous

  • Lösung auf fixed gesetzt
  • Status von new nach closed geändert

Ich hab den mal in r2162 vorerst implementiert, denn die Fritz nutzt eh nur Latin-1, so wie ich das sehe. Da der PAtch ncith merh passend war, habe ich manuell nachgeholfen. Ich hoffe, ich hab nichts vergessen oder zu viel mitgenommen. Ansonsten bitte hier nochmal öffnen.

Wobei ich allerdings wenig verstehen kann, wie man _so_ grosse logfiles überhaupt über den Browser betrachten möchte. Da bevorzuge ich doch die Kommandozeilenoptionen.

dennoch: Danke buehmann :)

comment:11 als Antwort auf: ↑ 5 Geändert vor 6 Jahren durch buehmann

Danke für die Übernahme der Funktion. Wie ich sehe, hatte ich vergessen, meine Bemerkung von oben zu &apos; (gibt's nicht in HTML) in den Patch einzuarbeiten; sorry. Es wäre toll, wenn du die kleine Änderung noch nachschieben könntest.

Übrigens hat html auch bei überschaubaren Ausgaben einen Vorteil, vor allem wenn diese relativ langsam produziert werden: Inkrementelle Anzeige (modulo Pufferung) statt langer Wartezeit, nach der alles auf einen Schlag kommt. (Dabei fällt mir auf, dass z.B. in save.cgi die Ausgabe gar nicht geschützt wird; ich schaue mal, ob das noch irgendwo zutrifft und mache ggf. ein neues Ticket auf.)

Geändert vor 6 Jahren durch buehmann

&#39; statt &apos;

comment:12 Geändert vor 6 Jahren durch cinereous

Checked in in r2163

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.