Beiträge von marinal

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?

Ich sollte hier eventuell noch eine Information hinzufügen. Bei den anderen PHP-Versionen, welche aus dem Liveconfig-Repository zur Verfügung gestellt werden, werden die oben genannten PHP-Dateien mit dem Debian-Package erstellt (verifiziert mit php-7.0-opt):
- /lib/systemd/system/php70-fpm.service und
- /etc/php-fpm/php70-fpm.conf

Gibt es zu diesem Problem keine Hinweise?
Es wird Apache2 als Webserver verwendet.

Hallo zusammen,

ich habe ein Problem mit PHP-FPM mit PHP 5.5.38 unter Debian stretch. Nach der Installation von PHP5.5 sind die Datei "/etc/php-fpm/php55-fpm.conf" und das Verzeichnis "/etc/php-fpm/php55-fpm.d" nicht vorhanden. Ferner ist das Verzeichnis für den Socket nicht vorhanden. Selbst, wenn ich das Verzeichnis anlege, wird es immer wieder wie von Geisterhand gelöscht.

Und ja, ich weiß, wie alt PHP 5.5 ist, aber ich muss den Usern noch ein paar Monate Zeit für deren Update geben.

Ich bedanke mich jetzt schon für jeden Hinweis.

Was ich bisher gemacht habe ...

• /etc/php-fpm/php55-fpm.conf angelegt (von der default-Config im dpkg
• /etc/php-fpm/php55-fpm.d angelegt (Verzeichnis)
• /lib/systemd/system/php55-fpm.service angelegt
• /var/run/php55-fpm/ angelegt.

Hallo Anton,
lange nichts mehr direkt von Dir gelesen.
Danke für Deinen Vorschlag. Wollte Dir schon letztes Jahr antworten.
doveadm search bringt meines Erachtens nicht die Ergebnisse, da mein Skript benutzerbasiert funktioniert. Bayes lernt somit bei jedem Benutzer, was für diesen Spam ist. Ham habe ich mittlerweile herausgenommen.

Nachdem es keine einheitliche Regel gibt, wie Spamordner zu heißen haben, brauche ich eine Wildcard bzw. eine Regex.

Das Dovecot-Plugin war bereits letztes Jahr "deprecated". Hier wäre Sieve eine Alternative, aber auch dort habe ich das Problem, dass die Spam-Ordner nicht einheitlich sind.

Oder habe ich irgendwas übersehen?

Viele Grüße
Alexander

Guten Morgen,

welches Betriebssystem verwendest Du? Hast Du Spamassassin installiert und Postfächer zur Verwendung von Spamassassin aktiviert? Unter Debian werden die Dateien im "LOCAL_STATE_DIR" abgelegt. Den Ort kannst Du über die Debug-Ausgaben von Spamassassin herausfinden.

Und ja, kann sein, dass das Skript einen Fehler enthält. Es steht ja dabei, dass Verbesserungen jederzeit willkommen sind.

Nachtrag: Ich habe bei mir das Lernen von HAM aus der Inbox abgeschalten, da dort auch aller unerkannter Spam vor dem Taggen durch den Benutzer landet.