LiveConfig v2.8.1

kk · 28. August 2019

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

taenzerme · 28. August 2019

Prima, vielen Dank!

Kann man denn damit jetzt SSL mit LE für bestehende Domains/Subdomains aktivieren?

TCRserver · 28. August 2019

Hallo Klaus,

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.

Zitat

Checking for POP/IMAP server software:
- Found 'dovecot' POP/IMAP server
Version: '2.2.27'
Package version: '1:2.2.27-3+deb9u5'

Bei mir ist es auf vielen Servern reproduzierbar.
Ein Neustart des Clients bringt nicht immer eine Lösung.

Getestete OS: Debian 9.9 und 10

aziegler · 29. August 2019

Zitat von kk

[*]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!

und welche werden sonst benutzt??

kk · 29. August 2019

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.

kk · 29. August 2019

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?

aziegler · 29. August 2019

Zitat von kk

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.

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

kk · 29. August 2019

Zitat von aziegler

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

aziegler · 29. August 2019

Zitat von kk

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

Natürlich, alles kein Drama.
Es fällt nur in die Kategorie "immer mehr Anwendungen machen DNS selbst", siehe auch Browser

An anderer Stelle erschwert das Debugging, insbesondere wenn man nicht davon weiß oder nicht daran denkt, dass nicht alles über den lokalen Resolver geht.

antondollmaier · 29. August 2019

Zitat von kk

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)

Das ist möglich, ja.

Fehler trat hier auch auf:

Code

Aug 28 16:45:22 s1 LiveConfig[24307]: [24307|24308] [LUA] POP/IMAP server 'dovecot' not found
Aug 28 16:45:22 s1 LiveConfig[24307]: [24307|24308] LC.popimap.editMailbox(xxx) failed: POP/IMAP server 'dovecot' not found

Allerdings nicht reproduzierbar.

ap24 · 29. August 2019

Zitat von kk

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

Das Problem mit der SSL-Bestellung besteht leider noch weiterhin auch mit der Version 2.8.1

CentOS Linux release 7.6.1810
LiveConfig 2.8.1-r5602

TCRserver · 29. August 2019

Ein Neustart von LC während Pakete installert wurden kann ich nicht ganz ausschließen.
Gestern Abend habe ich den Dovecot Patch und LC 2.8.1 in einem Rutsch installiert.

Teilweise wurde die Konfiguration von Dovecot erst einige Minuten nach dem Restart wieder angezeigt.

Inzwischen habe ich alle Clients nochmals neu gestartet und die Konfiguration wird bei allen Servern korrekt angezeigt. Ich kann es aktuell auch nicht mehr reproduzieren.

pkambach · 29. August 2019

hi!

Ich habe nun etliche Kunden, bei denen die Validierung von LE nicht mehr geht, da /.well-known/ mittels .htaccess umgeleitet wird... das war früher meine ich immer von LC verwaltet, oder irre ich mich?

Gleiche CentOS und LiveConfig Version

VG

kk · 29. August 2019

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.

pkambach · 29. August 2019

So kannte ich es eigentlich auch

Also ich habe zwei Sachen - ein Kunde ohne .htaccess, der einfach einen 404er generiert...

Eine .htaccess sieht z.B. so aus:

Zitat

# BEGIN WpFastestCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^domain-name.de
# Start WPFC Exclude
# End WPFC Exclude
# Start_WPFC_Exclude_Admin_Cookie
RewriteCond %{HTTP:Cookie} !wordpress_logged_in_[^\=]+\=Detlef\sBeyer|klaus
# End_WPFC_Exclude_Admin_Cookie
RewriteCond %{HTTP_HOST} ^domain-name.de
RewriteCond %{HTTP_USER_AGENT} !(facebookexternalhit|WhatsApp|Mediatoolkitbot)
RewriteCond %{HTTP_USER_AGENT} !(WP\sFastest\sCache\sPreload(\siPhone\sMobile)?\s*Bot)
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{REQUEST_URI} !(\/){2}$
RewriteCond %{REQUEST_URI} \/$
RewriteCond %{QUERY_STRING} !.+
RewriteCond %{HTTP:Cookie} !comment_author_
RewriteCond %{HTTP:Cookie} !woocommerce_items_in_cart
RewriteCond %{HTTP:Cookie} !safirmobilswitcher=mobil
RewriteCond %{HTTP:Profile} !^[a-z0-9']+ [NC]
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/all/$1/index.html -f [or]
RewriteCond /var/www/WEBNAME/htdocs/wp-content/cache/all/$1/index.html -f
RewriteRule ^(.*) "/wp-content/cache/all/$1/index.html" [L]
</IfModule>
<FilesMatch "index\.(html|htm)$">
AddDefaultCharset UTF-8
<ifModule mod_headers.c>
FileETag None
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Mon, 29 Oct 1923 20:30:00 GMT"
</ifModule>
</FilesMatch>
# END WpFastestCache
# BEGIN GzipWpFastestCache
<IfModule mod_deflate.c>
AddType x-font/woff .woff
AddType x-font/ttf .ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE font/opentype font/ttf font/eot font/otf
</IfModule>
# END GzipWpFastestCache
# BEGIN LBCWpFastestCache
<FilesMatch "\.(webm|ogg|mp4|ico|pdf|flv|jpg|jpeg|png|gif|webp|js|css|swf|x-html|css|xml|js|woff|woff2|ttf|svg|eot)(\.gz)?$">
<IfModule mod_expires.c>
AddType application/font-woff2 .woff2
ExpiresActive On
ExpiresDefault A0
ExpiresByType video/webm A2592000
ExpiresByType video/ogg A2592000
ExpiresByType video/mp4 A2592000
ExpiresByType image/webp A2592000
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/ico A2592000
ExpiresByType image/svg+xml A2592000
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000
ExpiresByType application/javascript A2592000
ExpiresByType application/x-javascript A2592000
ExpiresByType application/font-woff2 A2592000
</IfModule>
<IfModule mod_headers.c>
Header set Expires "max-age=2592000, public"
Header unset ETag
Header set Connection keep-alive
FileETag None
</IfModule>
</FilesMatch>
# END LBCWpFastestCache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Alles anzeigen

kk · 29. August 2019

Zitat von pkambach

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:

Apache Configuration

[...]
<Directory /var/www/.well-known/htdocs/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>
[...]


<VirtualHost <IP>:80>


    Servername default
    DocumentRoot "/usr/share/liveconfig/html/"


    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteMap  "lc" "int:tolower"
        RewriteCond %{REQUEST_URI} ^/\.well-known/(.*/)?([^/]*)$
        RewriteCond /usr/share/liveconfig/html/.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>


</VirtualHost>

Alles anzeigen

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

Andre · 29. August 2019

Ein Kunde kann bei vielen, nicht bei allen Domains keine PHP Version mehr auswählen, seit dem Update

kk · 29. August 2019

Welche Version lief vor dem Update?
PHP-Auswahl ist nicht möglich bei Verträgen, die auf mod_php konfiguriert sind.

sourceWAY · 29. August 2019

Wann wird denn das Handbuch aktualisiert, insbesondere im Hinblick auf die Änderungen an der API (PHP-Einstellungen)? Derzeit ist leider noch ein Handbuch aus November 2018 (!) online.

antondollmaier · 29. August 2019

Zitat von sourceWAY

insbesondere im Hinblick auf die Änderungen an der API (PHP-Einstellungen)?

WSDL aufrufen und ab geht's

klappt mit Python und zeep 1a:

Code

python -mzeep 'https://lc:8443/liveconfig/soap?wsdl&p=xxx&l=admin'

LiveConfig v2.8.1

Jetzt mitmachen!

Benutzer online in diesem Thema