Bei LiveConfig2 lässt sich der Mailserver nicht nachträglich über die GUI/SOAP ändern. Ich befürchte, das hat sich mit LiveConfig3 nicht geändert.
=> entweder manuell in der Datenbank anpassen und die System-Änderungen selbst nachziehen, oder den Vertrag komplett neu erstellen.
Was genau soll da unterstützt werden?
Nuja, das Debian-Team in allen Ehren - aber "verdammt schnell" wäre ein Datum zwischen dem Mainline-Patch (01.04.2026) und dem CVE-Assignment (22.04.2026) gewesen. Zudem patcht dieses Kernel-Update 303 (!) CVEs.
Keine Frage, das wäre besser gegangen.
Was ich aber mitbekommen habe, war, dass lediglich das Kernel-Team über die Schwere der Lücke und die Responsible Disclosure informiert wurde, aber keines der Distri-Teams. Und da finde ich Donnerstag Vormittag bis Freitag Abend schon schnell. Feiertag war ja auch (in DE) auch noch.
Das Debian-Team war verdammt schnell: inzwischen sind offizielle Kernel-Updates für Bullseye, Bookworm, und Trixie verfügbar:
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to system scope bus via local transport: Der Rechner ist nicht aktivIst das ein Debian-System, das von Debian 9 aus hochgezogen wurde?
Da scheint mehr im Argen zu sein. Das fehlende /run/liveconfig-Verzeichnis hätte ich jetzt adhoc noch als LiveConfig-Problem abtun können, aber mit dem zweiten Fehler ist das sowas von kein LiveConfig-Problem mehr...
Bitte prüfe dringend dein System. Da scheint Systemd große Probleme zu haben.
Hallo, wie bei mir oben im Post ersichtlich habe ich das bei uns bereits getan, es erscheint dennoch nirgends im v2 Web-Interface eine Option zum einstellen. Habe es auf 3 eMail Servern die in der großen Lizenz höngen mit v2 getestet. Nirgends erscheint es bei mir.
Der Screenshot von Klaus ist aus LiveConfig v3. In v2 scheint es nicht mehr integriert worden zu sein.
Wann gibt es diese Funktion? Das wäre eine große Hilfe, vor allem bei Kunden, die immer wieder anfragen... wäre das eine sorge weniger.
Geht doch schon: lcphp:
Das dürfte vorrangig an den Hetzner-IPs liegen. Wir haben aktuell keine Probleme.
Das wäre schlecht. Wie gesagt, 99,99% aller Kunden wissen wirklich nicht, das man erst den Haken in LiveConfig setzen muss
Wir haben die Selbstverwaltung der Postfächer über den LCDEFAULTS "mail.weblogin.enabled=1" pauschal aktiv. Es gibt, IMHO, nur wenige Gründe, weshalb sich die Postfach-Nutzer nicht selbst anmelden können dürfen.
Tut es. 
Wir trennen in unseren Cloud-Umgebungen unter Debian die Mount-Punkte auf:
Quotas sind somit effektiv nur auf /var/www notwendig.
Nebeneffekt: ein voller /var/www-Mountpunkt macht der Datenbank nichts aus.
Ich freue mich natürlich über eine Rückmeldung, ob die Anleitung bei dir funktioniert.
Wir haben ein (Python-)Script mit Cache, das Mails ähnlich dem Mail-Quota rausschickt. Wäre aber dennoch schön, wenn das integriert wäre, auch wenn die Mailadresse nicht für jeden Endkunden verpflichtend ist.
Auf dem Server ist Letsencrypt installiert und aktiv... aber die Config fehlt (auch wenn ich einen neuen LetsEncrypt anlege unter SSL Zertifikate -> SSL Anbieter).
Bin ich in den falschen Einstellungen?
Welche Konfiguration sollte denn fehlen? LiveConfig benötigt keinen certbot.
Zitat: "bei anderen Hostern muss ich auch nichts selbst kopieren, da geht das automatisch".
Es hat sicher seine Gründe, warum der Kunde sich für euch/uns entschieden hat. Die automatische Migration war's initial ja nicht ...
Dafür wird:
- eines der managesieve-Plugins in RoundCube
- sowie die ManageSieve-Konfiguration im Dovecot
benötigt.
Achtung: LiveConfig konfiguriert den Autoresponder auch über Sieve. Nutzt der Kunde seine E-Mail-Filter und konfiguriert dann einen Autoresponder, so sind die eigenen Filter plötzlich deaktiviert.
In LiveConfig 2 konnten Endkunden ohne eigenen Let's-Encrypt-Account bislang keine Zertifikate für z.B. Subdomains selber anlegen.
Häufig war/ist einfach als "admin" ein LE-Account eingerichtet, und beim Anlegen neuer Domains konnte mit einer (sogar vorausgewählten) Checkbox automatisch ein Let's-Encrypt-Zertifikat dafür eingerichtet werden. Der Endkunde hat von dem Zertifikat selbst üblicherweise praktisch nichts mitbekommen (die technischen Details interessieren die meisten Anwender ja auch nicht).
Das klappt aber nur für Domains. Wenn der Kunde in LC2 eine eigene Subdomain will, dann brauchen sie auch den eigenen Account, um das Zertifikat selbst zu erstellen.
Schön, dass das mit LC3 nun anders läuft und der Kunden-eigene Account somit weg fällt.
Allgemein zu Let's Encrypt: es ist nicht notwendig, dass sich Endkunden eigene Let's-Encrypt-Accounts anlegen. Im Idealfall sollte TLS inzwischen völlig transparent für Endkunden funktionieren: der Admin richtet einen "zentralen" Let's-Encrypt-Account ein, und Endkunden aktivieren beim Anlegen/Bearbeiten einer Subdomain lediglich die TLS-Checkbox. Den Rest macht LiveConfig automatisch.
Das ist aber neu in LiveConfig3 (und so auch sinnvoll!), aber bisher in LiveConfig2 so nicht gewesen - oder hab ich die letzten 10 Jahre da was falsch benutzt?
Ich würde die Datei nach /etc/liveconfig/lua.d legen. Nach /usr/lib kommen IMHO die Paket-Defaults.
Weitere Infos: https://www.liveconfig.com/de/…admin/lua.html#custom-lua
Folgende Zeile steht in der alten main.cf Datei:
smtpd_discard_ehlo_keywords = silent-discard, dsn
die neue Zeile sieht so aus:
smtpd_discard_ehlo_keywords = silent-discard
Empfehlung: das Ganze in die custom.lua aufnehmen, sonst ist die Konfiguration beim nächsten "Service neu konfigurieren" via LiveConfig weg.
postfix.LOCALCONFIG = {
['smtpd_discard_ehlo_keywords'] = "silent-discard"
}Zu Wildcard-Zertifikaten: wie sähe der Anwendungsfall hierfür aus? Es "kostet" ja nichts, jeweils einzelne Zertifikate auszustellen.
Prinzipiell wären Wildcard-Zertifikate mit LC3 realisierbar, vorausgesetzt die betroffene Domain wird auch von LiveConfig im DNS verwaltet.
Der Vorteil wäre eher die DNS-Validierung, die für Wildcard-Zertifikate ja zwingend nötig ist.
Somit könnten auch Webserver, die nur im internen LAN (bzw privates VLAN hinter VPN) erreichbar sein können, ein valides SSL-Zertifikat erhalten.
Und: der Hostname taucht nicht mehr im Transparency-Log auf.