Ich tippe mal darauf, dass Sie nicht das von Debian mitgelieferte NGINX-Paket installiert haben?
Dann kann es sein, dass LiveConfig die Konfigurationsdateien nicht dort sucht wo es sie erwartet.
Aus welcher Quelle genau haben Sie NGINX installiert?
Beiträge von kk
-
-
-
Ich lasse die Sache prüfen. Die Rücklastschriftgebühren werden selbstverständlich nicht berechnet.
Viele Grüße
-Klaus Keppler
-
Why blame LiveConfig for not being cheaper only because of Let's Encrypt?
Why shouldn't the server itself not also be cheaper?The "Basic" version of LiveConfig does exactly what it's named after: basic configuration of a server. Nothing more or less.
-
Hello,
the PHP packages for Debian have been updated to version 7.0.17 and 7.1.3.
Best regards & a nice weekend
-Klaus Keppler
-
Hallo,
die PHP-Pakete für Debian wurden eben auf die Versionen 7.0.17 und 7.1.3 aktualisiert.
Viele Grüße & ein schönes Wochenende
-Klaus Keppler
-
Wie ist denn hier der Status? Wäre halt gut, wenn man das pro Vertrag ein/ausschalten könnte, denn Exchange-User, die den Server als Smarthost benutzen, habe ich auch.
Status ist, dass so eine Konfiguration technisch möglich, aber relativ komplex ist.
(zu komplex, damit LiveConfig das derzeit mit abdecken könnte).Man kann das manuell wie folgt einrichten:
1.) Paket "postfix-pcre" installieren, damit Postfix mit PCRE-Lookups zurecht kommt.
2.) die /etc/postfix/main.cf wie folgt anpassen:Codesmtpd_restriction_classes = sasl_restricted_senders smtpd_sender_restrictions = check_sasl_access hash:/etc/postfix/sasl_access, [...] sasl_restricted_senders = reject_sender_login_mismatch smtpd_sender_login_maps = pcre:/etc/postfix/sender_login_map_default, hash:/etc/postfix/sender_login_map
3.) Datei /etc/postfix/sasl_access anlegen:Code# SASL-Accounts, die nur definierte Absenderadressen verwenden dürfen: user@example.org sasl_restricted_senders
Danach natürlich noch "postmap /etc/postfix/sasl_access" ausführen.
4.) Datei /etc/postfix/sender_login_map_default anlegen:
5.) Datei /etc/postfix/sender_login_map anlegen:Code# Liste der Absender (MAIL FROM) und der erlaubten Mailbenutzer info@example.org user@example.org manfred.mustermann@googlemail.de user@example.org
Danach auch "postmap /etc/postfix/sender_login_map" ausführen.Dieses Beispiel erlaubt es grundsätzlich allen SASL-Benutzern, die in "sasl_restricted_senders" stehen, nur E-Mails zu versenden, bei denen der Absendername ("From:") identisch mit dem SASL-Benutzernamen ist.
Zudem wird dem Benutzer "user@example.org" erlaubt, E-Mails auch als "info@example.org" oder als "manfred.mustermann@googlemail.de" zu versenden.WICHTIG: bei "smtpd_sender_restrictions" auch noch die bisherigen Einschränkungen übernehmen, sonst baut man sich ein "open relay".
Alle Einstellungen lassen sich über die custom.lua in "postfix.LOCALCONFIG" eintragen.Alle Angaben ohne Gewähr, o.g. Konfigurationsanweisungen sind "from scratch"!
-
Alles anzeigen
Also jetzt gehts auch mit TLS nicht mehr, einfach so über Nacht! Gestern abend ging es noch und heute Morgen dann so:
Status: Verbindung zum Server getrennt
Status: Auflösen der IP-Adresse für domain.de
Status: Verbinde mit 78.46.88.XXX:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Status: Initialisiere TLS...
Status: Überprüfe Zertifikat...
Status: TLS-Verbindung hergestellt.
Status: Angemeldet
Status: Empfange Verzeichnisinhalt...
Befehl: PWD
Antwort: 257 "/" is the current directory
Befehl: TYPE I
Antwort: 200 Type set to ISo weit klappt ja alles. Das heißt, die FTP-Anmeldung funktioniert einwandfrei. Das Problem liegt woanders:
ZitatAlles anzeigenBefehl: PASV
Antwort: 227 Entering Passive Mode (78,46,88,16,169,155).
Befehl: LIST
Antwort: 150 Opening BINARY mode data connection for file list
Fehler: Zeitüberschreitung der Verbindung nach 10 Sekunden Inaktivität
Fehler: Verzeichnisinhalt konnte nicht empfangen werden
Status: Verbindung zum Server getrennt"Passive mode" bedeutet, dass der FTP-Server darauf wartet dass Sie eine separate Datenverbindung dorthin aufbauen. Alle weiteren Details dazu finden Sie z.B. hier: http://www.proftpd.org/docs/howto/NAT.html
So wie es aussieht, geht genau das schief. Ob das nun auf dem Zielserver nicht klappt (z.B. aufgrund von Firewall-Regeln!) oder vom lokalen Netzwerk aus (Virenscanner der die FTP-Verbindung "kapert" und untersucht) kann man von hier aus nicht sagen.Dass das "plötzlich" nicht mehr geht, kann ich mir nicht vorstellen - irgendetwas muss sich geändert haben. Am häufigsten sind es eigentlich Firewall-Einstellungen, die da was stören. Wenn es sich um einen vServer handelt, prüfen Sie, ob auf dem Host vielleicht gefiltert wird.
ZitatAlles anzeigenDas passiert wenn ich TLS wieder abschalte:
Status: Verbindung zum Server getrennt
Status: Auflösen der IP-Adresse für domain.de
Status: Verbinde mit 78.46.88.XXX:21...
Status: Verbindung hergestellt, warte auf Willkommensnachricht...
Antwort: 220 ::ffff:78.46.88.XXX FTP server ready
Befehl: USER vnXXXX
Fehler: Zeitüberschreitung der Verbindung nach 10 Sekunden InaktivitätWas wird denn in den "üblichen" Logdateien (/var/log/messages|syslog|auth.log, proftpd.log etc.) protokolliert, wenn so eine Anmeldung stattfindet?
Vielleicht stört hier eine lokale Firewall die Verbindung wenn sie sieht, dass da eine unverschlüsselte FTP-Verbindung aufgebaut werden soll?Viele Grüße
-Klaus Keppler
-
Hallo,
naja, dass das ein Problem sei war bislang noch nicht bekannt.

Wurde aber eben geändert - künftig erhalten alle CSV-Downloads den Dateinamen "data.csv".
(ab v2.3.0-r4519).Viele Grüße
-Klaus Keppler
-
Sollte ich IPV6 für ausgehende Mails deaktivieren, um nicht als Spam erkannt zu werden?
Als Spam erkannt? Wenn Sie Spam versenden, dann sollte dieser bitte auch korrekt erkannt werden.

Wenn Sie aber legitime Mails versenden, die nicht als Spam verdächtigt werden sollten, dann: ja, IPv6 ausgehend deaktivieren. Ist nicht im Sinne von IPv6, aber Google will das ja leider so.

-
Dies führt bei großen Anbietern wie Google dazu, dass man teilweise auf die Spam-Liste gesetzt wird.
Nein, ein fehlender SPF-Record ist sicher noch kein Spam-Merkmal.
Bei Google ist es nur problematisch, wenn man Mail per IPv6 einliefert und kein SPF gesetzt ist.SPF ist "broken by design", Mailweiterleitungen werden damit zwangsweise als Spam bewertet. Als Workaround dafür gibt es SRS (Sender Rewriting Scheme), was dann wiederum DKIM-Signaturen beschädigt.
Technisch betrachtet ist es also ordentlicher, keinen SPF-Record zu haben als aufgrund von Mailweiterleitungen und kaputten DKIM-Signaturen als Spam eingestuft zu werden.Wir empfehlen ganz klar DKIM als halbwegs ordentliche Methode zur Markierung "echter" Mails.
Viele Grüße
-Klaus Keppler
-
Es gibt auch den Anwendungsfall, dass reine Weiterleitungs-"Benutzer" ein Passwort erhalten, um sich damit direkt im LiveConfig anmelden und die Zieladresse selbst bearbeiten zu können.
Wir könnten die Passworteingabe aber deaktivieren, wenn weder die Postfach-Checkbox noch die Web-Login-Checkbox aktiviert sind.
-
Zitat
Error creating new cert :: Certificate public key must be different than account key
Interessant... auf die Idee muss man auch erst mal kommen

Das dürfte an sich aber unkritisch gewesen sein (die Fehlermeldung von LE wurde ja erkannt und ausgegeben).ZitatError while parsing SSL certificate (PEM): error:0906D06C:PEM routines:PEM_read_bio:no start line
Diese Log-Meldung wird ausgegeben, wenn eine vHost-Konfiguration geschrieben werden soll und bei der Prüfung ob das SSL-Zertifikat OCSP unterstützt ein Fehler auftritt.
Ich tippe auf ein Timing-Problem (vHost-Konfiguration wird ausgelöst bevor das Zertifikat in der Datenbank commited ist, o.ä.). Wir werden in der Konsequenz nun zwei Änderungen vornehmen:
1.) wenn ein SSL-Zertifikat aus der Datenbank "unbrauchbar" ist (warum auch immer) wird der SSL-vHost nicht mehr konfiguriert (besser nicht als kaputt).
2.) der Programmfluss zwischen "Zertifikat in Datenbank schreiben" und "vHost-Konfiguration aktualisieren" wird geprüft und ggf. geändert, um dieses vermeintliche Timing-Problem zu vermeiden.Das Ganze wird umgehend bearbeitet, Update folgt umgehend.
Viele Grüße
-Klaus Keppler
-
-
-
Hello,
the PHP packages for Debian-based systems have been updated to version 7.0.16 and 7.1.2. Additionally, the "APCu" extension is now also available for these versions.
Best regards
-Klaus Keppler
-
-
Hallo,
die PHP-Pakete für Debian-basierte Systeme wurden eben auf die Versionen 7.0.16 und 7.1.2 aktualisiert. Außerdem steht für diese Versionen nun auch die "APCu"-Erweiterung als Paket zur Verfügung.
Viele Grüße
-Klaus Keppler
-
Steht doch eigentlich alles in der Postfix-Dokumentation...

Wichtig ist hier die Einstellung smtpd_client_restrictions. Damit authentifizierte Benutzer zugelassen werden, sollte da permit_sasl_authenticated drin stehen.
Wenn ansonsten nur noch Mails von einer anderen (bestimmten) IP erlaubt sind, ist die Einstellung check_client_access das Mittel der Wahl.
Vollständig sähe das also etwa so aus:Codesmtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/allowed-ips, rejectIn die Datei /etc/postfix/allowed-ips gehören dann die erlaubten IP-Adressen:
Danach noch den Befehl "postmap /etc/postfix/allowed-ips" ausführen.Um die o.g. Einstellung in die von LiveConfig verwaltete main.cf aufzunehmen, folgende Zeilen in die custom.lua hinzufügen:
Codepostfix.LOCALCONFIG = { ['smtpd_client_restrictions'] = "permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/allowed-ips, reject" }Verwendung auf eigenes Risiko, alle Angaben ohne Gewähr.
-
Hallo,
wir haben inzwischen herausfinden können, dass es in der HTTP-Kommunikation mit den Let's-Encrypt-Servern manchmal zu einem Problem kam. Vereinfacht gesagt brach LiveConfig die HTTP-Verbindung vorzeitig ab, wenn z.B. "halbe" HTTP-Header in einem separaten TCP-Paket empfangen wurden. Das haben wir früher nie beobachtet, den Meldungen im Forum nach zu urteilen häuft es sich aber inzwischen. Ich schätze, dass das mit dem gestiegenen Anfragevolumen bei Let's Encrypt zusammenhängt.
Jedenfalls sollte ab v2.3.0-r4510 bei der Kommunkation mit Let's Encrypt nun kein Fehler mehr auftreten.
Wir arbeiten mit Hochdruck am Release von v2.3.0 - da es gerade im "Unterbau" viele Änderungen gab bitte ich noch um ein paar Tage Geduld.
Mit den in v2.3.0 verfügbaren neuen Funktionen sind uns derzeit keine Fehler mehr bekannt, die offenen Änderungen (vor dem Release) betreffen nun nur noch die GUI.Viele Grüße
-Klaus Keppler