Beiträge von kk

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

Zitat von ap24

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).

Zitat von bravesurfer

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.

# 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

Zitat von Febas

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.

Danke für die Info, wir werden das gleich aktualisieren.

WordPress hat vor einigen Tagen schon einmal die Pakete ohne Ankündigung (und ohne Versionsänderung) aktualisiert - keine Ahnung was da aktuell los ist...

Zitat von bravesurfer

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?

Zitat von ñull

Seht so aus das Apache Option FileInfo jetzt nicht mehr verfügbar ist

Welche LiveConfig-Version genau nutzen Sie?
Es gab mit LiveConfig 2.7.4 Sicherheitseinschränkungen (SetHandler war nicht mehr erlaubt), ab LiveConfig 2.8.0 ist SetHandler aber wieder erlaubt.

Schicken Sie uns bitte ansonsten mal den Inhalt von /etc/apache2/sites-enabled/<Vertrag>.conf an support@liveconfig.com

Viele Grüße

-Klaus Keppler

Auf welches Protokoll genau soll zugegriffen werden (noch besser: welche LiveConfig-URL (Pfad genügt) wird aufgerufen?)

Zitat

Allerdings wurde wohl auch beim Upgrade kein db.bak File angelegt. Upgrade wurde gestern durchgeführt.

CentOS, richtig? Werden wir überprüfen - sieht nach einem Fehler im RPM aus.

Danke für die Info. Wir haben das beschriebene Vorgehen eben unter CentOS 7 getestet - hier hat alles geklappt.
Die Fehlermeldung ("... for unknown subdomain ...") zeigt, dass eine Datenbankabfrage an einer bestimmten Stelle kein Ergebnis zurücklieferte, obwohl sie das hätte tun müssen.
Bitte melden Sie sich mal kurz unter support@liveconfig.com damit wir das mit ein paar SQL-Befehlen untersuchen können.

Viele Grüße

-Klaus Keppler

Zitat von taenzerme

Danke für die Info, kk. Schade. Gibt es denn eine Roadmap für die 2.8.1?

Update ist für kommenden Montag (26.08.) geplant.

Zitat von ap24

Code

[2019/08/22 11:22:06.988983] [12850|12851] [LUA] Created SSL/TLS domain-validation file '/var/www/.well-known/htdocs/acme-challenge/demo2.domain.de.epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'
[2019/08/22 11:22:06.992495] [12849|12859] Got LC.web.addValidation.status for unknown domain 'demo2.domain.de' at '/.well-known/acme-challenge/epyj8O-rY4fkX1zH5j4--7F5IlDfMPZQmn8iVmoJF74'

Können Sie bitte kurz beschrieben, wie exakt Sie diese Domain angelegt und das SSL-Zertifikat dafür bestellt haben?
Die Fehlermeldung sagt sinngemäß, dass die Datei für die Domainvalidierung erfolgreich erstellt wurde, LiveConfig aber keinen offenen Bestellvorgang fand und daher den Auftrag nicht weiter verarbeitet hatte.
Lässt sich das mit anderen (Sub-)Domains reproduzieren?

Automatische SSL/TLS-Zertifikate für Subdomains (per einfacher Checkbox) kommen mit dem nächsten Update (v2.8.1).
Auch das wird also einfacher werden als bisher.

Es muss NICHTS angepasst werden! Lassen Sie die Dateibereichtigungen in /var/lib/spamassassin bitte unverändert auf "debian-spamd".

Das hat schon alles so seinen Sinn. Da SpamAssassin als "spamd" läuft, hat er keinerlei Schreibrechte irgendwo im System, kann aber auf die Regeln zugreifen (die "debian-spamd" gehören).

Wir testen die von LiveConfig erzeugte SpamAssassin-Konfiguration automatisiert auf allen unterstützten Plattformen (u.a. eben auch Debian 8/9/10) - das läuft reibungslos.
Im vorliegenden Fall wurde SpamAssassin nach der Aktivierung im LiveConfig nachträglich nochmal deinstalliert und neu installiert - dadurch gehen die Anpassungen natürlich verloren.

Wenn sich SpamAssassin zwischendurch "spontan" beendet, dann deutet das in vielen Fällen auf den sog. "OOM-Killer" hin (der schlägt bei SA gerne an, da der Prozess viele Ressourcen benötigt). Das hat aber weder etwas mit LiveConfig noch mit der SpamAssassin-Konfiguration zu tun. Ein Administrator kann der Ursache anhand der Logs auf den Grund gehen.

Um das klar zu stellen: das Problem liegt daran, dass zum Zeitpunkt der SSL-Bestellung die DNS-Server noch eine andere IP (die "alte") zurückgeliefert hatten - mit einer TTL von 86400 Sekunden (=24 Std).
LiveConfig prüft die DNS-Daten erst nach Ablauf der TTL erneut (alles andere macht auch wenig Sinn) - in diesem Fall steht der nächste Versuch also erst in etwa 24 Stunden an.

Workaround in so einem Fall ist, das noch nicht beantragte Zertifikat aus der SSL-Verwaltung zu löschen und dann erneut eines zu beantragen. Wir planen aber auch einen Button anzulegen, um die DNS-Prüfung manuell vorzuziehen.

Bei Domainumzügen ist es üblich, die TTL vorab auf einen sinnvollen Wert von z.B. 5 Minuten herunter zu setzen. Eine TTL von 24 Stunden bedeutet, dass ein eventueller Umzug auch erst nach 24 Stunden vollständig abgeschlossen ist (so lange eben, bis die DNS-Daten aus allen Caches geflogen sind).

Viele Grüße

-Klaus Keppler

Zitat von weltmeister

Nachtrag: das 1. Zertifikat ist nun aktiv. Es hat aber ungewöhnlich lange gedauert, was sonst in 5 Minuten erledigt war, hat hier 45 MInuten gedauert, obwohl die DNS der Domain aktiv und vorhanden waren. Woran liegt das?

Es liegt schlicht am DNS. Ich kann von hier aus leider nicht sagen was exakt die Ursache war, aber die Meldungen lassen ja keinen Spielraum zur Interpretation: in einem Fall wurde ein "NXDOMAIN" vom DNS-Server geliefert (das bedeutet also nicht dass der DNS-Server nicht geantwortet hat, sondern die Domain war tatsächlich (noch) nicht vorhanden). Im anderen Fall liefert der angefragte DNS-Server andere IPs als auf dem Server vorhanden sind. Beide Fälle führen bei einer Domainvalidierung durch Let's Encrypt zu einem Fehler - das Verhalten ist also richtig.

Bei neu angelegten Domains kann es immer ein wenig dauern bis diese im DNS konnektiert sind. Es macht keinen Sinn, eine Domainvalidierung anzustoßen bevor die Domain vollständig konfiguriert ist.

Bei der zweiten Domain: schicken Sie uns einfach mal den Domainnamen an support@liveconfig.com, dann prüfen wir das gerne mal.

Viele Grüße

-Klaus Keppler