Beiträge von kk

Hat nichts mit LiveConfig zu tun, sondern mit dem Server insgesamt. Führen Sie "systemctl status apache2" aus - vermutlich bringt das die selbe Fehlermeldung.
Anhand der spärlichen Fehlermeldungen kann man unmöglich sagen, was die Ursache ist. Eventuell läuft schlicht systemd nicht (z.B. wenn Upstart eingesetzt wird).

Da uns einige Anfragen hierzu erreicht haben: in ProFTPD steckt offenbar eine Sicherheitslücke (CVE-2019-12815) im Modul mod_copy.

LiveConfig ändert nichts an der Modul-Konfiguration von ProFTPD. Wir haben die Konfiguration unter Debian 8/9/10 getestet - dort ist mod_copy standardmäßig nicht aktiviert. Sie können mit folgendem Befehl testen, welche Module geladen werden:

proftpd -d 7 -t 2>&1 | grep loading

Sollten Sie mod_copy aktiviert haben, können Sie die entsprechende LoadModule-Anweisung einfach aus der ProFTPD-Konfigurations auskommentieren und ProFTPD neu starten.

Weitere Distributionen testen wir bei Gelegenheit auch noch durch.

Viele Grüße

-Klaus Keppler

Für PHP 7.2 haben wir das inzwischen in unser Buildsystem aufgenommen, PHP 7.3 folgt nächste Woche.
Beim nächsten PHP-Update wird Argon2 dann unterstützt (voraussichtlich in ca. 2-3 Wochen).

Auch unter Debian 8 und Ubuntu 16 (die keine libargon2 mitbringen) wird PHP Argon2 unterstützen (da haben wir die notwendige Bibliothek statisch in die Argon2-Extension gelinkt).

AutoDiscover/AutoConfigure hat mit SSL relativ wenig zu tun. Um genau zu sein, muss sogar zwingend ausdrücklich kein SSL auf der Autodiscover-Domain laufen (sprich: HTTPS/Port443 darf dort nicht geöffnet sein).
Das grobe Vorgehen für AutoDiscover ist im Wiki beschrieben: https://www.liveconfig.com/wiki/de/autodiscover
Das ganze ist aber aufgrund der Eigenheiten (insbesondere der Microsoft-Produkte) ziemlich anspruchsvoll und lohnt sich für einzelne Domains nicht wirklich.
Zwingende Voraussetzung für AutoDiscover ist ohnehin, dass Sie eine separate IP-Adresse zur Verfügung haben, auf der nur Port 80 geöffnet ist (für die Autodiscover-Weiterleitung).

Zitat von antondollmaier

8.000 SSL-Zertifikate unter der selben Subdomain funktionieren nicht - da greifen die Rate-Limits von Let's Encrypt.

... außer man ist Sponsor bei Let's Encrypt.

Zitat von lebenszeit

Wenn sich stable wegen Backup und ein paar "Kleinigkeiten" in GUI verzögert bitte ich um Release gefolgt von baldigem Update.

Wir haben aktuell das Problem, dass ein Kunde (wohl unbeabsichtigt) eine sehr frühe Preview-Version produktiv eingespielt hat und dem nun tausende Let's-Encrypt-Zertifikate um die Ohren geflogen sind.
(eine gefährliche Mischung aus "selber in die Datenbank eingegriffen" und "nö, ich sehe im Log nichts auffälliges").
(der Eingriff in die Datenbank hatte >50.000 SSL-Aufträge generiert, der Account ist in's Rate-Limit gerasselt, und wir arbeiten mit dem Kunden derzeit an einer Lösung)

Ja, das war ganz klar die Schuld des betroffenen Kunden, aber wir möchten den nunmal auch nicht im Regen stehen lassen. Zudem "nutzen" wir diese recht extremen SSL-Probleme nun dafür, LiveConfig in solchen Fällen etwas robuster zu machen (Beispiel: wenn DNS-TTL auf 1sec steht, wiederholt LiveConfig tatsächlich alle 1sec den DNS-Check vor einem SSL-Auftrag - das wurde nun aus konkretem Anlass auf eine Mindestwartezeit von 5min geändert).

Lange Rede, kurzer Sinn: wir feilen aktuell noch am letzten SSL-Dialog (SSL für bestehende Subdomains aktivieren), dann gibt's ein Update der Preview welches wir dann auf "unseren" ersten Produktivservern einspielen um in den Praxistest zu gehen. Backup-Integration läuft parallel dazu weiter, ist aber kein Showstopper mehr.

Zitat von Maxx

Fehler: failure while executing tar

Diese Meldung kann eigentlich nur auftreten, wenn die Datei in irgendeiner Form vorhanden ist... prüfen Sie bitte noch mal ob die auch wirklich in /var/cache/liveconfig/downloads/ gelöscht ist.

Ja, bei Änderungen an den Vertragseinstellungen wird die Konfiguration neu geschrieben, aber es werden auch die FastCGI-Instanzen neu gestartet.

Wenn eine PHP-Anwendung hängt und z.B. noch Dateien geöffnet hat, dann könnte das zu Problemen beim Upload führen. Falls das Problem mal wieder auftritt, mal mit "lsof" prüfen ob noch Dateien des betroffenen Benutzers geöffnet sind ("lsof also entsprechend mit z.B. "grep" filtern).

FileZilla ist im Zusammenspiel mit FTPS ohnehin problematisch; am besten im LiveConfig die Checkbox "SSL Session Reuse" bei den FTP-Server-Einstellungen deaktivieren.

Welchem Benutzer gehört denn das entsprechende Verzeichnis, und ist das Erstellen von Dateien darin erlaubt? (also Owner & Mode mal prüfen)

Wenn der Webspace evtl. mal auf mod_php konfiguriert war, könnte es sein dass einige Dateien/Verzeichnisse dem Webserver-User (www-data) gehören.

Am naheliegendsten: Webspace voll? (Quota)

Ansonsten schreibt vsftpd doch sicher irgendwas in's Log...

Viele Grüße

-Klaus Keppler

Zitat von Maxx

Funktioniert auch unter dem User liveconfig.

Kann es sein, dass die Auflösung der DL-URL nicht funktioniert? Also sprich, dass der Weg auf Amazons Server nicht gefunden wird?

Das ist äußerst merkwürdig.
Löschen Sie bitte die Dateien /var/cache/liveconfig/downloads/roundcubemail* und stoßen anschließend noch mal die RoundCube-Installation über den AppInstaller an. Ist die Datei wieder nur 0 Bytes groß?

Der AppInstaller führt als Benutzer "liveconfig" folgenden Befehl aus:

wget --no-check-certificate -O roundcubemail-1.3.9-complete.tar.gz https://github.com/roundcube/roundcubemail/releases/download/1.3.9/roundcubemail-1.3.9-complete.tar.gz 1>&2

Der Fehlerkanal (stderr) wird derzeit nicht protokolliert, das ist aber nur eine kleine Änderung die wir in v2.8 noch mit aufnehmen.

Oh, sorry - die Zeile hatte ich überlesen.

Da LiveConfig den Download als User "liveconfig" ausführt, wäre das evtl. mal einen Versuch wert:

su -s /bin/bash liveconfig
cd /var/cache/liveconfig/downloads
wget https://github.com/roundcube/roundcubemail/releases/download/1.3.9/roundcubemail-1.3.9-complete.tar.gz

Der AppInstaller macht im Grunde nämlich auch nichts anderes...

Wechseln Sie auf dem Server bitte mal ins Verzeichnis /tmp/ und laden das Installationspaket dort manuell herunter:

cd /tmp
wget https://github.com/roundcube/roundcubemail/releases/download/1.3.9/roundcubemail-1.3.9-complete.tar.gz

Eventuell ist das Paket "ca-certificates" nicht installiert?

Welche Ausgabe (exakt) liefert "php -v" und welche Linux-Distribution genau nutzen Sie?

Nein, da ist nichts geplant.
Weder POP3 noch IMAP unterstützen eine Zwei-Faktor-Authentifikation im Protokoll, ebensowenig die dahinterstehende Software (Dovecot).

Die PHP-Pakete für Debian 10 und Ubuntu 18 wurden eben aktualisiert, da dort die php.ini-Einstellung "sendmail_path" fehlerhaft war. Weitere Änderungen gab es nicht.

Viele Grüße

-Klaus Keppler

Zitat von BMK-Media

Das war mit dem Admin Account, beim Login Sprache auf Standard (also Deutsch)

Welche LiveConfig-Version genau nutzen Sie denn?
Handelte es sich um ein Postfach eines eigenen Vertrags ("Mein Hosting") oder eines Kunden?

Zitat

OK, wollte eigentlich auch SpamAssassin pro Postfach lernen lassen, aber das geht dann ja nicht, weil es dort die Datenbank nicht gibt.

Der Bayes-Filter wird (bei heutigem Spam) massiv überbewertet - den Aufwand kann man sich eigentlich komplett sparen. Lieber die bestehenden Filter tunen, und SpamAssassin bzw. ClamAV mit weiteren Regelwerken erweitern.

Zitat

Noch eine Frage, ist es möglich wieder die Benutzerdefinierte Header reinzusetzen, wie bei SpamAssassin, denn diese werden nicht angenommen.

Code

add_header all maximal_Score _REQD_
add_header all Score _SCORE_
add_header all Report _REPORT

Nein, das geht nicht ohne weiteres, da SpamAssassin in diesem Setup die E-Mail nicht modifizieren kann. Wenn lcsam mit der Option "-r" gestartet wird, fügt er den "X-Spam-Report:"-Header hinzu.
Um das mit systemd einzurichten, einfach den Befehl "systemctl edit lcsam.service" ausführen und folgenden Override anlegen:

[Service]
ExecStart=
ExecStart=/usr/lib/liveconfig/lcsam -g spamd -U postfix -r

Danach lcsam neu starten (systemctl restart lcsam.service).

Ich glaube das sind die mit dem 5 Buchstaben.
Wir haben das SNI-Thema für Postfix durchaus im Auge.
Aus rein technischer Sicht sehe ich keinen Mehrwert dadurch (aus dem selben Grund wurde dieses Feature ja auch jahrelang nicht implementiert...). Ich bin immer an Use-Cases interessiert, aber "Leute die es nicht schaffen ihre Postfächer richtig einzurichten" schaffen das dann mit einem eigenen Mail-Domainnamen auch nicht besser (die Energie für solche Kunden sollte man lieber in AutoConfigure/AutoDiscover investieren). Zudem unterstützen auch noch nicht alle Mail-Clients SNI entsprechend, was also letztendlich zu noch mehr Problemen führen kann (z.B. bei alten Outlook- oder Android-Versionen).

Aber zurück zum Thema: Debian 10 kommt mit Postfix 3.4 und würde das prinzipiell unterstützen.
Das größte Problem sehe ich in den SSL-Zertifikaten selbst. Da die meisten Anwender vermutlich gerne kostenfreie Zertifikate dafür nutzen möchten, müssen die Domains ("mail.example.org") automatisiert validiert werden. In Multiserver-Konfigurationen mit separatem Mailserver wird das durchaus kompliziert, da dort nicht zwangweise ein Webserver (für HTTP-Validierung) läuft.
Eine Idee hier ist, dass SNI angeboten wird, wenn alle Bedingungen für eine "einfache" HTTP-Validierung erfüllt sind (also u.a. dass auf dem Mailserver irgendein von LiveConfig gemanagter Webserver läuft).

Den Vorteil, dass der Kunde dann verschlüsselt mit "mail.<kundendomain>" arbeiten kann, erkauft man aber mit dem Nachteil, dass noch mehr SSL-Zertifikate verwaltet (validiert/aktualisiert) werden müssen - die Gesamtkomplexität und somit die Wahrscheinlichkeit für Probleme wird also meiner Einschätzung nach eher größer als kleiner.
Auch DANE/TLSA lässt sich mit einer "zentralen" Mail-Subdomain wesentlich einfacher handhaben...

Zitat von BMK-Media

geändert, da stand nur:

Code

SPAMDOPTIONS="-d -c -m5 --socketpath=/var/run/spamd.sock"

ist nun aber geändert und funktioniert.

Dann wurde diese Datei vermutlich nachträglich noch mal neu geschrieben (z.B. durch Neuinstallation von SpamAssassin)

Zitat

In /var/log/maillog steht nun folgendes

Code

Jul  8 13:51:08 server spamd[29231]: spamd: using default config for web1_1: /var/lib/spamassassin/web1_1//user_prefs

doch im Ordner /var/lib/spamassassin/ existieren nur diese Ordner, wahrscheinlich weil es vorher nicht lief?

Code

51265073 drwxr-xr-x 5 root root 4096  8. Jul 05:48 3.004000
1812258963 drwxr-xr-x 3 root root   18  8. Jul 06:41 compiled
1795184831 drwx------ 2 root root   79 28. Jun 01:04 sa-update-keys

Das passt schon so. Die user_prefs-Verzeichnisse werden erst ab v2.8 erzeugt, falls ein Postfach individuelle Blacklist/Whitelist-Einträge hat. Ansonsten werden keine user_prefs benötigt.

Zitat

Und mir ist noch etwas aufgefallen, in der /etc/postfix/spamassassin stand vorher z.B. immer

Code

NAME@DOMAIN.de      1 3 5 1 web1_1 ***SPAM-Verdacht***

bei den geänderten steht nun aber

Code

ANDERER@DOMAIN.de    1 3 5 1 web1_1 ***Suspected SPAM***

Der Text für den Header ("*** SPAM-Verdacht ***") wird mit der Sprache lokalisiert, die für den Benutzer eingestellt ist, der das Postfach bearbeitet.
Prüfen Sie daher bitte, mit welchem Account Sie das Postfach bearbeitet hatten und welche Sprache ggf. für diesen Benutzer eingestellt ist.

Zitat

get_spamd_fd: can't connect to '/var/run/spamd.sock': No such file or directory

Normalerweise sollte diese Datei aber existieren wenn SpamAssassin läuft (eben unter CentOS 7 getestet).
Haben Sie SpamAssassin evtl. aus einem anderen Repository installiert?

In /etc/sysconfig/spamassassin sollte Folgendes stehen:

SPAMDOPTIONS="-d -m 5 -H --socketpath=/var/run/spamd.sock --socketowner=root --socketgroup=spamd --socketmode=0660 -x --virtual-config-dir=/var/lib/spamassassin/%u/ -u spamd"

Wenn z.B. SpamAssassin nach der Aktivierung im LiveConfig nochmal komplett entfernt (erased/gepurged) wurde und dann wieder installiert, dann könnten da wieder die "falschen" Standardwerte drin stehen.

Zum anderen Problem (Postfachnamen stehen nicht in /etc/postfix/spamassassin): wenn Sie SpamAssassin für das betroffene Postfach mal deaktivieren, sollte der Eintrag wieder entfernt werden, wenn Sie es wieder aktivieren, sollte er wieder hinzugefügt werden.
Falls das nicht passiert, prüfen Sie bitte was in /var/log/liveconfig/liveconfig.log protokolliert wird, während die Postfacheinstellungen gespeichert werden.