Beiträge von marinal

Zitat von clickpress

Das Problem mit leeren Postfächern nach einem Upgrade von Bookworm nach Trixie haben wir hier auch.

Was auch aufgefallen ist, das liveconfig --diag sagt:

Code

[CRIT] LC.mutex: forcing unlock of mutex 'popimap.detect' 
Error running LC.popimap.detect(): /usr/lib/liveconfig/lua/dovecot.lua:150: attempt to call field 'exec' (a nil value)

dovecot.lua wurde unserseits nicht angepasst. Habt ihr eine Idee?

Auch ich habe die Problemmeldung in der Log-Datei. Meine Dovecot-Config-Datei hat die Version 2.4.0 und der in Zeile 150 abgefragte Wert ist bei mir nicht vorhanden, da es schon die neue Syntax ist.

kk

"man grep" bei Debian sagt jedoch folgendes aus:

Zitat

EXIT STATUS

Normally the exit status is 0 if a line is selected, 1 if no lines were selected, and 2 if an error occurred. However, if the -q or --quiet or --silent is used and a line is

selected, the exit status is 0 even if an error occurred.

Vielleicht wäre hier eine Option mit "| wc -l" arbeiten, also folgendermaßen:
grep '^mail_plugins = quota' /etc/dovecot/dovecot.conf | wc -l

Ansonsten funktioniert aber dovecot, wie es soll.

kk: Gibt es eigentlich Ideen, wie das Autoresponder-Feature mit ManageSieve zusammen funktionieren könnte? Denn, so wie ich es verstehe, überschreibt das Autoresponder-Feature jede Art von ManageSieve-Konfiguration.

Zitat von kk

Hier gab es tatsächlich (leider) auch eine inkompatible Änderung mit Dovecot 2.4. Vielen Dank für den Hinweis!

Mit LiveConfig 2.18.8 wird die Konfiguration entsprechend aktualisiert.

Antwort zu RE: Debian Trixie

Ich habe heute unter Liveconfig 2 auf trixie upgedatet und der Fehler ist weiterhin existent.

Oder besser sollte ich sagen - vorhandene "dovecot.sieve" werden nicht zu ".dovecot.sieve" umgeschrieben.

Lieber Armin,

hast Du Dir schon mal die Fehlermeldung durchgelesen? Und hast Du Dir schon mal Zeile 128 in der Datei '/etc/proftpd/modules.conf' angesehen?

Wenn Du nicht weisst, wie man sich eine Datei ansieht bzw. wie man Zeile 128 findet, dann nimm bitte Liveconfig nur für den privaten Gebrauch.

Ansonsten steht dort:

7a8,15

Die beiden Module, die Du danach lädst, werden bereits in Zeile 22 und 23 geladen. Lösch bitte alles nach Zeile 126.

Es hat normal immer einen Grund, wenn ein Maintainer schreibt. "# keep this module the last one"

Viele Grüße

Alexander

Mit dem Update auf 2.18.8 funktioniert wieder alles.

kk: Schade, dass es so überhaupt keinen Kommentar vom Seiten Keppler IT gab. So viele Posts sind es aktuell nicht im Forum.

darkstar: Wenn Du nach dem manuellen Setzen das Passwort für den Benutzer in Liveconfig änderst, ändert dann Liveconfig wiederum das Passwort in der Shadow?

Ich verstehe, was Du schreibst ... aber wo sollte die Information mit der Kleinschreibung herkommen? Sämtliche Informationen, aus der Datenbank beinhalten den Nutzernamen in Großbuchstaben. Sämtliches Vorhandensein in Dateien auf Dateisystemebene ist in Großbuchstaben.

Wenn dem so wäre, müsste Liveconfig einen Befehl "tolowercase" im Code beinhalten. Das kann ich mir nicht vorstellen.

kk: Gab es hier Modifikationen? Bei uns gibt es diverse Reseller, die System-Benutzer mit Großbuchstaben haben. Bei uns gibt es aber auch diverse Systembenutzer mit keinem Passwort in der shadow, obwohl FTP erlaubt ist.

Laut MySQL-Datenbank die Großschreibung. Mich hat auch die Kleinschreibung gewundert. Da die DB Datenbank aber den Benutzer immer in Großschreibung hat, sehe ich hier eher ein Logging-Thema von Liveconfig.

Hallo zusammen,

bei uns läuft "liveconfig --diag":

Running OS diagnostics... (LiveConfig 2.18.7-release)

[...]

Checking for ftp server software:

- Found 'proftpd' FTP server

Version: '1.3.8'

Package version: '1.3.8+dfsg-4+deb12u4'

Bei einem unserer Reseller kann der Kunde sein FTP-Passwort für den Haupt-Benutzer nicht ändern. Der Änderndialog wird mit Erfolg abgeschlossen, die Logs zeigen auch die Verarbeitung, aber die "/etc/shadow" ändert sich nicht.

Zitat

/var/log/liveconfig/liveconfig.log:

[2025/10/21 22:50:04.153129] [1711|1711] Pushing LCCP job into queue: 'LC.web.updateAccount'

[2025/10/21 22:50:04.153263] [1711|1716] Handling LCCP command 'LC.web.updateAccount'

[2025/10/21 22:50:04.153381] [1711|1716] [LUA] Updating password for user 'wv1071'

[2025/10/21 22:50:04.168130] [1711|1716] LCCP command 'LC.web.updateAccount' finished.

Zitat

/etc/shadow:

WV107120321:0:99999:7:::

Zitat

Mysql-Datenbank liveconfig:

Tabelle: ACCOUNTS : AC_STATUS: 5

Tabelle: HOSTINGCONTRACTS : HC_LOCKED: 162

Das Ausrufezeichen anstelle des vercshlüsselten Passworts bedeutet, dass sich der Benutzer nicht einloggen kann. Aber warum? Der Passwort-Change sollte doch angestoßen werden. Bei anderen System-Benutzern funktioniert das ohne Probleme.

Hat jemand Hinweise? Der Vertrag ist aktiv und der Liveconfig-Benutzer ist auch aktiv.

Vielen Dank im Voraus!

Ich habe jetzt doch nach mehr als 1 Stunde das Problem gelöst. Es gab noch Legacy-Benutzerrechte auf den Ordnern unter /var/lib/spamassassin (debian-spamd) und damit konnte es nicht gelesen werden.

Trotzdem bleibt für mich die Frage ... sollte man bei gewhitelisteten Sendern nicht komplett die Spamprüfung umgehen?

Hast Du mal bei dem Server, der Mail macht, die Postfix-Konfiguration geändert und neu gespeichert? Ich denke, dann wird auch der Spamassassin in /etc/default neu geschrieben.

Hallo,

heute habe ich bemerkt, dass Einträge unter Spamfilter --> Ausnahmen --> Whitelist nicht verarbeitet werden.

Bei Veränderung der Einträge wird zwar beim Mailserver ein Event getriggert, die Datei sender_local bleibt jedoch unverändert.

Die main.cf sieht im relevanten Bereich so aus:

smtpd_recipient_restrictions =
    reject_unknown_recipient_domain,
    check_recipient_access hash:/etc/postfix/recipient_access,
    check_policy_service unix:private/lcpolicyd,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_sender_access hash:/etc/postfix/sender_local,
    check_recipient_access hash:/etc/postfix/greylist_addrs

Die Berechtigungen auf die sender.local lautet:

Zitat

131608 0 -rw-r----- 1 root postfix 0 27. Jul 18:09 /etc/postfix/sender_local

132788 8 -rw-r----- 1 root postfix 12288 27. Jul 18:09 /etc/postfix/sender_local.db

Hat jemand eine Idee, woran es hakt? Bzw. haben andere auch das Phänomen?

Liveconfig-Version 2.18.2-release

Ich habe die Einträge im Spamassassin gefunden unter "/var/lib/spamassassin". Sollte ein Whitelisten nicht komplett den Spamassassin umgehen? Oder habe ich hier gerade einen Gedankenfehler?

Vielen Dank im Voraus.

Hallo zusammen,

auf Grund einer Änderung von Microsoft bzgl. Autodiscover haben wir unsere Auto-Konfiguration angepasst. Jetzt ist hat sich der Servername in der Serververwaltung unter E-Mail --> SSL/TLS --> Auto-Konfiguration geändert. Die Änderung wird jedoch nicht in die einzelnen Zonen propagiert. Selbt, wenn ich ein Zone-Update anstoße, passiert nichts.

Nur, wenn ich bei der Domain unter E-Mail Auto-Konfiguration zuerst deaktiviere und danach wieder aktiviere, funktioniert es.

Hat jemand eine Idee, wie ich die neue URL in die Zonen bekomme, ohne ein eigenes Zone-Update-Skript zu schreiben?

Vielen Dank im Voraus.

Alexander

Wenn man das Paket "apache2-suexec-custom" durch das Paket "apache2-suexec-pristine" ersetzt, kommt es zu keinen Fehlern.

Das Ersetzen war bei mir mit ein paar "Krücken" verbunden, ging aber am Ende doch sauber durch.

Hallo zusammen,

ich habe bei einem Kunden das Problem, dass die Quota, die Liveconfig bei dem Postfach anzeigt, um 400 MB größer ist, als die Realität.

Liveconfig zeigt an:

E-Mails: 2001

Größe: 2,34 GB (2.400 MB eingestellt)

Belegt: 1.402 MB

du -ms /var/mail/*user*/1/

auf den vollkommenen Postfachpfad gibt "917 MB" aus.

Woher kommt die Differenz? Außer dem Postfach-Pfad fließt doch nichts anderes in die Berechnung ein, oder? Und Du auf das Root-Verzeichnis des Postfachs schließt auch alle darin enthaltenen Dateien ein. Ist das ein Rundungsproblem? Dann wäre der Effekt aber sehr hoch. Kann man eine komplette Neu-Indizierung anstoßen?

Vielen Dank und viele Grüße

Alexander

Er ist verbunden. Nach dem Update auf die 2.16 hat er auch alle neuen Änderungen umgesetzt. Nur die alten sind irgendwie "lost" ... die Logs sind komplett unauffällig. Auf dem Client werden die entsprechenden Domains auch nicht in den Logs erwähnt --> Updates sind nicht am Client angekommen.

Auf dem Master wird in den Logs auch nicht wirklich was nachvollziehbares geloggt:

[2023/08/10 00:45:04.861652] [776523|1407897] Triggering vHost update for subscription '*user*'

[2023/08/10 00:45:05.048895] [776524|776524] Pushing LCCP job into queue: 'LC.web.vhostConfig'

[2023/08/10 00:45:05.048952] [776524|776533] Handling LCCP command 'LC.web.vhostConfig'

[2023/08/10 00:45:05.049337] [776524|776533] [LUA] LC.web.configureVHost()

Nachtrag: Interessanterweise finde ich zu keinen bekannten nicht-durchgeführten Änderungen Eintragungen im liveconfig-Log (Domain-Erstellung; DKIM-Eintrag im DNS etc.).

Hallo zusammen,

ich musste heute feststellen, dass der Liveconfig-Server an den Mail- und Bindserver (mit eigener Liveconfig-Lizenz) wohl seit einiger Zeit keine Anpassungen geschickt hat (Nameserver-Einträge fehlen - u.a. DKIM-Einträge, Domains fehlen im Bind). Gibt es irgendwie die Möglichkeit, die Änderungen manuell nochmals anzustoßen?

Im Hauptserver sind die angelegten Domains unter Kunde --> Domains sichtbar. Es fehlt somit "nur" die Kommunikation zum Bind.

Verwendetes OS:

Detected 'Debian GNU/Linux 11 (bullseye)'

Hauptserver mit Liveconfig, HTTP, FTP, MySQL

Mailserver mit Mail, Spam, DNS (bind)

Vielen Dank im Voraus.

Hallo Herr Keppler,

danke für die Antwort.

Zitat von kk

PHP 5.5 hatten wir bislang nicht für FPM vorkonfiguriert.

Das muss auch nicht sein. Vielleicht entfernen Sie die FPM-Ausgabe bei "liveconfig --diag" für die PHP 5.5. Denn das hat mich irritiert. Und noch mehr irritiert hat mich, dass Verzeichnisse wie von Geisterhand immer wieder gelöscht wurden. Ich werde den Kunden ein letztes Ultimatum geben und dann gibt es ein "apt-get remove --purge php-5.5-opt"

Ich melde an, dass ich den Bedarf nicht habe. Die Frage ist, ob die Kunden, deren Admin immer im Urlaub ist ;), denn mit der Warnung mehr zu Potte kommen würden. Ich bezweifle das. Ist so ungefähr das gleiche, wie das leidige PHP 5.5-Thema ... das dauert gefühlt auch Jahrzehnte bis alle upgedatet haben.

Hallo Anton,
Ihr lässt Eure Maschinen ohne Test automatisch updaten? Oder habt Ihr ein eigenes firmeninternes Repository?
Wie gewährleistet Ihr mit dem automatischen Update die Verfügbarkeit?