KeyHelp Community

Alexander wrote: ↑Thu 19. Jun 2025, 10:48 ignore_repeated_errors = 1

Ich habe dem Kunden vorhin 2 Installationen mit ignore_repeated_errors aktualisiert und vorher die Fehler im footer tpl fixed, das hat soweit gut geklappt, kein log file flooding.
Eine Systemweite Lösung ignore bei Bedingung (für warning, note) wäre allerdings bei dieser massiven Auswirkung schon nicht schlecht ...
Vieleicht fällt Dir ja dazu noch irgendwann etwas ein
L.G.

Man könnte es Quasi als Standard-Einstellung in der jeweiligen php.ini setzen.

Alexander wrote: ↑Thu 19. Jun 2025, 15:20 Man könnte es Quasi als Standard-Einstellung in der jeweiligen php.ini setzen.

Bei den "Problem Kunden" werde ich das vorerst so machen, ein mögliches Problem dabei sehe ich bei Fail2ban Filtern wenn es halt bei echten relvanten events (error) in den logs greift ... eine Beschränkung (limit) NUR für warning & note logging wäre wohl eine bessere Lösung.
Gab es das nicht bereits (früher vor hundert Jahren) schon mal?

ja, das war noch wohl noch vor der FPM/FCGI Ära ... ich bin ja schon ein alter Sack
sowas in der Art wäre nett: https://perishablepress.com/advanced-ph ... g-via-php/

Es muß doch irgendeine Lösung für FPM/FCGI geben ohne dass eine Disk durch exzessives PHP logging vollläuft ...

Ralph wrote: ↑Thu 19. Jun 2025, 16:48 Es muß doch irgendeine Lösung für FPM/FCGI geben ohne dass eine Disk durch exzessives PHP logging vollläuft ...

Vernünftige Software verwenden...

*SCNR*

Na ja, ein CMS was PHP 7.4 verwendet ist derzeit "noch nicht" exotisch ... die Interpreter bzw. deren configs sollten etwas ausgereifter sein ohne dass eine Disk mit PHP Logs "ohne Limit" geflutet werden kann, gleiches Problem kann auch mit neueren PHP Versionen produziert werden.
Ich würde sogar sagen dieses Problem fällt schon unter "category critical" so etwas darf nicht passieren ...
PHP haut dafür lieber neue releases nonstop wie warme Semmel raus und alte Bugs werden ständig mitgeschleppt.

Ralph wrote: ↑Fri 20. Jun 2025, 11:56 Ich würde sogar sagen dieses Problem fällt schon unter "category critical" so etwas darf nicht passieren ...
PHP haut dafür lieber neue releases nonstop wie warme Semmel raus und alte Bugs werden ständig mitgeschleppt.

Also wenn ich das Problem jetzt richtig verstanden habe, dann verhält sich doch alles korrekt. Deine Anwendung gerät (warum ist an dieser Stelle ja erst einmal egal) in einen Zustand, der eine Warning in php auslöst. Diese wird dann je nach Konfiguration abgehandelt (direkt ausgegeben und/oder geloggt oder ignoriert). Wenn deine Anwendung nun bei jedem Request mehrere solcher Warning-Zustände erzeugt und auch noch viel frequentiert ist (also anscheinend produktiv) und du warnings loggen lässt, erhälst du halt ein großes Logfile.

Wir setzen zum Beispiel das error_reporting für Produktiv-Instanzen so, dass es nur Fehler logged, auf der zugehörigen Dev-Instanz dann aber auch warnings, deprecations etc., um so etwas bei der Entwicklung gleich zu erkennen (und selbstverständlich sofort zu beheben *hust* ) aber auf dem Produktivsystem Ruhe zu haben.

Ich sehe hier wirklich kein Fehlverhalten seitens PHP oder der Konfig von Keyhelp. Oder ich hab das Problem nicht erkannt

l_fish wrote: ↑Fri 20. Jun 2025, 12:18 und selbstverständlich sofort zu beheben *hust*

Genau so handhabe ich das auch.

Nein, es ist nicht korrekt wenn PHP unlimitiert eine Disk fluten darf, das gilt für alte und für neue Anwendungen, irgendwo muß ein Limit gesetzt sein bevor ein System einfriert ... und gerade weil es sehr sehr schnell passiert.

Die Logfiles werden doch im Kundenspace abgelegt?
Sobald dessen Quota voll ist, ist Ende mit Logfile.

Oder hat der Kunde unlimitierten Webspace?

Die Logs schreibt der Webserver, die Dateien laufen alle unter www-data:www-data.

Es ist kein Keyhelp basierendes Problem, aber bei einem Vorfall (egal ob neue oder alte Anwendungen Auslöser sind), ist das Panel bzw. das komplette System von einem Einschlag massiv betroffen ...
Könnte in dem Teil wo PHP error.log in die User error.log gelangen, irgendwie eine Bedingung eingesetzt werden?

Ralph wrote: ↑Fri 20. Jun 2025, 11:56 Na ja, ein CMS was PHP 7.4 verwendet ist derzeit "noch nicht" exotisch ...

Meistens teile ich Deine Ansichten ja, aber PHP 7.4 bekommt seit Dezember 2022 keine Security Updates mehr.
Ab wann würdest Du es dann als "exotisch" bezeichnen?

24unix wrote: ↑Fri 20. Jun 2025, 20:10 Meistens teile ich Deine Ansichten ja, aber PHP 7.4 bekommt seit Dezember 2022 keine Security Updates mehr.

LTS erhält noch 7.4 security updates bis Juli 26 vermutlich weil Sury da mit drin hängt ...

Gut, dann verpacke ich das hier mal besser und komme auf den Punkt

Nehmen wir mal an ein Kunde verwendet ein aktuelles CMS und er lädt versehentlich einen veralteten Teil seines Themes oder was auch immer hoch ... das produziert dann ungewollt eine prächtige Fülle an Logs.

Deckmantel Sicherheit:
Nehmen wir mal an es kommt z.b. bei WP, einem Plugin etc. zu einem RCE Leck (kommt ja sehr selten vor aber es kommt vor ), ein Angreifer der nun gezielt die Log Files überquellen lassen möchte, braucht nur ein einfaches PHP script dem WP unterzujubeln was dann ein Log flooding produzieren könnte um damit z.b. Fail2Ban außer Gefecht zu setzen um sich danach ungestört um andere Dinge kümmern zu können ... wäre problemlos möglich oder er könnte einfach abwarten und sich freuen wenn die Kiste abgeraucht ist.

Schlusswort
es geht hierbei nicht um eine Problemlösung unter einem PHP 7.4 CMS, es geht darum ein Log file flooding zu verhindern und zwar nicht nur von alten CMS oder Scripten sondern generell!

In KeyHelp werden aber nicht die Pakete von Sury genutzt.

Ich wurde hier ansetzen:
Und das am besten im CMS (welches auch immer das ist).