Was sagen denn die Logs nach so einem Reboot, warum LCSam SpamAssassin nicht findet/nutzt? Was sagt der Spamasassin-Dienst selbst dazu?
Was passiert, wenn über "spamc" manuell eine Mail an spamd übergeben wird?
Wir fahren hier ausschließlich Debian Stretch und hatten diese Symptome kein einziges Mal. Ich bin mir auch sicher, dass LiveConfig niemals eine Version veröffentlicht, die Konfigurationen schreibt, die nicht Reboot-fest sind.
Ich würde gern z.B. den Parameter pm.max_children = 8 erhöhen, wo und wie mache ich das?
Aktuell über Webinterface/Configs - gar nicht.
ZitatIch vermute mal nicht in dieser .conf, oder?
Korrekt. Die wird allerdings bei Änderungen neu geschrieben.
Die web.lua bzw. apache.lua kann natürlich direkt geändert werden - das ist dann zumindest längerfristig, wenn auch nicht liveconfig-update, fest.
ZitatKann ich das über die PHP-Einstellungen in LC erledigen?
Nein.
kk: bitte den ersten Beitrag auf die neuen RewriteRule anpassen. Danke! 
Eventuelle Hinweise in "dmesg"/journal zu Segfaults in den Binaries, die entweder kaputt sind oder auf kaputten RAM hinweisen könnten?
Please set the FQDN of your server not to "hisdomain", but instead use "server.hisdomain.com" or similar. That's also included in the general setup manual of LiveConfig.
Kurz zur Info: mit LiveConfig v2.8.0 gibt es einen LCDefaults-Key "mail.forwards.blacklist", bei dem man bestimmte Zieldomains für die Verwendung in E-Mail-Weiterleitungen sperren kann (kommagetrennte Liste). Also z.B. so was wie "gmx.de,web.de,t-online.de".
Bestehende Weiterleitungen sind davon nicht betroffen, die Blacklist wird nur beim Anlegen oder Bearbeiten eines Postfachs geprüft.
Kurze Rückfrage: Aktuell ist ja 2.7.4-r5214 - ist dort der Commit r5157 (vgl https://www.liveconfig.com/de/…6889&viewfull=1#post16889) schon drin enthalten?
Achtung: NEOS ist auch betroffen, dort wird der SetHandler auch verwendet:
# Prevent execution of script files
SetHandler default-handler
<Files *>
# Override again if executed later in the evaluation list
SetHandler default-handler
</Files>Vorhandene Domains mit PHP X.Y sollen die PHP Version X.Y beibehalten.
PHP 7.3 soll neue Standardversion werden und für alle neuen (Sub)Domains gelten.
Diese Option wäre zu begrüßen.
Die neuen API-Methoden lassen sich dafür auch nicht nutzen?
Da es nur DomainAdd und kein DomainUpdate gibt - nein.
Dovecot und Postfix sollen *ein* Zertifikat erhalten, welches mehrere SANs enthaelt. Ich moechte die Kunden nicht zwingen die Einstellungen ihres eMail-Programms aendern zu muessen, deshalb soll das System mehrere valide Namen haben.
Da stellt sich die Frage, was leichter ist: einmalig Kunden dazu zwingen, ihr Mailprogramm zu ändern, oder sich um ein SAN-Zertifikat zu bemühen.
Zumal es - abhängig von der Umgebung - im SAN-Zertifikat auch Privatsphären-Probleme gibt. Immerhin sieht jeder, welche CN sonst noch geschützt werden.
ZitatKann ich über Liveconfig ein Letsencrypt-Zertifikat erstellen, welches mehrere SANs besitzt?
Abgesehen von der Domain und der WWW-Subdomain - nein.
ZitatAngenommen ich baue mir ein LE-Zertifikat per Certbot ganz an Liveconfig vorbei, dann wuerde ich es gerne trotzdem an Liveconfig uebergeben, so dass Liveconfig es an die Dienste (Postfix, Dovecot) verteilt. Ist dies der Weg den ich gehen sollte? Muss ich dafuer wirklich mit der API sprechen? Ich wuerde gerne allzu große Klimmzüge vermeiden.
Certbot/Dehydrated - möglich.
Übergabe an LiveConfig - nicht.
Einfach die phpinfo() anschauen.
Befehl in ein eigenes Bash-Script auslagern und dieses in der Crontab ablegen/ausführen.
Oder gleich das PHP-Script via CLI aufrufen und die Mail dort erzeugen:
/usr/bin/php -f /var/www/..../cron.phpTatsache. Die Mails liegen im mail-spool des lokalen Users nico. Aber wie kommen diese da rein? Ich verstehe das Mapping an der Stelle einfach nicht ganz.
Da Postfix "domain.de" als HOstname verwendet, wird "Nico@domain.de" an den System-User "nico" übermittelt - irgendwie muss Postfix ja auch internes verwalten können.
Die virtuelle Domain, die über LiveConfig angelegt wird, wird daher ignoriert (und auch in den Logs als Warnung angegeben!).
Zitatliefert den Domainnamen mit Endung.
In der /etc/hosts Datei ist sowohl das Mapping für v4 und v6 gesetzt.
Nochmals: genau das ist falsch.
Umbenennen auf "server.domain.de" oder ähnliches - nur die Domain führt zu obigen Fehlern.
Bitte verwende doch für so Code die Code-Tags ("[code ]...[/code ]").
[code]to=<nico@DOMAIN.de>, relay=local, delay=0.36, delays=0.35/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)[/quote]
Gibt es einen System-Account "nico"? Dann leigen die Mails dort.
Es sollte nämlich "relay=dovecot" verwendet werden.
=> Server umbenennen.
Laut Log landen die Mails doch in der Mailbox?
Der Server hat allerdings den falschen Hostname:
Jan 6 14:08:03 DOMAIN postfix/trivial-rewrite[25662]: warning: do not list domain DOMAIN.de in BOTH mydestination and virtual_mailbox_domainsUmbenennen in server.DOMAIN oder ähnliches.
Siehe auch im Handbuch.
Das ist Wichtig, da den Haken viele Kunden einfach übersehen und im Nachhinein meckern, weil viel Spam kommt.
Da sind jetzt mehrere Sachen vermischt worden.
- die LCDEFAULTS greifen nur, wenn ein neues Postfach angelegt wird. Egal, wann - solange dies nach der Änderung passiert. Durch die Änderung der Defaults werden keine bestehenden Postfächer angefasst.
- eine Aktivierung von SA-Einstellungen für alle Kunden, zwangsweise über die gesamte Datenbank hinweg und das auch noch über die Web-UI des Admins, halte ich für falsch. Immerhin gibt es genügend Kunden, die explizit den Spam-/Viren-Filter deaktiviert haben wollen.
=>
- direkt beim Server-Setup die LCDEFAULTS passend setzen. Dafür gibt es inzwischen ja sogar schon das AutoDeploy.
- nachträgliche Änderungen halte ich für nicht realisierbar. Da muss der Kunde schon selbst Antispam aktivieren, wenn ihm zu viel Spam kommt.
Der Ordnername "Junk" wird vom Server vorgegeben und kann daher nicht auf "Spam" geändert werden.
- was steht im Log zu Bind und LiveConfig?
- Zonen-Dateien werden nur mit "freeze" geschrieben, ansonsten gibt es das Journal. Anschließend den "thaw" nicht vergessen.
Die Limits lassen sich doch auch bei Dovecot über die GUI unter dem Punkt "Verbindungen" festlegen.
Dort lassen sich nur die Anzahl der gleichzeitigen Verbindungen festlegen - nicht aber die Prozess-Limits.
ZitatDiese Datei existiert derzeit nicht. Erstelle ich diese mit dem gen. Inhalt kommt es zu dem Fehler. (Es existiert nur die dovecot.conf-Datei)
das process_limit gehört offenbar nicht in die protocol{}-Sektion.
Anlegen mit:
default_process_limit = 1024
default_client_limit = 2500