KeyHelp Community

Im Prinzip wäre es für die sinnvollste möglichkeit das Remote zu nutzen oder? Also kein lokales Redis.


Macht ja eh Sinn wenn man mehrere Keyhelp Server hat sich die Datenbank von Rspamd zu teilen.

Florian wrote: ↑Tue 20. Jan 2026, 11:29 Es ist erstmal nur zum Probieren, ob das die Probleme löst, natürlich können auf diesem Weg keine anderen Anwendungen den Redis nutzen die das Passwort nicht kennen.
Desweiteren bietet Redis ja auch ne ACL Funktion. Mit der kann man sich ja auch auseinandersetzen.

Hallo Florian, das löst mit Sicherheit das Problem. Wenn ich im WordPress das olugin deaktiviert habe geht es ja auch und rpsamd füllt den redus Speicher. Aber die Lösung hilft ja eigentlich nicht so richtig, es wäre ja schön Redis schon auch für Kunden bereit zustellen. Eigentlich wäre es perfekt wenn keyhelp einen eigenen gesicherte Redis Dienst nutzt der gesichert ist mit pw.

Man kann das Plugin in der wp-config einstellen das es eine andere DB nutzt, dann geht es auch damit. Wäre aber trotzdem gut, wenn man Keyhelp wenigstens als Standart auf DB 14 oder 15 stellt, das hat bei mir noch nicht geklappt.

Kann man das irgedwo sehen ob nach der Einstellung in der config auf eine andere DB diese auch genutzt wird? (db = "15";)

Naja das sind keine praktikablen Vorgehensweisen und die nutzbarkeit hört halt auf wenn man auf dem Server nicht mehr alleine ist.
Im Normalfall nutzt man ja Keyhelp auch für Kunden und die sind mal mehr oder weniger technisch versiert oder vertrauenswürdig.

Man muss zwingend davon ausgehen das da irgendwann mist passiert wenn das nicht ordentlich separiert ist.

Florian wrote: ↑Mon 19. Jan 2026, 15:37 Alternativ bleibt noch ne weitere Redis Instanz auf einem anderen Port

Pragmatischer Ansatz:
Das Panel nutzt eine separate redis Instanz völlig alleine (auf separatem Port natürlich) und es wird OOTB eine normale redis Instanz mit eingerichtet, auf die die Anwendersoftware dann zugreifen kann.
So wären beide Datenpfade (Panel und Anwendungen) strikt voneinander isoliert und könnten nicht mehr kollidieren.

Ich hoffe das zeitnah diese Lösung mit einem separaten redis eingebaut wird. Wäre super wenn man hier dazu eine Info von offizieller Seite bekommt.

marco wrote: ↑Thu 22. Jan 2026, 21:02 Ich hoffe das zeitnah diese Lösung mit einem separaten redis eingebaut wird.

Ich kann dir versichern, daß die Dev's den Thread aktiv verfolgen.

marco wrote: ↑Thu 22. Jan 2026, 21:02 Wäre super wenn man hier dazu eine Info von offizieller Seite bekommt.

Wenn der Vorschlag in Betracht gezogen werden sollte, dann kannst du sicher davon ausgehen, daß es entsprechende Infos geben wird.

Jolinar wrote: ↑Wed 21. Jan 2026, 12:18 und es wird OOTB eine normale redis Instanz mit eingerichtet, auf die die Anwendersoftware dann zugreifen kann.

Ich frage mich, ob man das denn wirklich noch vorinstalliert haben will. Hat man zwei Kunden, z.B. jeder mit seiner Nextcloud und beide sehen "Oh supi, der Server stellt redis zur Verfügung, gleich mal einbinden, wird ja empfohlen..." und natürlich ändert keiner die redis DB Nummer in seiner Nextcloud config. Schon gibt es gleich wieder Ärger... eigentlich möchte ich so etwas Unsicheres nicht standardmäßig den Kunden verfügbar machen.

Wenn dann sollte man meiner Meinung nach wohl die redis Instanz für die Kunden auch erstmal per Default mit Passwort versehen. Dann kann Admin entscheiden, ob und wem er das verfügbar macht.

Mit KH 26.0 wird läuft Rspamd über eine separate passwortgeschützte Redis Instanz ("redis-keyhelp").

Die normale Instanz ("redis-server") bleibt weiterhin aktiv, kann aber auf Wunsch vom Admin aber auch deaktiviert werden. Diese wird seitens KeyHelp nicht mehr anderweitig verwendet.