fail2ban-Darstellung Ladezeit

[Ralph]

Eventl. die IP Adressen nicht direkt bei Klick auf Fail2ban abfragen ... nur die Jails (count) und das Textfeld für eine IP Suche.
Von der Übersicht mit den Jails dann bei Klick auf die jeweils enthaltenen IP Adressen (eventl. extra Seite) routen und dort erst abfragen.

[24unix]

Eventl. die IP Adressen nicht direkt bei Klick auf Fail2ban abfragen ... nur die Jails (count) und das Textfeld für eine IP Suche.
Von der Übersicht mit den Jails dann bei Klick auf die jeweils enthaltenen IP Adressen (eventl. extra Seite) routen und dort erst abfragen.

Dann müsste jemand mal das mit einem jail ausprobieren, was lange dauert:

Code: Select all

❯ fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:	11
|  |- Total failed:	296003
|  `- Journal matches:	_SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned:	1
   |- Total banned:	17190
   `- Banned IP list:	80.94.93.119

[Tobi]

Ich wollte es nicht schreiben müssen:
„Nein, ich möchte keine 40 Sekunden einen Spinner angezeigt bekommen! Vielen Dank!“

[blickgerecht]

ich möchte keine 40 Sekunden einen Spinner angezeigt bekommen

Zumal das ja evtl. auch in einem 500er enden würde, weil deine Liste ja auch einiges mehr an Einträgen hat.

[24unix]

ich möchte keine 40 Sekunden einen Spinner angezeigt bekommen

Zumal das ja evtl. auch in einem 500er enden würde, weil deine Liste ja auch einiges mehr an Einträgen hat.

Auf einen 500er kann man ja entsprechend reagieren.

Evtl. ist der Cache keine schlechte Idee.

[Alexander]

Wenn der Ursprungsbefehl, von dem ich die Daten sammele schon so lange dauert, gibt mir das leider wenig Möglichkeiten zumindest die Ladezeit zu optimieren (*). An irgendeiner Stelle muss es dann zumindest einmal laden. Via Paginierung kann ich die fail2ban Daten meines Wissens nicht abfragen.

Habe gerade bei meinem Server geschaut mit mit 10500 gebannten IPs, der läd die Seite in maximal 1 Sekunde.

Vielleicht muss mir Tobi mal Zugriff zu seinem Server mit den 200.000 gebannten IPs geben, damit ich es selbst mal sehen kann.


(* Challenge accepted, ich denke ich bekomme die Ladezeit trotzdem um ein gutes Stück gedrückt, dann noch Asynchron laden und dann sollte es auch mit 200k noch bedienbar bleiben)

[Tobi]

Meine Idee wäre per Cron die fail2ban-client Ausgabe in eine MariaDB Tabelle zu schreiben.

Dann kann die GUI die Datenbank befragen.

Zugriff zum Server ist kein Problem.
Sag einfach Bescheid ob, wann und wie.

[Alexander]

Da blutet mein Effizienzherz leider sehr , wenn man bedenkt das permanent in diese Datenbank geschrieben wird ohne, das der Nutzer diese Daten auch tatsächlich abruft.
Ich würde so ab kommende Woche vielleicht mal einen Blick drauf werfen wollen, sage dir dann Bescheid - Dankeschön!

[Tobi]

[24unix]

Da blutet mein Effizienzherz leider sehr , wenn man bedenkt das permanent in diese Datenbank geschrieben wird ohne, das der Nutzer diese Daten auch tatsächlich abruft.

Wie wäre es mit redis?

[Alexander]

Auch da muss ja vorher jedes mal ein Prozess laufen (immer wenn der Cache gefüllt wird) der scheinbar bei einigen mit 200k Einträgen 30-40 sek läuft.
Dann möchte man ja gern recht aktuelle Werte haben, also alle 5 - 10 min, den Cache aktualisieren.

Ich schau zum Beispiel bei meinem Server einmal alle paar Monate in die Fail2Ban Liste rein. Wenn ich nun bedenke, das so viel Rechenzeit (pro Tag / alle 5 Min Cache füllen * 30 Sek Ausführzeit = 144 Min verschwendete Rechenzeit pro Tag) verschwendet würde um einen Cache zu füllen, den ich mir nur in den seltensten Fällen anschaue, ne tut mir leid, das kann ich nicht umsetzen .

Es wird sich eine andere Lösung finden...

[Tobi]

Es wird sich eine andere Lösung finden...

Ich ziehe mein Posting von gestern zurück.

Intern verwendet fail2ban bereits sqlite.
Speicherort: /var/lib/fail2ban/fail2ban.sqlite3

Na da geht doch was, oder?
https://www.php.net/manual/en/book.sqlite3.php


Du machst das schon