Beiträge von kk

Zitat von TCRserver

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?

Zitat von aziegler

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

Bestenfalls liegt das Installationspaket für 2.7.x noch unter /var/cache/apt/archives/
Ansonsten melden Sie sich bitte ggf. per Mail an support@liveconfig.com, damit wir Ihnen das zuschicken.

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