Beiträge von marinal

Hallo zusammen,

ich bin sicherlich nicht der einzige, der einen externen Mailserver mit lcclient betreibt. Bisher waren mit den einjährigen Zertifikaten die Zertifikate immer sehr gut "handelbar".

Mit der Verkürzung wird das zukünftig sehr müßig. Was macht Ihr da? Da es sich um einen externen Mailserver handelt, müsste ich dort auch einen Webserver erlauben, damit "Let's encrypt" funktioniert. Da der Mailserver über den A-Record gesteuert wird, eine SAN-Lösung nur bei gleicher IP funktioniert, müsste ich gezwungenermaßen einen Webserver auf dem Mailserver einrichten.

Alternativ einen certbot mit lua-Skript. Aber so an Liveconfig vorbeimogeln mache ich halt nicht gerne. Führt meistens zu Problemen.

Welche Lösungen haben die wirklich Großen hier am Start?

Viele Grüße

Alexander

In der aktuellen Liveconfig-Version (3.2.5 (Build 18080)) gibt es einen Bug bei der Anpassung von Vorlagen.

Wenn man den Webspace bei einer Vorlage anpassen möchte, es bereits zu der Vorlage einen Vertrag ("Account") gibt, bei dem die Vorgabe aus der Vorlage überschrieben wurde (größer gesetzt wurde), so lässt sich die Anpassung an der Vorlage nicht durchführen.

Beim E-Mail-Speicherplatz funktioniert es jedoch!

Konnte selbst alle Probleme lösen. Am Ende musste man in der Datenbank die Fehler suchen. In einem Fall waren es unbegrenzte Mailboxen aber begrenzte Adressen, dann wiederum ein nicht-komplett konfigurierter Account. Der Vergleich zwischen den Werten bei HC_MAILADDRS und HC_MAILBOXES in der Tabelle "HOSTINGCONTRACTS" hat mich am Ende zum Ziel geführt.

Ein offensichtlicheres Logging im Debug-Modus wäre hier sehr wünschenswert! Oder aber Informationen in der Benutzeroberfläche.

Ich konnte jetzt teilweise etwas herausfinden. Die Liveconfig-Logs hatten folgenden Inhalt:
InputException: exceeded.0.account (*****), exceeded.0.properties.0 (users), exceeded.1.account (*****), exceeded.1.properties.0 (users)

Eigentlich passten immer die Anzahl an Nutzer, ich habe die aber trotzdem erhöht und danach war die Fehlermeldung weg.

Aktuell habe ich nur noch immer die Fehlermeldung "InputException: mailboxes (Die Anzahl der Postfächer darf nicht größer sein als die Anzahl der Adressen.)"

Den Fehler kann ich immer noch nicht auflösen.

Hallo,

ich wollte gerade den Account (Vertrag) eines Resellers anpassen und bekomme beim Speichern immer folgende Fehlermeldung:

"Durch das Speichern dieses Vertrages werden einige hierauf basierende Verträge ihre Limits überschreiten ("overprovisioning"). Möchten Sie fortfahren?"

Klicke ich die Checkbox an, kann ich trotzdem nicht fortfahren.Ich kann leider auch nicht den Webspace und den E-Mail-Space ändern, dass es passt. Da kann ich eingeben, was ich möchte ...

Er meldet z.B. aktuell "Die Anzahl der Postfächer darf nicht größer sein als die Anzahl der Adressen.". Bei beiden ist jedoch als Wert "unbegrenzt" hinterlegt.

Ferner wird bei Benutzer gemeldet, dass zwei Accounts des Resellers das Limit bei einem unbegrenzten Wert überschreiten.

Kennt jemand das Problem bzw. die Lösung?

Zitat von loswebos.de

Wir sind in 25 Jahren exakt 2 mal gewechselt. (ca 10k Domains) Anfangs wegen der Preise, Mittlerweile eher wegen höher Automatisierungsmöglichkeiten / AddOns. Preislich lohnte sich der Umzug nicht wirklich, übers Jahr gesehen spart man dann jedoch einiges an Zeit/Recherche/Nachfragen... und somit in Summe dann doch einiges.

Meinst Du jetzt bei OpenProvider?

Ich finde es mehr als bitter, dass wir jetzt nach über 20 Jahren uns einen neuen Domain-Provider suchen müssen ... es gibt scheinbar nur noch "think big"

Hat jemand Erfahrung mit Openprovider?

Hallo zusammen,

ich weiß ja nicht, wen es bisher alles getroffen hat, aber Internetx plant eine nicht unerhebliche Service-Gebühr pro Hauptbenutzer einzuführen.

Wer kennt gute Alternativen bzw. möchte auch wechseln?

Die Begründungen (NIS-2 und Co.) ziehen einfach nicht, da NIS-2 für Internetx nichts neues fordert, außer die Meldepflicht. Risikomanagement haben die vorher auch schon betrieben.

Freue mich über jeglichen Input.

Ich habe einen Post gelöscht, der inkorrekt war. Habe Roundcube auf die neueste Version geupdatet und konnte die Probleme des TO nachvollziehen.

Ich mache das Update immer über Konsole und das funktioniert sehr gut auch im App-Verzeichnis.

Rundmail kann nicht ausgeführt werden für Vertragskunden

Beim Versuch eine Rundmail zu initiieren (klick auf "Weiter") tut sich nichts in Liveconfig.

Eine Rundmail an "nur senden an:" funktioniert, der Versand an alle Vertragsempfänger funktioniert nicht.

Fehlermeldung:

[2029542] [2026-05-21 07:52:51.527108] [DEBUG] InputException: recipient.allOtherLcUsers (Unerwartete Eingabe)

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?