Bugreport: Fehlende Spalte USERS.U_REJECTED_COUNT nach Upgrade 2.19.x → 3.2.4

Umgebung

• LiveConfig-Version: 3.2.4 (Build 17979), Paket liveconfig3
• Vorherige Version: 2.19.1-release (Upgrade von 2.x auf 3.x, kein Neuinstall)
• OS: Debian
• Datenbank: MariaDB (Connector/C 3.4.9)
• Mailsystem: Postfix mit lcpolicyd als Autorisierungs-Policy-Dienst (authorized_submit_users via socketmap:unix:/var/run/lcpolicyd-lookup.sock:user)

Symptom

Nach dem Upgrade auf 3.2.4 schlägt jeder Login im LiveConfig-Panel (Web-UI, POST /liveconfig/app/login) mit folgendem Fehler fehl:

Login failed
An internal server error has occured. Please check the log file for more details.

Root Cause

Beim erfolgreichen Login versucht LiveConfig, eine Sicherheits-Benachrichtigungsmail zu versenden (z. B. "Anmeldung mit neuem Gerät"). Dieser Versand ruft /usr/sbin/sendmail auf, welches über den lcpolicyd-Socket die Absenderberechtigung prüft. Diese Prüfung schlägt fehl:

sendmail: warning: socketmap:unix:/var/run/lcpolicyd-lookup.sock:user socketmap server permanent error: Lookup error. please try again later!
sendmail: fatal: authorized_submit_users: socketmap:unix:/var/run/lcpolicyd-lookup.sock:user: table lookup problem

Der resultierende Exit-Code 75 von sendmail führt zu einer unbehandelten Exception im LiveConfig-Server-Prozess, die den gesamten Login-Request abbricht:

[EMERG] Uncaught exception: /usr/sbin/sendmail returned with exit code 75
[EMERG] METHOD: POST; URL: /liveconfig/app/login
[EMERG] Got exception: std::runtime_error

Im lcpolicyd-Log (/var/log/liveconfig/lcpolicyd.log) findet sich die eigentliche Ursache:

[ERR] no such column: U_REJECTED_COUNT

Die Spalte U_REJECTED_COUNT in der Tabelle liveconfig.USERS fehlt nach dem Upgrade komplett — offenbar wurde der entsprechende Datenbank-Migrations-Patch beim Upgrade von 2.19.x auf 3.2.4 nicht (vollständig) ausgeführt, obwohl der Log beim Start mehrere Patches auflistete (Applying database patch 3.00.00 bis 3.03.01).

Workaround (selbst angewendet, funktioniert)

ALTER TABLE liveconfig.USERS ADD COLUMN U_REJECTED_COUNT INT NOT NULL DEFAULT 0;

Anschließend systemctl restart lcpolicyd (der Dienst hatte die fehlschlagende Query offenbar zwischengespeichert/vorbereitet und musste neu starten, um die neue Spalte zu erkennen).

Nach diesem Fix funktionieren Login und Sicherheits-Benachrichtigungsmails wieder einwandfrei.

Vorschlag

Bitte den Datenbank-Migrationspfad für Upgrades von 2.19.x auf 3.x prüfen — der Patch, der U_REJECTED_COUNT (vermutlich Teil einer neuen Brute-Force-/Rate-Limiting-Funktion für Logins) anlegt, scheint bei bestehenden Installationen mit Upgrade-Historie nicht zuverlässig zu greifen.

Danke für die Aufklärung! Bestätigt: Nach dem systemctl restart lcpolicyd hat die Datei /var/lib/liveconfig/lcpolicyd.db jetzt korrekt die Spalte:

CREATE TABLE USERS ( U_ID INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, U_USER VARCHAR(255) NOT NULL,  U_LIMIT_1_INTERVAL INTEGER NOT NULL, U_LIMIT_1_LIMIT INTEGER NOT NULL,  U_LIMIT_2_INTERVAL INTEGER NOT NULL, U_LIMIT_2_LIMIT INTEGER NOT NULL,  U_LASTTS INTEGER, U_SEND_STATUS TINYINT DEFAULT 0 NOT NULL,  U_REJECTED_COUNT INTEGER DEFAULT 0 NOT NULL);

(Meine ursprüngliche Annahme, dass es sich um eine fehlende Spalte in der MySQL-Haupt-DB handelt, war falsch — ich hatte dort eine Spalte ergänzt, die keinen Effekt hatte, und habe sie wieder entfernt.)

Zeitlicher Ablauf laut Journal:

• 14:23:17 — lcpolicyd startet zum ersten Mal nach dem Upgrade (kein Fehler im Journal zu diesem Zeitpunkt sichtbar)
• 14:36:41 — erster [ERR] no such column: U_REJECTED_COUNT (offenbar der erste tatsächliche Login-Versuch nach dem Upgrade, ca. 13 Minuten nach dem Start)
• Fehler tritt danach bei jedem Login-Versuch wiederholt auf (mehrfach bis 16:24 Uhr protokolliert)
• 16:27:49 — manueller systemctl restart lcpolicyd → danach keine Fehler mehr, Spalte korrekt vorhanden

Das deutet darauf hin, dass die Migration beim allerersten Start (ausgelöst durchs Paket-Postinst) nicht korrekt durchlief, ein manueller Neustart später aber problemlos funktionierte.

Angeforderter Ausschnitt aus /var/log/apt/term.log (kompletter Log-Block für den Upgrade-Vorgang):

Log started: 2026-08-19  14:23:06
Entfernen von liveconfig (2.19.1-release) ...
Vormals nicht ausgewähltes Paket liveconfig3 wird gewählt.
Vorbereitung zum Entpacken von .../liveconfig3_3.2.4-1.17979_amd64.deb ...
Entpacken von liveconfig3 (3.2.4-1.17979) ...
liveconfig3 (3.2.4-1.17979) wird eingerichtet ...
Created symlink '/etc/systemd/system/multi-user.target.wants/lcbackup.service' → '/usr/lib/systemd/system/lcbackup.service'.
Trigger für man-db (2.13.1-1) werden verarbeitet ...
Trigger für libc-bin (2.41-12+deb13u3) werden verarbeitet ...
Log ended: 2026-08-19  14:23:19

Auffällig: Im Log wird nur der lcbackup.service-Symlink explizit erwähnt, kein Hinweis auf einen lcpolicyd-Neustart durch das Postinst-Skript selbst (der laut journalctl aber trotzdem um 14:23:17 erfolgte — vermutlich durch einen separaten systemctl restart-Aufruf im Postinst, der in diesem Log-Ausschnitt nicht mitgeschrieben wird).

Danke nochmal, insgesamt also kein LiveConfig-weiter Bug, sondern ein einmaliger Migrations-Hänger beim ersten Start nach dem Upgrade, der sich per Neustart beheben ließ.