Beiträge von kk

    Eine .htaccess sieht z.B. so aus:


    Ich habe es mit exakt dieser .htaccess getestet, und der Zugriff auf /.well-known/ wird korrekt auf die Validierungsdatei geroutet...


    Prüfen Sie bitte mal die vHost-Konfiguration (/etc/httpd/vhosts.d/<Vertrag>.conf), ob dort folgender Abschnitt drin steht:

    Apache Configuration
    <IfModule mod_rewrite.c>
            RewriteEngine On
    
    
            RewriteMap  "lc" "int:tolower"
            RewriteCond %{REQUEST_URI} ^/\.well-known/(.*/)?([^/]*)$
            RewriteCond /var/www/web1/htdocs/.well-known/%1%2 !-f
            RewriteCond /var/www/.well-known/htdocs/%1${lc:%{HTTP_HOST}}.%2 -f
            RewriteRule / /var/www/.well-known/htdocs/%1${lc:%{HTTP_HOST}}.%2 [T=text/plain,L]
        </IfModule>


    Der sorgt dafür, dass Zugriffe auf http://<domain>/.well-known/<datei> umgeleitet werden auf /var/www/.well-known/htdocs/<domain>.<datei>


    Testweise können Sie einfach mal eine Datei mit dem Namen /var/www/.well-known/htdocs/acme-challenge/<domain>.test.txt anlegen - die müsste dann unter http://<domain>/.well-known/acme-challenge/test.txt abrufbar sein.


    Zudem müsste in /etc/httpd/vhosts.d/00_default_vhost.conf auch folgendes zu finden sein:


    Damit routet LiveConfig die Zugriffe auf .well-known für Domains, die deaktiviert oder noch nicht vollständig konfiguriert sind.

    Hmm, interessant - sollte eigentlich nicht möglich sein.
    Könnten Sie uns mal schicken was genau in den RewriteRules der .htaccess drin steht? Dann testen wir das mal durch.
    Ziel seitens LiveConfig ist es immer, den Kunden "vor sich selbst" zu schützen. ;)

    aber der Betreiber und das OS hat dann weniger Kontrolle über die DNS-Tätigkeiten die vom System ausgehen ;)


    Ja, es hat eben alles Vor- und Nachteile. Wenn direkte DNS-Zugriffe möglich sind, dann nutzt LiveConfig diese um den TTL von DNS-Daten ignorieren zu können - wird ein externer Resolver verwendet, dann erhält LiveConfig ggf. Antworten aus dessen Cache (was im Normalbetrieb ja erwünscht ist, für Diagnosezwecke aber ungünstig ist).


    Bei Multi-Server-Setups genügt es, wenn der LiveConfig-Hauptserver DNS-Zugriff hat (die LiveConfig-Clients lösen keine DNS-Anfragen aus). Und wenn die DNS-Zugriffe lokal (iptables) gefiltert werden, kann man mittels "owner"-Modul einzelne Benutzer freischalten - wie z.B. den Benutzer "liveconfig". ;)

    bei mir wird mit der 2.8.1 in der Server Verwaltung der Dovecot Server nicht mehr angezeigt.
    Ein "lcclient --diag" findet den Dovecot aber zuverlässig. Daher tippe ich jetzt einfach mal auf ein Problem mit der anzeige.


    Hmm, das ist merkwürdig. LiveConfig macht beim Start nichts anderes als das was "--diag" auch macht (es führt eben die Paketsuche aus). Daher kann es eigentlich nicht sein, dass es manchmal klappt und manchmal nicht - dann müsste nämlich auch der Aufruf mit "--diag" manchmal kein Ergebnis bringen.


    Wurde LiveConfig eventuell neu gestartet während noch Pakete installiert wurden? (dann könnte der gleichzeitige Zugriff auf die APT-Datenbank einen Konflikt verursacht haben)


    Zitat

    Ein Neustart des Clients bringt nicht immer eine Lösung.


    Gibt es Server, bei denen der Client-Restart reproduzierbar nichts bringt?

    und welche werden sonst benutzt??


    Keine. LiveConfig nutzt mit "libunbound" einen integrierten, validierenden DNS-Resolver - die jeweiligen Nameserver werden dann also direkt kontaktiert. Für Diagnosezwecke ist man damit flexibler als mit einem externen Resolver.

    Hallo,


    ab sofort steht LiveConfig v2.8.1 zur Installation bereit.


    Die wichtigsten Änderungen sind:

    • Verbesserungen beim DNS-Check für SSL-Bestellungen (Timeout von 5 Sekunden für DNS-Anfragen, Caching von DNS-Daten für nur noch 60 Sekunden)
    • Wenn keine DNS-Abfragen "nach außen" erlaubt sind (Firewall), dann erkennt LiveConfig das nun automatisch und nutzt in diesem Fall die in /etc/resolv.conf hinterlegten Resolver. In diesem Fall sollten die Resolver aber DNSSEC-Validierung unterstützen!
    • Wird eine IP-Gruppe auf "starke" SSL-Chiffren konfiguriert, dann wird für diese IP-Gruppe automatisch auch TLSv1 und TLSv1.1 deaktiviert. Die SSL-Protokolle lassen sich (bei Bedarf) auch über Lua-Variablen ändern.


    Alle Änderungen sind wie immer im Änderungsverlauf zu finden.


    Viele Grüße


    -Klaus Keppler

    Ich denke wir brauch hier keine weitere Diskussion.


    Im vorliegenden Fall war zum Zeitpunkt der SSL-Bestellung noch die alte IP (.42) im DNS hinterlegt. LiveConfig prüft seit v2.8.0 die DNS-Einträge - hat hier also einen Fehler festgestellt (erwartet wurde die .45). Die DNS-Daten werden bislang aber durch die von LiveConfig verwendete Resolver-Software (unbound) gecached. Da die falsche Antwort mit einem TTL von 24 Stunden ausgeliefert wurde, hing die "alte" Antwort also entsprechend lange in LiveConfig fest.
    Das war und ist also kein Fehler in LiveConfig, sondern schlicht eine seeehr ungünstige Domainkonfiguration.


    In LiveConfig v2.8.1 werden DNS-Antworten nur noch maximal für 60 Sekunden gecached - damit können SSL-Bestellungen also sofort fortgesetzt werden, nachdem die DNS-Daten aktualisiert wurden.
    Dass der Endkunde bei einem Umzug mit großen TTL-Werten (egal ob 3 oder 24 Stunden) ganz andere Probleme hat, habe ich nun auch schon oft genug erklärt - das liegt aber außerhalb des Einflussbereichs von LiveConfig.

    Zur Information für andere Mitlesende: im DNS war die IP XX.XX.XX.42 hinterlegt, im Apache war diese Domain aber auf XX.XX.XX.45 konfiguriert. Die Fehlermeldung war also korrekt und berechtigt.


    Mit einem der nächsten Updates werden wir evtl. die Fehlermeldung noch etwas weiter aufbohren ("got XX.XX.XX.42, expected XX.XX.XX.45") - dann sieht man das vielleicht etwas schneller.


    Viele Grüße


    -Klaus Keppler

    Ich wiederhole mich gerne noch zum vierten Mal, aber gleichzeitig auch zum letzten Mal: ohne konkrete Daten können wir nicht weiterhelfen. Gerne per Mail an support@liveconfig.com. Ohne Hilfe keine Hilfe - sorry...
    Ich habe alleine in diesem Thread schon 3x geschrieben was wir brauchen, um das nachzuverfolgen:

    • einen betroffenen Domainnamen
    • dessen konfigurierte IP
    • (am besten den zuständigen <VirtualHost>-Abschnitt aus /etc/apache2/sites-enabled/<Vertrag>.conf)
    • und zudem alle Log-Einträge zu dieser Domain in /var/log/liveconfig/liveconfig.log


    Letztes Angebot.

    Wir werden voraussichtlich in der ersten Septemberwoche (ab 02.09.) diverse Server von Debian 9 auf 10 aktualisieren und eventuelle Stolpersteine dokumentieren.
    Aufgrund unserer bisherigen Erfahrungen auf Testsystemen ist aber nicht mit großen Überraschungen zu rechnen.


    Viele Grüße


    -Klaus Keppler

    Ich würde Ihnen ja wirklich gerne helfen - daher wiederhole ich mich gerne ein weiteres mal: ohne die genauen Log-Meldungen zu dieser Domain und konkreten Daten können wir nicht weiterhelfen.


    Würde die IP zum Bestellzeitpunkt stimmen, dann würde die Bestellung sofort durchgehen.
    Die Fehlermeldung ist extrem eindeutig und lässt KEINEN Spielraum zur Interpretation zu.
    Daher benötige ich konkrete, exakte Daten.


    Nutzen Sie vielleicht NAT-IPs auf Ihrem Server?

    Ich denke das hatten wir schon geklärt?
    Wenn die IP-Adresse zum Zeitpunkt der Bestellung korrekt wäre, dann würde es diese Fehlermeldung nicht geben.


    Ansonsten bitte konkrete Daten (IP, Domainname, alle Log-Meldungen aus /var/log/liveconfig/liveconfig.log) an support@liveconfig.com schicken.


    Die DNS-Einträge werden von LiveConfig alle 15 Minuten überprüft - sobald die stimmen, wird die SSL-Bestellung automatisch fortgesetzt.

    Update: die Ursache ist gefunden und behoben. Das Verhalten tritt auf, wenn man MySQL als LiveConfig-Backend verwendet und (das klingt vielleicht komisch) der Server zu schnell ist. :)


    In diesem Fall wird die Validierungsdatei auf dem Server angelegt und dem LiveConfig-Prozess zurückgemeldet, noch bevor die Transaktion mit dem Anlegen der Domain abgeschlossen ist.
    Wir ändern den Workflow nun geringfügig, um das Problem zu umgehen.


    Viele Grüße


    -Klaus Keppler

    Leider werden die SSL-Aufträge auch nicht bearbeitet:
    [...]
    Erst nach einem Neustart von LiveConfig wird das Zertifikat dann angelegt.
    CentOS Linux release 7.6.1810 (Core)
    LiveConfig 2.8.0-r5579


    Unter CentOS 7 mit MariaDB (5.5.60) als LiveConfig-Backend können wir dieses Verhalten reproduzieren. Wir kümmern uns gerade darum, der Fix wird noch mit in v2.8.1 einfließen.
    (mit SQLite als Backend, sowie auf anderen Distributionen mit anderen MySQL/MariaDB-Versionen klappt es interessanterweise...)

    Mit welcher PHP-Version genau und auf welcher Distribution führen Sie das Migrationsscript denn aus?


    Es ist wenig sinnvoll, TLSv1 oder gar SSLv3 wieder in LiveConfig zu aktivieren (Sicherheit geht vor) - notfalls müssten Sie z.B. über LiveConfig einen SSL-Proxy einrichten (also irgendeine Domain anlegen, die per "spiegeln (Proxy)" zur LiveConfig-URL weiterleitet).


    Oder eben das Migration-Script mit einer moderneren OpenSSL-Version ausführen (z.B. PHP 7.2/7.3).

    Keine Berechtigung user_prefs zu lesen. Konnte aber auch dieses Problem nun lokalisieren. Neue Nutzerverzeichnisse werden in /var/lib/spamassassin mit den Rechten root:spamd angelegt (bislang debian-spamd:debian-spamd), daher gab es in den bereits vor der Umstellung angelegten Verzeichnissen Probleme.


    Die von Debian/SpamAssassin verwalteten Verzeichnisse unterhalb von /var/lib/spamassassin/ müssen weiterhin debian-spamd:debian-spamd gehören (3.00*, compiled, sa-update-keys). Die Benutzerverzeichnisse (<Vertrag>_<PostfachID>) müssen spamd:spamd gehören und mode=0750 haben.


    LiveConfig macht das alles korrekt. Probleme gibt es nur, wenn SpamAssassin eben als Benutzer "debian-spamd" läuft (dann hat er keinen Zugriff auf die user_prefs). Umgekehrt hat SpamAssassin als Benutzer "spamd" aber Zugriff auf die Regeln, die "debian-spamd" gehören. Dieses Setup ist sicherer und deshalb so beabsichtigt.


    Code
    # ls -l /var/lib/spamassassin/
    total 0
    drwxr-xr-x 3 debian-spamd debian-spamd 71 May 14  2016 3.003001
    drwxr-xr-x 3 debian-spamd debian-spamd 71 Oct 23  2018 3.003002
    drwxr-xr-x 3 debian-spamd debian-spamd 71 Jan 15  2019 3.004000
    drwxr-xr-x 3 debian-spamd debian-spamd 71 Aug 23 07:02 3.004002
    drwxr-xr-x 3 debian-spamd debian-spamd 18 Oct 23  2018 compiled
    drwx------ 2 debian-spamd debian-spamd 79 Aug 23 07:02 sa-update-keys
    drwxr-x--- 2 spamd        spamd        57 Aug  2 18:34 web345_7

    Ist es normal, dass unter Debian 10 PHP-FPM nicht erkannt wird?


    Danke für den Hinweis!
    Die Erkennung für PHP 7.3 war noch nicht angepasst. Wurde eben korrigiert, ist in v2.8.1 (Release voraussichtlich am Montag) enthalten.
    Als Workaround bis dahin (in dringenden Fällen): die Datei /usr/lib/liveconfig/lua/web.lua bearbeiten und in Zeile 170 sowie 181-185 jeweils "7.2" durch "7.3" ersetzen; anschließend LiveConfig neu starten.

    Dann funktionieren die Spamfilter hier leider nicht mehr!


    In Beitrag #11 schreiben Sie doch aber dass alles funktioniert...?
    Die Änderung der Berechtigungen von /var/lib/spamassassin (siehe Beitrag 13) ist aber nicht notwendig (und wir raten auch davon ab).


    Wie genau äußert sich "funktioniert [...] hier leider nicht mehr" denn? Welcher Fehler tritt auf, bzw. was wird in /var/log/mail.log während des Empfangs einer E-Mail protokolliert?