Konflikt mit Socket für Redis-Server nach Upgrade auf Keyhelp 26

[l_fish]

Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
(z.B. Ja / Nein (Probleme ohne KeyHelp-Bezug gehören ins Offtopic-Forum))

Ja.

Server-Betriebssystem + Version
(z.B. Ubuntu 24.04)

Ubuntu 24.04.4

Eingesetzte Server-Virtualisierung-Technologie
(z.B. keine, OpenVZ, KVM, XEN, etc.)

KVM (Proxmox)

KeyHelp-Version + Build-Nummer
(z.B. 26.0 - Build 3582)

26.0 (Build 3618)

Problembeschreibung / Fehlermeldungen

Konflikt mit Socket für Redis-Server nach Upgrade auf Keyhelp 26:

Nextcloud nutzte bei uns bisher den default Redis via socket /run/redis/redis-server.sock. Nach dem Upgrade gab es dann Fehler in Nextcloud ("RedisException NOAUTH Authentication required."). Vermutung: /run/redis/redis-server.sock wird nun von der zusätzlichen Redis-Instanz (die für rspamd) genutzt, welche ja passwortgeschützt ist.
Das deckt sich auch mit den Konfigurationsdateien. /etc/redis/redis.conf definiert unixsocket /run/redis/redis-server.sock, /etc/redis/redis-keyhelp.conf inkludiert die default config (include /etc/redis/redis.conf), überschreibt aber den unixsocket Parameter nicht.

Erwartetes Ergebnis

Die zusätzliche Instanz für Rspamd nutzt einen eigenen Socket.

Tatsächliches Ergebnis

Die zusätzliche Instanz für Rspamd nutzt den Socket des bisherigen allgemeinen Redis-Servers.

Schritte zur Reproduktion

Software, (z.B. Nextcloud) die den bisherigen default Redisserver per Socket nutzt, muss sich nach dem Upgrade authentifizieren, da sie nun den rspamd-redis über den Socket erreicht. Stellt man Nextcloud auf TCP um (127.0.0.1:6379) funktioniert es wieder.

Zusätzliche Informationen
(z.B. kürzlich durchgeführte Änderungen am Server, Auszüge aus Protokolldateien (/var/log/*, /var/log/keyhelp/php-error.log, etc.))

Keine.

.

[Eule]

Server-Betriebssystem + Version
Debian 12

Eingesetzte Server-Virtualisierung-Technologie
KVM (Proxmox)

KeyHelp-Version + Build-Nummer
26.0 (Build 3618)

Der gleiche Fehler tritt auch bei uns auf.
Ich kann bestätigen, dass die Umstellung auf TCP (127.0.0.1:6379) das Problem behebt.
Auch ein Neustart von Redis hat den Fehler behoben, er kommt jedoch wieder.
Wieso der Socket falsch bindet konnte ich bisher nicht nachvollziehen.
Der redis-keyhelp wird scheinbar jede Minute neu gestartet und krallt sich den Socket.
Die Datenbank des redis-server hält immer noch die alten Daten von RSpamd. Hier sollte ein Cleanup erfolgen.

Grüße Andreas

[Tobi]

Follow up:
viewtopic.php?t=14441

[l_fish]

Da mein Bug-Report viewtopic.php?t=14440 geschlossen wurde, schreibe ich hier mal weiter. Meiner Meinung nach sind das zwei unterschiedliche Probleme. In diesem Thread hier geht es darum, dass die Redis-DB für rspamd zu viele DBs enthält, weil auf der Standard-Redis bereits mehr als eine angelegt / genutzt wurden.

In meinem Thread ging es darum, dass sich die beiden Redis-Instanzen denselben Socket-Pfad teilen, was zu undefiniertem Verhalten führt. Das Problem ist also noch nicht gelöst.


ADMIN-EDIT: Keine Ahnung warum der Beitrag geschlossen wurde, er ist nun aber wieder frei .

[Tobi]

Da hatte ich das Problem wohl falsch eingeschätzt.